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

  • Posts: 15
  • Thank you received: 0
4 weeks 1 day 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)
Fields


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


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: 84695
  • Thank you received: 13776
  • MODERATOR
4 weeks 19 hours 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.

  • Posts: 15
  • Thank you received: 0
5 days 3 hours ago #369351

Hello,

Sorry for the delay, it has been a very busy week.

All translations were made using the "Non-latin translation keys" option and right now, all products are completely translated. After that, I changed the LanguageFilter fileto show the canonical URL.

So far the content is displaying correctly in their respecting language. However, I am facing a couple of additional issues.

The first one is with the smart search component, the english versions of the products are being indexed but the URL that appears in the search results isn't correct,



In the image above, the results appears with the english title and descriptions, but the URL is incorrect. Any link in the search results are pointing to the "productos" parent menu instead of "products". For example: site.net/en/productos/pet/product/116-1-PRODUCT appears instead of site.net/en/products/pet/product/116-1-PRODUCT

Clicking this links will show a 500 error and this issue doesn't affect the spanish version of the search page.

Product and Productos are menu items that display an article and they are linked together with the Joomla Associations option, the canonical url for the products were set like this.



- The base product has a canonical URL pointing to the spanish version (productos/pet/product/116-1-PRODUCT), without the beginning slash.
- The canonical URL field for es-ES is left empty.
- The canonical URL field for en-GB is using en/products/pet/product/116-1-PRODUCT without the beginning slash.


What am I doing wrong here?

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

  • Posts: 84695
  • Thank you received: 13776
  • MODERATOR
4 days 4 hours ago #369366

Hi,

The Smart Search system only accept a non SEF URL during the indexing of the content. So, the canonical URL cannot be provided by HikaShop.
This means that HikaShop tries to dynamically calculate a valid URL for the product being indexed for each language on the website.
I think the problem stems from the fact that HikaShop takes into account the current language instead of the language of indexation when searching for a menu item to use in the URL of the indexed product. This can lead to a menu item being used in the URL which doesn't correspond to the language indexed, and thus an invalid URL, which would result in an error on the frontend when being used.
I've made a patch in the HikaShop Smart Search plugin in order to take into account the language of indexation during this process. It should hopefully fix your problem with the search results generating invalid URLs in some cases.
You can download the latest version of HikaShop on our website and installing on yours to get the patch.
You'll then have to clear your Smart Search index and reindex your content.

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

Time to create page: 0.063 seconds
Powered by Kunena Forum