Rearchitecture of the multilingual texts / static pages

[stephanegigandet]

The current system to store and serve pages like /terms-and-conditions (https://fr.openfoodfacts.org/conditions-d-utilisation in French) does not work very well with translated versions in many languages. Those texts are currently stored that way:

/lang/en/texts/terms-and-conditions.html
/lang/fr/texts/conditions-d-utilisation.html

This make translation difficult because the names are different, and the links to those texts (in the top bar for /discover and /contribute , in the footer etc.) can be broken if the file name is translated in one place and not the other.

Proposed new system:

1. Keep the same file name for texts, and either store them in /lang/[language code]/terms-and-conditions.html or in /lang/texts/terms-and-conditions.[language code].html (or something like that)

   -> This should make it easier to generate and commit translations through Crowdin.

2. Use a new entry in the .po files so that we can translate the text link and url:

   in fr.po:

   msgctxt text_terms_and_conditions
   msgid Terms and conditions
   msgstr Conditions d'utilisation
   

   That's it for the configuration. The code will use it to:

3. Turn "Conditions d'utilisation" to the /conditions-d-utilisation url.

4. Make /terms-of-use redirect to /conditions-d-utilisation in the correct language. (useful to keep old untranslated urls working, and to quickly find new urls)

5. Automatically create links to Conditions d'utilisation in the menus, footer etc.

6. Allow texts to link to other texts with just a tag like <text_link terms-and-conditions> (create the full <a href=""..>..</a> link), <text_title terms-and-conditions> and <text_url terms-and-conditions>

---

Also introduce support for language variants for texts:

show terms_and_conditions.pt_BR.html for Brazil, fall back to terms_and_conditions.pt if it does not exist.

Part of

• 👷‍♀️DevOps (Tracker) #5512
• 🌐 Improve the translator journey (tracker) #5528

[teolemon]

How do we handle character languages ? Automatic romanization ?
Tag entries in the same file, just below the Normal text ?

[stephanegigandet]

We will use a new get_string_id_for_language function that normalize the string in a language specific way, it will work like entries in the taxonomy. See @hangy's #1696

So French will be deaccented, German won't, and CJK will be kept as-is in the URLs.

[teolemon]

We could use a simple Wordpress instance, with a system to sync pages to Crowdin. This works pretty well for the blog.

[alexgarel]

Yes I'de really advocate to choose a CMS and either proxy it from nginx or perl, but avoid re-implementing a CMS 😬