[OSM-talk-fr] Suppression des tirets cadratins

[Philippe Verdy]

Le 3 décembre 2012 19:40, <teuxe at free.fr> a écrit :

> Au passage, je ne sais pas si la règle est édictée quelque part, mais il
> semble logique pour un système géographique de privilégier l'usage local
> dans le remplissage du champ name=* et d'indiquer les spécificités dans les
> langues étrangères si elles existent dans le champ name:LANG=*.
>  Par exemple : http://www.openstreetmap.org/browse/node/26686563(name:fr=* n'a pas besoin d'être précisé)
>

Pourquoi pas besoin ?

Note mon précédent message qui indique qu'il peut être nécessaire
d'indiquer justement dans quelle langue la valeur d'un "name=" est écrit,
(ne serait-ce que pour autoriser ou non des substitutions automatique
dedans dans un rendu, par exemple pour générer des abréviations qui ont un
sens dans la langue source, ou justement pour des corrections
"typographiques", mais aussi pour des adaptations — y compris la génération
automatique des translittérations pour les écritures non précisées dans la
base :

Par exemple on trouve en France plein de "pseudo-noms" russes alors que ce
ne sont QUE des translitérations et PAS des traductions réelles (la
présence de ces translittérations dans la base est à mon avis inutile,
d'autant plus qu'il existe diverses méthodes de translittération, notamment
arabe-latin, cyrillique-latin, sinogrammes-latin, et même hangûl-latin,
même pour un même couple de langues, et même si certaines sont normalisées
internationalement pour la toponymie et ont encore moins besoin d'être
stockées dans la base

— Un exemple : la Wikipédia russe, est pleine de translittérations
fantaisistes, qui sont même incohérentes dans les toponymes composés dont
les composant signifiants sont pourtant individuellement traduits et non
translitérés: un exemple cocasse est la "Seine-Saint-Denis" qui est
entièrement translitérée sous une forme pseudo-phonétique qu'on lirait en
latin comme "Cène-Cène-Dénisse" (sic !), alors que "Seine" est traduite
sous une forme qu'on peut lire "Céna" et "Saint-Denis" est traduit sous une
forme similaire à "Sinkt-Denis" avec le mot russe pour "Saint", ce qui veut
dire que la traduction devrait être similaire à "Céna–Sinkt-Denis" sans
répétition apparente. Mais rapidement la base OSM se remplit de ces
translitérations fantaisistes, Wikipédia ayant tendance à présenter ces
translitérations comme si c'était des traductions, il suscite des
modifications à la langue russe elle-même et développe l'incompréhension,
et multiplie les homonymies en russe, là où le nom initial en français ne
souffrait d'aucune ambiguïté et que cette distinction aurait pu être gardée
aussi en russe, en utilisant sa langue et non des translittérations souvent
hasardeuses. —

Tant qu'on ne précise pas au moins quelle est la langue par défaut dans une
zone géographique donnée, c'est difficile de savoir quoi faire de la valeur
"name=" à laquelle on ne peut donc pas toucher.

Je veux bien qu'on ne répète pas la valeur de name=* (dans une langue par
défaut non précisée dans cette clé) dans "name:fr=", à condition qu'on ait
quelquepart l'information comme quoi cette langue par défaut est bien le
français, ou qu'elle peut s'appliquer au français — ce qui suppose une clé
du genre "name:langs=fr".

Si on était vraiment rigoureux, on devrait toujours mentionner la (ou les)
langue(s) pour laquelle une même valeur donnée s'applique, et on éviterait
de répéter aussi la même valeur dans plusieurs "name:LANG=", en utilisant
une syntaxe de clé comme "name:LANG1,LANG2,LANG3=" (mais cela au prix d'une
modification des outils cherchant à internationaliser un nom dans une
langue donnée)

Et de fait il n'y aurait plus aucune clé "name=", mais on pourrait avoir
encore une clé comme "name:LANG1,LANG2,*=" pour indiquer (avec une "*" ici)
dans la liste des langues mises dans une clé, laquelle des clés contient la
valeur par défaut pour les langues qu'on ne trouve pas listées dans les
autres clés e la forme "name:LANG1,...,LANGn=".
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20121204/88c3b307/attachment.htm>