[OSM-talk-fr] Chiffres romains

[Philippe Verdy]

oui mais en comparant:
  name:fr-fonipa
et
  name:phonetic:fr

lequel est le plus "simple" d'après toi ?

Et demandera le moins de travail spécifiqure pour gérer les exceptions aux
règles BCP47 qui sont déjà implémentées dans des bibliothèques partagées et
qui ne demandent pas dêtre maintenaues séparément avec beaucoup moins de
développeurs disponibles pour comprendre ce qu'il en est ? OSM s'est trop
largement tenu à l'écart des normes existantes en voulant créer la sienne
sans aucun bénéfice supplémentaire.

Résultat: la lourdeur extrême d'utilisation de ses bases de données, les
requêtes ultra compliquées pour chercher les features, des scripts d'export
de plus en plus ingérables car les exceptions non maintenues (et souvent
même pas dopcumentées ni réellement décidées) se sont multipliées de façon
incohérente (et souvent même avec des incompatibilités entre elles!)

Il n'y a strictement rien à gagner à s'écarter des normes quand elles sont
suffisantes pour les problèmes à traiter. Bien au contraire ces écarts en
s'accumulant deviennent de véritables boulets qu'on traine ensuite, et qui
du fait des complications qu'ils impliquent, laissent des tas de cas
oubliés, non testés, non gérés, et des anomalies ensuite à l'utilisation.

Même Wikipédia s'en est rendu compte et maintenant uniformise ses codes
langues propriétaires défaillants vers BCP47 (il n'en reste plus beaucoup à
migrer, ils sont tous dans les tubes mais cela demande du travail non pas
dans le code MediaWiki ou son paramétrage mais dans la conversion des
stockages des bases de données, ce qui est énormément plus lourd à faire,
et la conversion de tas de scripts shelle pour la maintenance, l'addittion
de la prise en charge de divers alias pour la transition, la conservation
si possible de noms de domaines pour limiter le nombre de liens brisés...)

S'écarter des normes sans bonne raison justifiée par un bénéfice réel
(alors qu'on est face uniquement çà une spécification technique) est
toujours risquée. En fait cela n'aide même pas les utilisateurs qui au lieu
de se fier à des normes qu'ils connaissent déjà et sont utilisées ailleurs,
doivent apprendre à maitriser un tas d'exceptions purement locales : pour
eux aussi c'est une perte de temps et pour nous aussi un gachis inutile de
ressources et de moyen parce que cela aboutit ensuite à du temps perdu pour
corriger, ou apporter un support technique supplémentaire ou de la
formation. S'écarter des normes en fait les éloigne encore plus du projet
(à commencer par tous les nouveaux arrivants, ou ceux qui ont décroché
pendant un certain temps du projet et y reviennent sans être au courant
qu'il y a de nouvelles exceptions à ce qui logiquement était supposé être
une règle de base).

Le bénéfice réel serait uniquement si cela apportait quelqurechose que la
norme ne sait pas et ne peut pas gérer du tout dans son état actuel (même
dans ses extensions privées autorisées, ce dont BCP47 dispose aussi avec
les préfixes de sous-tags en "-x-", mais là il n'est même pas question
d'extension privée puisque la fonctionnalité est codifiée et déjà
normalisée de façon suffisante pour exactement même but ; une transcription
phonétique, en fait plutôt phonologique, n'est qu'une variante
ortrhographique d'une langue, elle reste même spécifique à cette langue par
rapport à son orthographe habituelle qui s'écarte souvent de la phonétiqure
pure car phonétique et écriture n'évaluent pas au même rythme : la
phonétique évolue beaucoup plus vite alors que les écrits restent là pour
longtemps et existe alors une résistance normale à l'évolution
orthographique qui fait alors apparaitre des lettres muettes, ou pas
écrites de la façon ont elles sont prononcées, ou carrément omises de
l'orthographe : orthographe et phonologie sont deux transcriptiosn de la
même langue mais l'orthographe est plus figée et plus globale que la lange
parlée réelle qui est nettement plus locale et plus restreinte dans le
temps, même sans réelle évolution orale de la grammaire ou du vocabulaire
morphologique).

De fait il existe souvent des tas de réalisations phonologiques d'une même
langue (surtout dans les langues très répandues dans le monde comme
français et anglais) et donc l'apparition de tas de variété dialectales
orales : pour simplifier un peu la phonologie tentent d'unifier certains
sons et l'API n'est utilisée que sur une partie de ses capacités dans les
transcrioptions (mais rien n'interdit pourtant d'utiliser une transcription
non pas phonlogique mais phonétique de la langue y compris avec ses
distinctions dialectales très locales, voire carrément personnelles)

Mais pour nous en s'en tient juste à la phonologie moderne la plus cournate
(celle des dictionnaires) qui devient alors une orthographe supplémentaire
de cette langue

----

(Le français a quatre orthographes officielles en France :
- 1. traditionnelle (celle de l'Académie depuis sa création tardive),
parfois avec des règles imposées juste pour limtier le nomb re de as même
si phonologiquemt elles sont fauisses.
- 2. réformée (issue de la tentative de réforme de 1990 à l'itnitiaive au
départ de la France, mlais qui est en fait plus mal passée en France
qu'ailleurs, alors que c'est en Fance que la langue est la moins bien
respectée),
- 3. phonologique API, et les dialectes oraux équicalents à cette phonologie
- 4. et la partie de la langue des signes française (LSF) qui est celle
destinée à la représentation phonologique ou orthographique et non
"idéographique par geste" de la langue et qui obéit à une syntaxe
complètement différente, très proche de la syntaxe des langues du sud-est
asiatique et du chinois par juxtaposition de concepts et adverves
contextuels dont l'ordre dans la phrase gestuelle est significatif et fairt
usage aussi de concepts d'analogie proches de ce qui est fait en chinois à
la fois dans la langue orale et dans sa forme écrite sinographique: une
caractéristique en fait de la plupart des langues des signes dont c'est la
forme normale avant d'utiliser comme paliatif les solutions épelées très
lourdes et vite remplacées par des idéogrammes gestuels: cela fait qu'il
n'est pas compliqué pour un signeur de différentes langues de parvenir à
communiquer entre eux: les langues des signes sont très "graphiques" et
basées sur des observations communes et assez universelles; les noms de
personnes sont réalisés en signes dérivés en fait de surnoms populaires, un
trait, une démarche physique ou une expression qui lui est associée, de la
mêm façon que les chinois et japonais désignent les noms de pays par des
noms assez imagés sans les traduire nécesairement par les syllabes les plus
proches dans leur phonoogie qui est beaucoup plus riche que celle qu'ils
peuvent écrire sous forme sinographique ou syllabographique) La LSF est
reconnue langue officielle (mais pas lles trascriptions phontétiques ou
phonologiques du français).


Le 28 juin 2015 04:52, Thierry Bézecourt <thierry at thbz.org> a écrit :

> 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
>>
>>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20150628/8ac0ddd2/attachment.htm>