Non on ne veut pas 2 noms séparés, c'est un seul et même nom contenant deux éléments.
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). 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). 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
