traduction des catégories

etienneJr

Je rouvre un nouveau ticket (en plus de ce que j'ai déjà écrit 1880#issuecomment-12182706">ici dans #1880) pour raconter mon expérience du jour :

• @LySioS a ajouté des catégories dans le fichier français.
• ça provoquait un crash car loadCategories.ts ne trouvait pas les traduction en et br
• je me suis dit que j'allais rajouter les traductions, mais ...
• autant pour en j'en aurais été capable
• autant pour br, impossible, je n'ai pas réussi, même en m'aidant d'un outil de traduction automatique

J'en conclus que les outils de traduction ne font pas tout. Pour des petits mots comme ça, c'est impossible de traduire dans une langue qu'on ne connait pas du tout. Et donc, il faut que la liste des catégories soit indépendante d'une langue, que les traductions soient gérées dans un fichier séparé. Même les traductions en français. Car aujourd'hui, un non francophone ne peut pas ajouter une catégorie, vu qu'il ne connait pas le français.

Cela dit, il faut bien une langue pour les keys. Ca me paraitrait hyper logique de prendre l'anglais, comme ça la plupart des keys seront cohérentes avec le tag OSM.

@laem Pour éviter le crash, j'ai désactivé le console.error() mais ça fait que les catégories non traduites ne sont pas incluses dans la liste (cela dit c'est un mécanisme intéressant pour ne pas inclure France Travail dans la traduction en anglais !)

https://codeberg.org/cartes/web/src/commit/af2202cb44a6394a777c3628903854155ae4a53f/components/categories/loadCategories.ts#L63

1. laem

   Merci d'avoir géré !

   il faut que la liste des catégories soit indépendante d'une langue, que les traductions soient gérées dans un fichier séparé.

   Je pige pas trop, c'est déjà le cas non ? Un fichier de traduction par langue.

   Même les traductions en français. Car aujourd'hui, un non francophone ne peut pas ajouter une catégorie, vu qu'il ne connait pas le français.

   Oui mais ça ne me semble pas déconnant. L'i18n du site ne veut pas dire qu'on a acté que des contributions peuvent se faire en anglais sans être faites en français. Je sais que ça choque, mais j'inscris jusqu'à nouvel ordre le fait que le Français est la langue de base.

2. laem

   pour les keys. Ca me paraitrait hyper logique de prendre l'anglais, comme ça la plupart des keys seront cohérentes avec le tag OSM.

   Je suis plutôt opposé. Il y a un immense déséquilibre aujourd'hui dans l'informatique sur la mise en avant de l'anglais. N'y participons pas : si quelqu'un se motive pour faire proprement une version traduite dans toutes les langues des clefs de l'URL, c'est cool mais l'anglais ne doit pas remplacer les clefs en français. Et pour l'instant c'est pas la priorité, on a besoin de natifs et de code sur d'autres choses plus critiques, cf 1866.

3. etienneJr

   @laem wrote in https://codeberg.org/cartes/web/issues/1907#issuecomment-12382818:

   Je sais que ça choque, mais j'inscris jusqu'à nouvel ordre le fait que le Français est la langue de base.

   D'accord, mais il faut quand même que les keys soient codées en dur, et non calculées à partir du name comme aujourd'hui, car c'est trop risqué (au sens il y a trop de risque de crash si qq change le name).

4. laem

   (au sens il y a trop de risque de crash si qq change le name).

   C'est quoi ton scénario ? Un contributeur FR change "vendeur de vélos" en "boutique vélo" et du coup le lien avec l'anglais basé sur le premier saute ? Mais justement, si renommage il y a en français, nécessaire revue des traductions il y a, car le sens a changé.

5. etienneJr

   @laem wrote in https://codeberg.org/cartes/web/issues/1907#issuecomment-12383088:

   Mais justement, si renommage il y a en français, nécessaire revue des traductions il y a, car le sens a changé.

   je suis d'accord, mais cette remarque est vraie dans tous les cas. Et justement :

   • si il y a categories.yaml qui définit le name français et la requête, et categories.en.yaml qui définit le name anglais, alors le contributeur FR qui aura modifié requête et name a 100% de chance de rater le fait qu'il doit aussi modifier le name anglais pour être cohérent.
   • alors que si on a categories.yaml qui définit la requête et la key, et des categories.xx.yaml qui définissent les traductions, alors c'est beaucoup plus clair qu'un changement de requête doit être accompagné d'un changement de name dans toutes les traductions.
6. LySioS

   Donc on mettrait les infos universelles dans categories

   • requete
   • key (c'est l'identifiant unqiue ?)
   • icone par défaut
   • group id ?

   Et dans la version categories.xx

   • name
   • group ?
   • dictionnaire
   • icone

   Ama, l'icone devrait etre dans les infos universelles, mais etre écrasable par le fichier spécifique à la langue/pays, puisque la symbolique dépend beaucoup de notre culture.

7. laem

   @etienneJr je comprends ton idée mais je suis pas sûr que ça change grand chose. Dans les deux cas il faut avoir envie de se soucier de l'anglais et des autres langues, donc de quintupler l'effort voir plus. La question de où est inscrite la version française source me semble accessoire par rapport à l'effort supplémentaire ajouté par les traductions, qui écrase tout le reste.

   C'est précisément ce que je voulais éviter avec la traduction du contenu JSX : séparer les texte humains en les mettant loin des id.

   Banner.tsx

   <div><Trans id="banner-message-plus-2" /></div>

   .po msgid: "banner-message-plus-2" msgstr: "Attention, le site est en panne !"

   Ici un contributeur pourrait ajouter dans categories.yaml

   • key: cargo

   et dans categories.yaml transport: title: Arrêt de vélo cargo

   Donc je pense qu'il faut éviter de passer du temps à rédiger à la main des ids (enfin des clefs ici) tant qu'on peut, c'est mieux et ça créée un ensemble plus humain. Qui favorise le français ici c'est sûr, mais l'autre version ne favorise aucune langue et c'est pas mieux je pense.