Saleor: Translation for models

[artursmet]

As we discussed with @patrys, it will be useful to add translation feature to saleor models (mostly products, probably some CMS in future).

A few assumptions:

Create a model that adds translation to a Product instance and is connected to a product with FK.

• Use Prefetch objects
• Adding new language can't modify the DB schema
  
  
  
  • API like product.translated.name - how do we handle multiple languages there?
  
  
• Use Django Prefetch objects
• ~Only products with complete translation will be available in translated version (if not fields are translated, product will be displayed only in default language)~ Only complete translation can be added to a product

[krzysztofwolski]

Only products with complete translation will be available in translated version (if not fields are translated, product will be displayed only in default language)

So language setting could change displayed products? What about products in cart, order, etc?

[patrys]

My idea was quite different: only allow complete translations to be saved to the database.

We don't want to hide products depending on the language, we want to display some of them untranslated.

Regarding product.translated.name: this should return data for the currently active language.

[artursmet]

@patrys Currently active language, so this should be a function that will be take at least a language (or whole request) as a parameter

[itbabu]

Hello,
what about storefront and dashboard searches? One index per language?

[artursmet]

In search, there are several approaches for handling multiple languages. For example we can index data as nested structure like

title: {
  "en": "Some english title",
  "de": "The same title in German"}

[patrys]

@artursmet I imagine product.translated being an object that overrides its __getattr__. The currently active language can be obtained at any given time with a call to django.utils.translation.get_language().

[patrys]

For UI I want to keep the current forms for default language and a dedicated translation tab for translation work. Editing a translation should display the untranslated content next to each field.

Things to consider: provide a dedicated localization interface that allows you to select a language and see which products require translation. In future we could bring in features such as CSV import/export and external translating APIs.

[artursmet]

@maciekjablonski Please take a look on above specification, it should be enough to start development for this. Please reach me out if something is not clear enough.

Also some estimations will be very useful

[patrys]

Another requirement: have the translation proxy return a correct language for use in HTML (so we can correctly tag mixed content with lang="..." (this is important for accessibility and for proper support of English-within-an-RTL-language).

Please note that HTML language codes are not the same as gettext locale names: http://www.ietf.org/rfc/bcp/bcp47.txt

This looks like a good candidate for the implementation: http://babel.pocoo.org/en/latest/api/core.html#babel.core.get_locale_identifier

[curaloucura]

I look forward to updates on this issue, if anybody could update the status as PR is pending since few weeks now.

[MacLake]

What about using something like django-modeltranslation
? We use it for another Django project, and it works fine. The only drawback is that a Django update might break the app, as it relies on internal API. But when it did, there was an update available within a couple of weeks. As Saleor uses it’s own Admin interface, it would be some work to integrate it there.

[patrys]

@MacLake we explicitly don't want any "magic" that modifies the database schema.

[mnagy]

Hello, is there any update on this? Do I understand it correctly that as of now, there is no way to provide translations for product names, etc.?

[maarcingebala]

We have a PR that adds model translations but only at the backend level without any dashboard UI. Recently we also had other priorities and that's why the PR is still waiting. I'll talk to the team and we'll decide whether to merge only the backend changes and if we have time to work on the UI in the nearest future.