Internationalisation

[papoteur-mga]

Cette branche apporte l'infrastructure pour permettre l'internationalisation de l'interface. Toutes les chaînes concernées par la traduction ont été marquées :

• dans les contrôleurs en php
• dans les modèles blade
• dans les scripts javascript.
  Trois commandes artisan ont été ajoutées et permettent de traiter chacun des types de fichiers ainsi que les fichiers de migration qui renseignent la base de données.
  Un script bash permet de mettre à jour le catalogue de chaînes à traduire.
  Au final un script python permet de générer les fichiers de langue utilisée par l'application.
  Ceci pourra encore être simplifié à l'avenir.
  La traduction en français est également réalisée.

[papoteur-mga]

• The migration creates the language column in the actor table. This migration fails because the language column was already present for setting the language of the emails used by the renewal management tool.

  • The column was designed to store languages in two-character format in lower case (fr/en/de).

I removed the migration file

* Each method in each controller has its own `App::setLocale(Auth::user()->language)` statement. Is there no way to set the locale globally for the translations? For instance using a [middleware](https://lokalise.com/blog/laravel-localization-step-by-step/#Middleware).

I have no clue on how to do that. Do you have?

* What about the date formats? This was handled by `config.app.locale`, to specify a date format independent of the language of the interface. There seems to be a potential conflict between setting the session locale to the user's language for the translations, and setting the date format to a specified locale. I believe the locale for the translations and the locale for the formats should be handled independently, maybe with an additional `date_format` column in the actor table.

I did not see any problem with date, but it is perhaps by chance ;)

[papoteur-mga]

I see that there is still a missing feature. The issue is with autocompleted fields. For now, as the database is queried with the starting word, the answer is the word in original language. After setting the field, it is displayed in translated language, which is not coherent.
What could be done is to find first all strings where the translation starts with the partial word, to query the database with this list to filter the ones in the database and provides the list with translated strings.
Another way is to query the database without filter, get a list of translated terms and filter this list.

[jjdejong]

I was wondering how you handled that. I imagined additional columns in the tables for different languages, like in the country table. The issue is then how to use the appropriate column depending on the language chosen. I haven't developed anything for the country table.

Maybe use a JSON column including all languages, like { "fr": "Dépôt", "en": "Filing", "de": "Einreichung" } for name in the event_name table.

Or simply a JSON array, where the order corresponds to the language, like ["Filing", "Dépôt", "Einreichung"].

[jjdejong]

I'm still a little dubious about the performance of filtering and autocompletion queries operating on columns translated on the fly by retrieving the translations from a file, i.e. without using the column indexes. I'd really prefer JSON columns containing names in all the languages required, which would then be indexed, or a separate column for each of a reduced set of languages, like in the country table.

I spent a lot of time optimizing the matter filtering query so that it performs almost instantly even if the matter table is very large. The "Status" field of the filter is a term contained in a joined table (event_name), so using a file-based translation there significantly reduces performance.

Anyway, given the amount of changes made since the request was posted, merging it is very difficult. The branch should be synced with the main branch offline and submitted again, hopefully with a better performing solution for the translation of terms contained in the tables.