Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Internationalisation #126

Open
wants to merge 54 commits into
base: master
Choose a base branch
from
Open

Internationalisation #126

wants to merge 54 commits into from

Conversation

papoteur-mga
Copy link
Collaborator

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.

@jjdejong
Copy link
Owner

  • 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).
  • 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.
  • 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.

@papoteur-mga
Copy link
Collaborator Author

  • 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
Copy link
Collaborator Author

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
Copy link
Owner

jjdejong commented Mar 12, 2024

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"].

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants