[OSM-talk-fr] Suppression des tirets cadratins

[Vladimir Vyskocil]

Envoyé de mon iPad

Le 29 nov. 2012 à 16:57, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :

> Non on ne veut pas 2 noms séparés, c'est un seul et même nom contenant deux éléments.

Oui c'est ce que j'ai dit un nom "multi-valué" que le moteur de rendu pourra très bien afficher nom1 – nom2 par exemple.

> 
> Et les moteurs de recherche n'ont strictement aucun problème avec ces caractères qui ne sont pas des "curiosités françaises" mais présents par défaut dans de nombreux protocoles, supportés par des encodages essentiels (dont windows-1252 qui est le seul encodage par défaut d'HTML5, et UTF-8 qui est le seul encodage par défaut d'XML et XHTML), présents dans toutes les polices latines non restreintes à l'ASCII (et un très grand nombre de polices d'autres écritures).

C'est surtout ceux qui cherchent qui peuvent avoir des soucis s'ils doivent utiliser le bon tiret ou le bon espace. 

> 
> Ils ont d'autant moins de problème que les moteurs de recherche ont des standards pour ça, je le répète: UCA et une norme ISO équivalente. Ils ont été dans toutes les versions de CLDR, et même indiqués comme partie prenante des ponctuations essentielles non seulement au français mais aussi à l'anglais (même si les anciens claviers ne peuvent pas toujours les saisir, il a toujours existé d'autres moyens que la saisie directe au clavier, même pour ceux qui travaillent les fichiers XML pour OSM dans un éditeur de texte basique, avec des entités de caractères — ou entités numériques Unicode).

Oui sûrement, mais on parle de gens qui ne savent même pas que ceci existe.

> 
> Il y a même moins de complication à les utiliser que les caractères accentués français pour les recherches ou le tri (là encore lire ce qu'en dit le standard de "collation" UCA, ou la norme ISO équivalente ou la norme française NF). Même avec une collation la plus basique (à un seul niveau, c'est plus simple que les lettres accentuées françaises), la complication est en faitdu même ordre quand on se reporte uniquement à la ponctuation ASCII.
> 
> 
> 
> 
> Le 29 novembre 2012 15:13, Vladimir Vyskocil <vladimir.vyskocil at gmail.com> a écrit :
>> 
>> On 29 nov. 2012, at 12:45, Philippe Verdy <verdy_p at wanadoo.fr> wrote:
>> 
>> > Ce qui se complique encore quand les toponymes ***officiels*** espagnols utilisent le "/" pour séparer les noms ***co-officiels*** issus de plusieurs langues, ces deux langues ***devant*** toujours être citées ensembles et dans l'ordre indiqué sans qu'on puisse en supprimer un ! C'est alors le même toponyme dans les langues d'origine, les différences linguistiques étant alors abolies dans la dénomination officielle pour la même entité (regardez le Pays Basque espagnol par exemple).
>> >
>> > Dans ce cas le "/" ne signifie pas non plus "sur", ***même*** en Français. Comment alors faire un traitement automatique de substitution "pour faire joli" ?
>> >
>> > Oui effectivement le "/" a sa propre sémantique dans ce cas, mais on ne doit PAS l'utiliser comme s'il s'agissait d'une abréviation, même en français.
>> >
>> > Bref en aucun cas "Argenton / Creuse" ne signifie la même chose que "Argenton-sur-Creuse" (ne pas oublier non plus les traits d'union ici !)
>> >
>> > Car en Espagne et même en français, ce "/" est un séparateur, distingué de l'autre séparateur trait d'union qui est aussi utilisé pour juxtaposer deux termes mais avec une autre signification.
>> >
>> > L'idée qu'un moteur de rendu peut librement remplacer la ponctuation est totalement erronée, chacune a sa signification propre mais on ne peut pas la déduire de la seule façon dont cette ponctuation est codée puisque pour cela il faudrait coder ***aussi*** la sémantique.
>> >
>> 
>> Dans ce cas c'est le schema qui n'est pas bon et on aurait du partir par exemple sur un tag name multi-valué alors que l'on est clairement parti sur une solution simpliste qui revient a tagguer pour le rendu : on veut que les 2 noms s'affichent côte à côte séparés par un caractère lambda sans rien a avoir a changer aux moteurs de rendu actuels...
>> Il faut également prendre en compte tous les outils de recherche qui vont faire comment pour se dépatouiller avec des données formatés avec des demi-espaces insécables ou je ne sais quelle curiosité de la langue française ?
>> 
>> Vladimir
> 
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20121129/27f69061/attachment.htm>