Envoyé de mon iPad

Le 29 nov. 2012 à 16:57, Philippe Verdy <verd...@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 &mdash; 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.vysko...@gmail.com> a 
> écrit :
>> 
>> On 29 nov. 2012, at 12:45, Philippe Verdy <verd...@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
> 
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Répondre à