Use po files to translate taxonomy properties

[alexgarel]

Today we have in taxonomy some files with properties like:
description:en: it is meant to be translated to description:fr, description:it, etc.

I thinks it's a bad idea because it's less accessible to translators + it makes taxonomies always bigger.

My proposal would be to instead be able to add a description:_:sugar_over_100 (here in data_quality.txt).

In the server code, if we see it, we can translate it by searching for data_quality_description_sugar_over_100 language string to translate (<taxonomy_name>_<property_name>_<value_for '_'>)

Now we can have a script, when we build translation, that also add or update the language_id and its english value in the po files (maybe not common.po but a taxonomies.po ?).

Note: I propose it only for properties of entries, not for entries themself, whose translations should remain a work of taxonomist.

This way we could have a lot more translation to useful descriptions (and more) and avoid taking too much memory on server side for taxonomies.

[alexgarel]

@aleene @stephanegigandet @john-gom @CharlesNepote @teolemon I request your comments :-).

[stephanegigandet]

It's a good idea, but I would keep the English source in the taxonomy file.

Something like:

en:Nutrition value over 1000 - Sugars
description:translate:Sugars value is over 1000g per 100g, which is impossible.
show_on_producers_platform:en:yes

Any property with :translate: would be added to the taxonomies.pot file, with the msgctxt "taxonomies/data_quality/en:nutrition-value-over-100".

[john-gom]

I'm not sure it makes sense to keep having translations in multiple places. If we can get the taxonomy editor more usable, or switch to a wikibase approach, then adding translations while editing the taxonomy would be much more seamles and give clearer context to the translator

[alexgarel]

@john-gom we have a big community of translators on crowdin. Much larger than the one working on taxonomies.

[john-gom]

Yes, but why can't they also work on translating taxonomies too? I know that is kind of what you are looking for, but why limit it to the descriptive fields?

[john-gom]

Sorry, I appreciate I'm probably over simplifying things but want to be sure we are asking the obvious questions, and your answers are helpful in giving newcomers like me better context

[stephanegigandet]

@john-gom Translating the names and synonyms of taxonomies is very tricky, because they have to be unique (one name or one synonym should only match a single entry), and you really need domain expertise for some of them (e.g. categories, ingredients). Crowdin is great to translate sentences, but translating names without context is much more difficult.

[alexgarel]

Yep, just to reformulate what @stephanegigandet wrote:

• translating taxonomies entries and adding synonyms is a work of taxonomy (specific rules to account for, expert knowledge, very language specific and cultural also)
• translating some texts within taxonomies (like description, or explanations, etc.) is more of a standard translation work, and can be done by crowdin community.

we are killing two birds with one stone:

• use less memory to load taxonomies even with lot of translations
• have more translators thanks to our crowdin community

[yarons]

I think that this should be structured as Wikidata, managing this kind of list in a flat file is tedious.

[github-actions]

This issue is stale because it has been open 90 days with no activity.

[yarons]

We still don't have an agreement on this :)

[alexgarel]

@yarons I think we should put aside discussion on changing the taxonomies structure (for that we should open a new issue).

[github-actions]

This issue has been open 90 days with no activity. Can you give it a little love by linking it to a parent issue, adding relevant labels and projets, creating a mockup if applicable, adding code pointers from https://github.com/openfoodfacts/openfoodfacts-server/blob/main/.github/labeler.yml, giving it a priority, editing the original issue to have a more comprehensive description… Thank you very much for your contribution to 🍊 Open Food Facts

[yarons]

@alexgarel well, using Wikidata/Wikibase means that we can use the internal localization system and we cannot use .po/gettext/cliff/i18next whatever, it's a full commitment to the structure from all perspectives with a dedicated pages for collections and translation statuses based on SPARQL queries, this is why I'm proposing it here, going with po is the complete opposite direction and will be very hard to manage and we won't benefit from the data that is already managed and translated.