[OSM-talk-fr] Chiffres romains

[Philippe Verdy]

Le 28 juin 2015 00:58, Thierry Bézecourt <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.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20150628/80a036d5/attachment.htm>