Parkings affichés avec "Type : Revêtement" au lieu de "En surface"

esmenard

Mauvaise traduction de "surface" dans le tag parking=surface

Et tant qu'on y est, sur la même image access=yes devrait être traduit par "Accès autorisé : oui" au lieu de "Accès autorisé : autorisé", ou alors juste un "Accessible au public".

1. etienneJr

   Ces traductions viennent d'OSM, c'est le iD tagging schema, c'est à dire les traductions utilisées en premier lieu dans l'éditeur iD, mais aussi dans plein d'autres outils basés sur OSM. Les modifications se font (pour tous les outils !) sur la plateforme transifex.

   Le fichier json qui agrège toutes les traductions enregistrées sur transifex est disponible sur le repo github : https://github.com/openstreetmap/id-tagging-schema/blob/main/dist/translations/fr.json

   Au fait @laem :

   • j'ai un doute de si on devrait utiliser fr.json ou fr-FR.json ?
   • la version sur github a 130 lignes de plus (que ma version en local) : comment on fait la mise à jour ? comment on automatise ça ?

   Mais j'observe des incohérences entre le fichier json du repo et la copie qu'on a sur cartes, mais aussi avec ce qui est enregistré dans transifex. C'est bizarre, il faudrait que je demande comment le fichier est compilé.

   • type=surface est bien traduit En surface sur transifex et dans le json du repo github, mais il est Revêtement dans le json de cartes.app => il faut mettre à jour notre json https://app.transifex.com/openstreetmap/id-editor/translate/#fr_FR/$/567162904?q=developer_notes%3Aparking%3Dsurface (il faut peut-être un compte pour accéder à cette page)

   • access=yes est bien traduit Public sur transifex alors qu'il est Autorisé dans le json => vraiment bizarre https://app.transifex.com/openstreetmap/id-editor/translate/#fr_FR/$/309271232?q=developer_notes%3Aaccess%3Dyes

   Pour Accès autorisé, on a la main sur transifex pour le remplacer par Accès mais je préfère ne pas le faire, car c'est le texte qui est utilisé dans le formulaire de iD pas seulement pour access=* mais aussi pour foot=*, motor_vehicle=*, bicycle=* et horse=* (quoique j'ai l'impression qu'il y a un doublon). Et le texte anglais de référence est bien Allowed access https://www.openstreetmap.org/edit?way=1243324640

   Heureusement, on peut gérer des exceptions au moment où on interroge les presets iD dans /app/api/tag-translations/route.ts Pour l'instant, on le fait seulement pour apporter une traduction qui n'existe pas les presets iD. Il faudrait qu'on étende cette logique au cas où on veut forcer une autre traduction que celle d'iD. Je regarderai comment faire ça un autre jour.

   Voir aussi le ticket #922 sur le sujets des presets iD

2. etienneJr

   Finalement j'ai compris que le tag access a été dupliqué en 2 sets de traductions (non cohérentes) dans access et access_simple. J'ai demandé une explication ici : https://github.com/openstreetmap/id-tagging-schema/issues/1746

3. laem

   Voilà ce qu'on a dans notre package.json : "@openstreetmap/id-tagging-schema": "6.10.0",

   La version actuelle semble être la 6.12.0. Il suffit de MAJ le paquet avec bun add @openstreetmap/id-tagging-schema@6.12

   Je viens de le faire et le déploiement est lancé.

   Pas facile d'automatiser, faut le faire à la main.

4. laem

   @esmenard n'hésite pas à partager les liens en plus / à la place des captures d'écran, ça facilite pour tester les corrections sur ton exemple :)

5. laem

   Corrigé, non ? Example

6. etienneJr

   Oui pour le revêtement. Mais pour l'accès, on a toujours Accès autorisé : Autorisé quand access=yes. A cause de l'histoire qu'il utilise (logiquement) la propriété access au lieu de access_simple. Je pense que je rajouterai des exceptions dans /app/api/tag-translations/route.ts pour afficher une traduction moins bizarre. https://cartes.app/?style=base&allez=Parking%7Cw123335645