Multilanguage product

[appliculture]

I've just launched a multilanguage shop where the same product is duplicated and filled with translation.

The issue would be to manage the stock and each time I would update the price/description/.. I'll have to do it for each translation.

In the future it would be great if we could have product translation, only text information would be different and the other informations like price, stock, dimensions, weight,.. would be common.

[Remo]

I posted some ideas about that here https://github.com/VividWeb/vivid_store/issues/74

[typoman76]

Vote for this one 👍🏻 Also from Switzerland 😄

[Mesuva]

I'm certainly keen to work on this as one of the next major things to add to the store.

As a list of what would be need translation values

• Product names and descriptions
• Product options names (e.g. Size) and values (e.g. small, medium, large)
• Product attribute values
• Receipt email headers/footers
• Fulfilment statuses
• Tax names/labels

Am I missing anything?

This would be mean that:

• Calls to getName, getDesc and getDetail on products would need to be able to accept a locale value
• Other functions that retrieve strings to do with options would also need to handle a locale parameter
• Places where config values are directly retrieved may need to be replaced with storewide functions that respect the locale.

It's a fair bit of work, but I do think it's achievable. The trickiest bit in my mind is coming up with a UI that makes it easy to manage these additional values.

I'm wondering if it's better to have it all contextual to what you are needing to provide translations for - i.e. you have a little globe button directly next to each field and it pops up a bubble where you can enter in translations.

Or, would it be better to try and handle this more in one place, so provide a separate tab for translations when editing a product, where it shows you all the things that need to be translated, or even have a few dashboard pages where products can be listed purely for the tasks of entering translated values.

The latter is perhaps easier to add to the system, but isn't as contextual - I don't want to make assumptions as to what would and wouldn't work, as managing translations just isn't something I'm regularly doing.

I also wonder about whether it needs to be treated a bit more like how concrete5 translations are handled in general. Should a shop admin only need to enter in red->rouge once, and anytime a product option has that string it gets translated, or would it always be product specific. I could almost imagine a page in the dashboard that shows all unique pieces of text throughout the store. Then there could be the equivalent of a t() function added to the store, but specifically for the package.

[Remo]

I'm not sure you can have a fixed list of things that are translatable. We've had stores where we need to upload language specific PDF documents. Custom attributes to show a table with technical data and so on.

The approach we've had in the past (see comment above) worked well for all of us. Having a globe icon to indicate that the value is global / translatable would have been nice, but wasn't request. It was simple for the user, everything in one place, no need to switch to different screens or anything.

We've had a product option attribute where we could manage those options (red, rouge) once and then pick them wherever we needed. Using attributes for everything would imho be handy as it's flexible and powerful. You can always come up with something new and even create a custom UI so that the user can easily enter whatever he needs in a nicely structured way.

[Jozzeh]

A bit late... but I agree with the statement of having a global value and using flags or something else to translate something product related. Everything should be translatable (even though it means more changes) except the stock, and code/SKU . Working with a global value and additional (non-required) translations is a very flexible way, because sometimes a custom attribute needs translation, and other times it doesn't ... Also if someone enters a product, he or she does not have to copy paste every mandatory field.

I think Magento and Prestashop has a similar way on how it handles translations of products. (first enter global values, save product, then the translations become available)

Example as to why most things should be translatable :
A computer store having en_GB and en_US as languages , the custom attribute weight should be translated into kgs for the UK and lbs for the US . (the same for measurements in meter and feet)
But the same computer store could have an attribute 'Clockspeed' in Mhz, which should not be translated.. so the global translation is taken for both the GB and US store .

I'll have a look into this but if someone is looking into this, please give me a shout on where to find the fork of community store where the development is being done.

[typoman76]

Any news or timelines on multilingual functions? I upload a visualization from prestashop. There every input element is translatable. You could change the language beside the input field. And all fields visible change the language. This could be a possible solution for the store. One selector for changing could be enough…

[Mesuva]

No news from me to report, it's certainly in my mind as a future addition, but there are just a couple of items to finish up beforehand I think.

I like the prestashop style, but I do wonder how difficult this would be to implement across the store...