HIKASHOP ESSENTIAL 60€The basic version. With the main features for a little shop.
HIKAMARKETAdd-on Create a multivendor platform. Enable many vendors on your website.
HIKASERIALAdd-on Sale e-tickets, vouchers, gift certificates, serial numbers and more!
MARKETPLACEPlugins, modules and other kinds of integrations for HikaShop
-- HikaShop version -- : 3.1.1
-- Joomla version -- : 3.7.5
-- PHP version -- : 7.1.8
-- Browser(s) name and version -- : Chrome 60
Hi guys,
as all we know an eCommerce is an international commerce. Now that also
Multilingual Associations feature
has been released in Joomla, I think this is one of the biggest lack here in
Hika
, a real Joomla Multilanguage integration.
Please, Do we have any hope to see it soon ?
Please Log in or Create an account to join the conversation.
Hi,
I'm sure you already know that there is an integration with Falang which is quite real if you need a multilingual shop with HikaShop.
Now if your question is whether we'll build soon a solution directly integrated in HikaShop to do that, without the need of Falang, that's another question. Yes, that's something we want to do. Will it be soon ? I would say no for two main reasons:
- there is already Falang which work quite good for that
- we have other more pressing features we want to add like web services
Please Log in or Create an account to join the conversation.
Hi Nicolas,
just a note that sure you yet know, the Multilingual impovements are on
Joomla 4 Roadmap
, to confirm the importance of a real Multilingual vision.
Thanks for your attention...
Please Log in or Create an account to join the conversation.
Hello,
I wrote many times in that forum my opinion about the Joomla multilingual system. So I won't make long speech.
The way that Joomla is performing the multilingual is good for the "article" perspective but not good for an e-commerce solution.
You can do it in HikaShop if you want but it means that you will duplicate every single product for each language ; exactly like you duplicate your categories/articles in Joomla.
Regards,
Please Log in or Create an account to join the conversation.
Hi Jerome,
Jerome wrote: ...I wrote many times in that forum my opinion about the Joomla multilingual system...
Please Log in or Create an account to join the conversation.
Hi,
I'm not sure about Jerome.
Here is a thread where I talked about it a while back:
www.hikashop.com/forum/3-bug-report/3765...edition-in-j2-5.html
Please Log in or Create an account to join the conversation.
Hi Nicolas,
thanks for link, I red it.
As far as I understand, the only "bad" thing on managing multilanguage with Joomla should be the need to "moltiplicate products", one product id per language, and this would be bad for statistics etc. because HikaShop do not have an integrated way to make associations (like joomla) and say that all the products languages are the same product. Hope also Jerome can confirm this.
Now, I think that this issue, and also others like joomla article integration / Seblod cck integration, can be solved with a similar
"j2store Seblod" plugin approach
, where:
- Build a plugin for joomla article (each joomla article will ask if is a product). Buld a plugin for Seblod (when integrated es explained each Seblod article will ask if is a product)
- Add a pre-question "Do you want to pick a product yet exist in your HikaShop?" (In this way all the old HikaShop products will can be moved into a Joomla article / Seblod article)
- The "Joomla article product" will be able to use the new Joomla Custom Fields. The "Seblod article product" will be able to use all the CCK features
- The user will be able to choose to use the Multilanguage with falang when using HikaShop directly, or switch to Joomla Multilanguage when using the Joomla Article / Seblod Article - No needed anymoreto develop an internal HikaShop Multilanguage
- And in my opinion would be better to leave the Custom Fields development to Joomla / Seblod etc... to concentrate HikaShop team efforts on features more importants like payments/invoices/statistics etc. and new app like a booking system...
If you are agree, I'd have some questions:
1 - When you can choose to treat article as product, you have to choose also the "product type".
J2store divide into: Simple / Variable / Configurable / Downlodable
I think HikaShop have only one product type, because all the product configurations are under the same product setting page (Included the HikaSerial, HikaSubscritpion, HikaMarket variables). Am I right ?
2 - I need help, your opinion, on Which HikaShop Product page sections leave and which have to be removed (because have to be setted into the article, like the description... I add a j2store Configurable Product Type example
Please Log in or Create an account to join the conversation.
Hi,
1. Well, HikaShop has a product_type field for products. However, it's mostly used for behind the scene things.
For example, variants are stored as products but their product_type is "variant" instead of "main". I don't think that you would have to allow the selection of the variant type in articles though.
Another one is the "template" type, that HikaMarket uses to generate products when vendors create new products on the frontend. But again, these are not useful for articles in such integration.
So I indeed don't think that the selection of a type should be necessary for HikaShop if you were doing such an integration.
2. I think you would want most of the options. The options you wouldn't want I think are:
- product name since you would use the article title
- categories (but it would be useful for discounts, limits, custom hikashop fields, etc) so it might be interesting to keep them
- tags since you would use the article tags
- published since you would use the article published status instead
- the description, obviously
- the page title, meta description, keywords and alias fields would be irrelevant as the article handle these
- the canonical URL wouldn't be necessary as the URL would be the article's URL
- the available from/to fields could potentially be removed since there are already a publish/unpublish date for the articles
- the access level could be ommited to use instead the access level of the article
- for the page layout, I'm not sure. You might still want layouts but only for the bit added to the article by the integration plugin
- the custom fields could be ommited.
3. The idea is quite good indeed. That would allow for a great multilingual native integration without the need to rewrite a lot of the MySQL queries of HikaShop to handle it and would also avoid the pitfalls of duplicating the products, one per language.
That could even be made as a third party plugin since it wouldn't touch to the core of HikaShop, only add products to it.
One thing you could do first would be to have a product selector instead of a whole product settings interface in the articles. That way, you would have the same result but without all the work to integrate all the options of the product page to the articles. The only downside, would be to precreate the products, but you could have a add button with a popup to do that next to the product selector on the joomla article.
Please Log in or Create an account to join the conversation.
Hi Nicolas,
really many thanks. I'm already working on it preparing a working plan to show you (as always, you know: I'm a collaborative spirit).
I'm including in the plan the Joomla Article (not only Seblod) and the "import" for all the HikaShops that want move:
- "a product selector": "Yes", to permit to all the the old HikaShop an integration, with a "prefilled importing view" and making available only products that are not yet associated with an Article (to avoid unwanted duplicated, two articles for the same product)....One thing you could do first would be to have a product selector instead of a whole product settings interface in the articles. That way, you would have the same result but without all the work to integrate all the options of the product page to the articles. The only downside, would be to precreate the products, but you could have a add button with a popup to do that next to the product selector on the joomla article.
Please Log in or Create an account to join the conversation.
Hi Nicolas,
Is there any movement in regards to this?
Falang is a solution but not a great one, for instance, Sh404sef folks told me they would not debug a website with Falang on it, because of what Falang does to a Joomla website. This alone is a red flag to me.
Honestly, maybe I'm too dense, because I have Hika for about 1 year now and I'm yet to use it in favor of Virtuemart, just because I always get frustrated. I find the routing harder to get around, maybe its the Sh404/Falang issue. I don't know, but one thing I know that I think most of us agree with is that if Joomla haves a system that works well, why use Falang?
I know Jerome doesn't agree but I've been through several Virtuemart websites that are multi-language and they work pretty well and you can manage the products translation from the product tab, comfortably.. I've also worked on a joomla website using for a couple of years now, and Mijoshop also uses Joomla to handle the translations.
But I do understand that you guys favor Falang as a work around while you come up with features that are not possible to have unless you develop something from scratch.
Still wondering if this is in your roadmap or not, and if yes, how far down or up it is.
Please Log in or Create an account to join the conversation.
Hi,
It's not that we disagree.
The main advantage of Falang is that as an extension developer, I can integrate with it by just writing a few xml files (so a few hours). I don't need to change MySQL queries, change the database structure, etc.
With the Joomla translation system, it requires adding new columns and/or tables to the database structure and changing most of the MySQL queries in the code. So it's a lot of work. The advantage is that you would get one less extension on your website and it would be faster as the MySQL queries would be better optimized (faster) than having them go through Falang.
If you start a new extension, it would of course be a no brainer to directly integrate with Joomla. But when you already have a really big extension with more than a thousands of MySQL queries to change, that's a big undertaking.
We still want to work on that at some point. However, at the moment, we have our eyes on more important things:
- the compatibility with Joomla 4
- the integration with the future privacy system of Joomla 3.9
- web services
- new filters system as the current one is kinda old, hard to maintain, not flexible enough, not ajax, etc.
Just these are big projects for us, without counting all the other little things here and there.
Please Log in or Create an account to join the conversation.
