Best practice with translations when the text is long (product descr., etc.)

Hi,

I wanted to know the best way to manage product descriptions in multiple languages.
Indeed I have some products with sometimes a long description.

If I fill in the description for another language, the original description becomes the key in the "override.ini".
Ex. :
AVERYLONGDESCRIPTIONWITHTAGSH1H1FOREXAMPLE = ATRANSLATEDLONGDESCRIPTIONFORLANGUAGE1
AVERYLONGDESCRIPTIONWITHTAGSH1H1FOREXAMPLE = ATRANSLATEDLONGDESCRIPTIONFORLANGUAGE2
So if I have 1000 products, I will have rather large keys, values and language file.

Is it normal and without perfomance problem ? Is there a better way ?

An other alternative that I would see and that would improve it maybe a little bit would be :
Use a key for the original description : ex. : {Product_id}_DESC
So in the language1 file : {Product_id}_DESC = ATRANSLATEDLONGDESCRIPTIONFORLANGUAGE1
language2 file : {Product_id}_DESC = ATRANSLATEDLONGDESCRIPTIONFORLANGUAGE2

But it's not a very practical solution I think.

So do you have any advice for me on this ?

Thank you

Hi,

It's normal. ini files parsing is done by PHP's internal C code, so it should be lightning fast, unless your translation override file is hundreds of MBs in size. So it mainly depends on the number of products you have. If you have hundred of thousands of products and each one has long translation overrides, it's likely it would become slow so reducing the size of the translation keys will be good.
For a few hundred products shop, it shouldn't change anything.
I would personally still try to have small translation keys just to have something clean, but it's more of a personal preference than anything else.

What you can do is to have only a translation key in the main description and then enter the description for all your languages, including your main language.
That way, you can decide what you want the translation key should be for the translations.

Hi,

Thanks for your answer.

My manager is a bit disappointed to know that the translations work like this (with a language file and not using a table from the database for example).

Are there any developments planned on the subject?

Hi,

There are no developments to do it with the database.
That's because this is already possible with Falang, a third party extension which has provided translation capabilities for HikaShop (and Joomla and other extensions) and is the reference in the Joomla world for years.
But I don't see why that would be disappointing ? Joomla has used translation files for translations for 15 years. Unless you have a lot of content, doing it like that shouldn't matter. And if you have a lot of content, using Falang would be a good idea. The translation interface would still be the same.

The description of a product is one of the fields that can be long (like a Joomla article in our case).
So store this content in a file instead of the database (like articles) can be problematic in some situations.

In fact, our new website in development with Hikashop is a migration/improvement from an existing Virtuemart website.
Virtuemart used 1 table for all products and 1 table per language for products, categories, etc., for example.
So we see the pros and cons of these two opposite choices

On my side, I am not a fan of this multiplication of tables (and files that are too large).
I was less disappointed and initially favourable to the use of a key in the original description.
We are in a case where we use very small or very large fields and none of these solutions seem ideal to me.

I will try to see if using falang could be worth it.

Thanks !