[OSM-talk-fr] Chiffres romains

[Thierry Bézecourt]

Merci pour ces explications détaillées qui m'aident à mieux comprendre 
BCP47.

Mais l'un des problèmes que rencontre Wikipédia actuellement, c'est que 
le code wiki est devenu trop compliqué, au point apparemment de rebuter 
de nombreux utilisateurs. Donc ils ont développé un éditeur visuel, qui 
est lourd et qui marche plus ou moins bien.

Ce serait dommage qu'OSM suive le même chemin en imposant des balises 
aux noms non intuitifs. Cela conduirait à une "clubbisation" d'OSM, où 
seuls les experts pourraient comprendre comment cela fonctionne ; 
d'autant que, les projets collaboratifs étant ce qu'ils sont, on ne peut 
pas espérer que le système sera "stable" un jour.

L'utilisateur moyen d'OSM ne lira jamais une RFC en entier. De même, il 
serait exagéré d'exiger que le contenu soit saisi en IPA (tant qu'à 
faire, on pourrait proposer que le "name" soit saisi en HTML ou en RTF 
pour mieux respecter la typographie). Il faut fournir une possibilité de 
le saisir en langage plus simple.

Il y a des outils "conviviaux", certes. C'est sans doute bien pour les 
utilisateurs occasionnels, mais cela complique la tache pour les 
utilisateurs aguerris (libellés différents d'un outil à l'autre, mise à 
jour incertaine des outils par rapport aux "règles" mouvantes d'OSM...).

Bref, choisir des noms de balise compliqués parce qu'ils sont standards, 
cela revient à favoriser le développeur qui utilise les données de la 
base de données par rapport au contributeur moyen d'OSM.

Et encore, cela revient à privilégier le développeur paresseux. Si 
j'exporte les données d'OSM vers une base externe, je vais tout de même 
vérifier un peu que les données sont correctes. Le nom des tags étant 
libre dans OSM, le développeur sérieux ne va pas supposer que toute 
balise "<lang>-<...>" est une balise BCP-47. Il devra bien faire des 
vérifications sur le format du tag, donc ça ne constituera pas une 
complexité supplémentaire pour lui de convertir ":phonetics" en 
"-fonapi" au besoin.

On pourrait envisager un système à deux niveaux :
-  name:<lang>:pronunciation : prononciation approximative ("Quimpère", 
"George 5")
-  name:<tag_bcp7> : prononciation IPA pour les plus motivés

Quant à X-SAMPA, ça n'est pas à la portée du premier venu... Exemple 
(indice : c'est de l'anglais) :

| "@Up at n stri:t m{p s bIlt baI @ k@"mju:nIti @v m{p "drA:p at rz D at t 
k at n"trIbju:t @nd meIn"teIn "deIt@ @"baUt r at Udz | treIlz | "k{feIz | 
"reIlweI "steISn=z | @nd "mVtS mO: | O:l "@Uv@ D@ w3:ld |


Thierry

Le 28/06/2015 09:05, Philippe Verdy a écrit :
>
>
> Le 28 juin 2015 00:58, Thierry Bézecourt <thierry at thbz.org
> <mailto:thierry at thbz.org>> a écrit :
>
>     Le 28/06/2015 01:19, Jérôme Seigneuret a écrit :
>
>
>         J'ai pas encore trouvé une seule valeur utilisant le tag
>         name:fr-fonapi
>         et le fameux codage BCP47
>
>
>     Bien sûr, parce qu'OpenStreetMap utilise des tags aux noms simples
>     et compréhensibles. Personne n'utilisera des balises aux noms aussi
>     absc
>
>     ons que "fr-fonapi" ou "und-fonapi"...
>
>
> "fr-fonipa" n'est abscond que pour ceux qui ne savent pas qu'une telle
> norme existe et qui la lisent mal ou en diagonale express (en ne lisant
> qu'une phrase piquée dans le texte hors de son contexte et des
> définitions qui précèdent concernant les termes utilisés).
>
>   Quand on a compris que ce qui suit "name:*=*" est un code BCP47, on a
> accès à toutes ses variantes et on n'est pas réduit aux seul codes à 2
> lettres venus de l'ISO 649-1. Et sionon pour beaucoup même "name:fr=*"
> est abscond puisqu'ils croient à tord que cela désigne un nom pour la
> France (ils confondent codes langues et codes pays et ça donne des trucs
> aussi infames que "name:jp=*", ou encore "name:als=*" et
> "name:zh-classical" venus d'une confusion grossière entre un nom de
> sous-domaine spécifique à une édition de Wikipédia et un véritable code
> langue)
>
> BCP47 est en fait très simple et très clair, d'autant plus qu'il est
> universel (ce qui n'est pas du tout le cas de pas mal de codifications
> dans OSM qui nécessitent un apprentissage spécifique et où il n'y a
> aucune cohérence entre tags pourtants similaires !).
>
> Ce n'est pourtant pas compliqué: le premier code avant le premier tiret
> est toujours un code langue, les autres sont des extensions dans l'ordre
>
> - un code d'extension pour accéder à un code langue primaire quand le
> premier code n'est pas suffisant et que toutes les langues de cette
> famille ne sont pas mutuellement compréhensibles (code de famille
> linguistique, tels que "roa"): cette extension n'est plus utilisée
> depuis que plus de 7000 langues ont été codées dans ISO 639-3, et dans
> certains cas ces codes de regroupement étaient même faux (exemple avec
> zh-min-nan) ou de format incorrect (zh-classical, en-simple).
> - un code d'écriture (ex. ur-Arab contre ur-Deva qui est en fait
> pratiquement équivalent à hi-Deva pour le Hindi; meilleur exemple avec
> tk-Latn et tk-Arab)
> - un code de région (ex. en-US contre en-GB)
> - un code de variante orthographique ou linguistique (e.g. en-bootling):
> "fonipa" peut être utilisé ici quelque soit les codes qui précèdent, les
> variantes phonétiques sont nommées simplement par convention avec le
> sous-code "fon*"
> - des codes supplémentaires d'extension pour autre chose que la langue
> ou la convention orthographique (par exemple le tri, une préférence de
> format de dates ou de monnaie) utilisant un premier code à 1 lettre
> suivi d'un code à 2 caractères alphanum ou plus
> - des extension totalement privées et libres avec le code "x" suivi d'un
> autre code jsuqu'à 8 alphanum
>
> Ce format est immuable (il n'a en fait pas réellement bougé depuis près
> de 40 ans meˆme s'il a eu des extensions, il est resté compatible; il
> est beaucoup plus utilisé qu'OSM qui est encore extrèmement jeune et
> même plus encore que l'UCS d'Unicode et ISO/CEI 10646, ou *les* normes
> ISO 639 qui sont incompatibles entre leurs éditions sucessives, y
> compris depuis l'ISO 639-3 qui a rajouté de la complexité et de
> l'ambiguité que BCP 47 résoud complètement tout en préservant la
> compatibilité ascendante).
>
> L'algo pour résoudre les resources dans des jeux de traductions
> disponible est standardisé par BCP47 et par les données présentes dans
> la base IANA (qui définit les alias et codes préférés), ce qui permet
> aux applis de fonctionner même avec des traductions incomplètes sans
> avoir à chaque fois à afficher uniquement de l'anglais ni même obliger
> les applis à fournir une traduction anglaise complète.
>
> ----
>
> OSM reste une base de données quji sera utilisée par des outils
> techniques et les éditeurs peuvent très bien prendre en charge le nom
> des tags (iD le fait déjà sans qu'on soit obligé au prermier abord de
> coder ça correctement). OSM est destiné à être utilisé par des outils
> techniques qui feront des analyses automatiques. Autant donc choisir les
> techniques d'automatisation standarisées (déjà implantées dans de très
> nombreux logiciels pour ne pas avoir à les réécrire ou les corriger au
> fur et à mesure ce qui double le travail pour rien) car de toute façon
> on ne peut pas se passer d'une codification technique.
>
> Si on a des éditeurs pour OSM c'est justement pour ne pas avoir à tout
> coder à la main, les éditeurs se chargent de contrôler et proposer une
> interface facile. Mais sinon "name:fr-fonipa=*" reste tout à fait
> lisible une fois qu'on a compris ce que ça représente en ayant lu
> *seulement* que le code qui suit un name:* est un code BCP47 standard:
> si le code ne correspond pas à cette norme, il ne sera tout bonnement
> pas lu correctement par les outils techniques, et la donnée ne sert plus
> à rien d'autre, c'est du commentaire, qui ne sera même pas utilisé dans
> un rendu avant longtemps, et certainement jamais par un navigtateur GPS
> emabrqué lorsuq'on aura fabriqué une carte téléchargeable dessus avec
> les donénes OSM.
>
> Vouloir utiliser autre chose c'est devoir ajouter une exception qu'il va
> falloir maintenir longtemps séparément et documenter et réexpliqer à
> tous nouveau venu (comme si on n'avait pas déjà assez de spécificités à
> expliquer: c'est même de plus en plus dur pour un nouveau venu de
> rentrer dans le projet à cause des exceptions spécifiques qui se
> multiplient partout et ne suivent pas les règles standards les plus
> courantes): BCP47 est une norme universelle, plus universelle même que
> l'UCS et depuis bien plus longtemps, quand à l'ISO639 on en connait les
> limites, les ambiguités et les incompatibilités successives jamais résolues:
>
> ISO 639-2 est un patchwork informe et il y a même une erreur depuis
> longtemps dans la doc d'ISO 639-1 concernant deux codes qui ne sont même
> pas des langues mais des groupes de langues non mutuellement
> intercompréhensibles : quechua et bihari, et une énorme confusion dans
> certaines "variantes" du chinois qui n'en sont pas du tout mais sont des
> langues séparées, alors qu'en revnache indonésien et malais sont la même
> langue, au même titre que serbe, croate et bosniaque; ne parlons même
> pas du "moldave" qui n'est rien d'autre que le roumain standard juste
> transcrit temporairement en alphabet cyrillique pendant l'ère
> stalinienne, puis abandonné puisque ceux qui coutiennent le cyrillique
> en fait ne parlent pas "moldave" mais russe et que les autres parlent et
> écrivent le "moldave" non différent du roumain... Continuer à parler
> d'ISO 639 pour les usages techniques est une hérésie, cette norme n'a en
> fait été développé que pour les bibliotalistes pour indexer leurs
> collections de titres d'oeuvres dans les catalogues, même même pas pour
> codifier leur contenu réel, et même pas pour classer les livres
> eux-mêmes dans les rayonnages, et n'a aucun intérêt aujourd'hui pour le
> passage à la numérisation.
>
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>