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@n stri:t m{p s bIlt baI @ k@"mju:nIti @v m{p "drA:p@rz D@t
k@n"trIbju:t @nd meIn"teIn "deIt@ @"baUt r@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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
