Issues with Hikashop Translation: 1) Name/Title/Alias fields are linked, and 2)

  • Posts: 14
  • Thank you received: 0
1 week 2 days ago #369022

-- HikaShop version -- : 6.1.0
-- Joomla version -- : 5.3.3
-- PHP version -- : 8.1.33
-- Browser(s) name and version -- : 7.7.3832.3 (Build oficial) (64 bits)

Hello everyone,

I'm working on a website migration from Joomla 3.x to Joomla 5 for a client, which includes moving to the latest version of Hikashop.

The original site was built before Hikashop's integrated translation system, so they created duplicate products (one for Spanish, one for English). For the new J5 site, I am trying to use the modern translation feature to merge these products and simplify management.

I've run into two issues that I'm hoping to get some guidance on.

1. Product Name, Page Title, and Alias fields are linked
My first issue is that when using the translation interface, the product_name, product_page_title, and product_alias fields seem to be linked. The system copies the same string into all three fields, and I can't set them independently.

For SEO, I need to define different content for these fields. For example:

  • Product Name: My Awesome Product

  • Page Title: Buy My Awesome Product | My Company

  • Alias: my-awesome-product

Currently, if I enter "My Awesome Product" in the "Name" field, it automatically populates the "Page Title" and "Alias" fields with that exact string. If I then try to edit just the "Page Title", the "Name" field gets updated to match it.

This behavior occurs in both the original language and the translation.

Here is an image of the desired outcome (with independent values)


And here is an image of what is actually happening (the fields are forced to be identical):


2. Canonical URL tag is missing
The second issue is that the canonical URL tag (<link rel="canonical" ...>) is not appearing in the HTML source code on any of my Hikashop product pages.

I found another forum post detailing the same problem here:
https://www.hikashop.com/forum/product-category-display/907095-issue-ith-canonical-urls.html

Following the temporary solution in that thread, I went to the Joomla System - Language Filter plugin and set the "Alternate tags" parameter to "No". This does make the canonical tag appear correctly on the product page.

However, this isn't a long-term solution, as I need the "Alternate tags" (hreflang) enabled for our multilingual SEO. This suggests a potential conflict between Hikashop's canonical tag generation and the Joomla Language Filter plugin.

I'd really appreciate any help or ideas on how to get these two issues sorted out. Getting these fields to work independently and having both canonical and alternate tags show up is pretty critical for the site.

Thanks in advance!

Please Log in or Create an account to join the conversation.

  • Posts: 84582
  • Thank you received: 13752
  • MODERATOR
1 week 1 day ago #369033

Hi,

1. The translation system in HikaShop uses the translation files of Joomla to store the translations.
If you go to the Languages tab of the HikaShop configuration page, and edit a language, you can find the translations you've already made for that language on the right side of the screen.
You can see that you'll have one row per translation in this format:
KEY="text"
When you add a translation via the translation popup, it will have to generate that "KEY" from the original text of the product.
So, for example, if you have a product with the name "HikaShop Business", it will generate the key HIKASHOPBUSINESS and store the translation text using that same key.
However, if, for the same product, you have the alias "hikashop-business", it will result in the same key HIKASHOPBUSINESS. And since you can't have several translations with the same key, the translation for the name and the alias will appear "linked" to you.
But they aren't.
You have two possibilities:
- You could activate the "Non-latin translation keys" setting of the HikaShop configuration. That way, instead of using the latin letters of the original text to generate the key, it will generate a hash of the original text to use as the key. By doing this, as long as there is something different between two fields of the product, the generated key will be different and thus you won't have that problem :
www.hikashop.com/support/documentation/5...onfig.html#languages
The issue with this solution is that since the key generation method is different, the translations you've already made will be lost and you'll have to redo them.
- You could just make sure that the original text is different enough. One simple way would be to add some text. For example, in the alias, instead of having just "hikashop-business", I could have "hikashop-business-edition" or "hikashop-business-for-joomla" or "hikashop-business-by-hikari-software". Another method would be to directly enter a translation key of your choosing. So you could have for the product alias "HIKASHOPBUSINESSALIAS" so that it can be used directly as the key.

2. It is not a conflict between HikaShop and that plugin. It is a bug in that plugin.
As explained on that other thread, we reported the issue to the Joomla project:
github.com/joomla/joomla-cms/issues/42128
Since then, a pull request with a simple fix has been proposed but the developers are still discussing the proper implementation for the long term:
github.com/joomla/joomla-cms/pull/45428
So, on our end, we did what we could. We reported the issue, proposed a fix and discussed with the Joomla developers what would be appropriate.
What I can recommend you to do for this:
- I provided a temporary patch for it at the end of the thread you provided a link to:
www.hikashop.com/forum/product-category-...-canonical-urls.html
So, you could implement that patch in the joomla plugin. This will make it work. The drawback is that you can loose that change after each update of Joomla, and thus you would have to reapply it.
- You can add your comment to the pull request on GitHub. The more people voice their concern on that matter, the quicker it will get addressed.
- you can wait for Joomla to rollout the fix in a future version.

Please Log in or Create an account to join the conversation.

Time to create page: 0.055 seconds
Powered by Kunena Forum