Se dépatouiller avec des bizarreries… On se demande ce qui est bizarre ou ce qui est normal.<div><br></div><div>Il faut savoir que certaines (un certain nombre) implémentations de la reconnaissance de motifs par expressions régulières dans le monde UTF-8 (en perl, php, extension SQL et sûrement d’autres langages) permettent de reconnaître des classes de caractères : les espaces, les séparateurs, caractères de groupement (parenthèses, crochets, etc…), ponctuations, chiffres, caractères de citation, les caractères accentués, les caractères en haut de casse, etc… indépendamment de la langue ; ce sont des propriétés des caractères.</div>
<div><br></div><div>Et j’insiste sur le fait qu’il serait une erreur d’imposer l’utilisation de ces fameux caractères, puisque tout le monde ne les connaissent pas, et ne peuvent les saisir !</div><div>Mais dès lors qu’ils enrichissent les données et qu’ils peuvent être exploités, ils ne doivent pas être bannis.</div>
<div><br></div><div>Cordialement,</div><div>--</div><div><br></div>

<div class="gmail_extra"><br><br><div class="gmail_quote">Le 29 novembre 2012 15:13, Vladimir Vyskocil <span dir="ltr"><<a href="mailto:vladimir.vyskocil@gmail.com" target="_blank">vladimir.vyskocil@gmail.com</a>></span> a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 29 nov. 2012, at 12:45, Philippe Verdy <<a href="mailto:verdy_p@wanadoo.fr">verdy_p@wanadoo.fr</a>> wrote:<br>
<br>
> 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).<br>

><br>
> 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" ?<br>
><br>
> 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.<br>
><br>
> 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 !)<br>
><br>
> 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.<br>
><br>
> 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.<br>

><br>
<br>
</div>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...<br>

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 ?<br>

<span class="HOEnZb"><font color="#888888"><br>
Vladimir<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.org/listinfo/talk-fr</a><br>
</div></div></blockquote></div><br></div>