<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Le 28 juin 2015 00:58, Thierry Bézecourt <span dir="ltr"><<a href="mailto:thierry@thbz.org" target="_blank">thierry@thbz.org</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Le 28/06/2015 01:19, Jérôme Seigneuret a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
J'ai pas encore trouvé une seule valeur utilisant le tag name:fr-fonapi<br>
et le fameux codage BCP47<br>
</blockquote>
<br></span>
Bien sûr, parce qu'OpenStreetMap utilise des tags aux noms simples et compréhensibles. Personne n'utilisera des balises aux noms aussi absc </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ons que "fr-fonapi" ou "und-fonapi"...<br></blockquote><div><br></div><div>"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).</div><div><br></div><div> 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)</div><div><br></div><div>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 !).</div><div><br></div><div>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</div><div><br></div><div>- 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).</div><div>- 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)</div><div>- un code de région (ex. en-US contre en-GB)</div><div>- 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*"</div><div>- 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</div><div>- des extension totalement privées et libres avec le code "x" suivi d'un autre code jsuqu'à 8 alphanum</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>----</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>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.</div><div><br></div></div></div></div>