<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Le 26 juin 2015 21:26, Jérôme Seigneuret <span dir="ltr"><<a href="mailto:jseigneuret-pro@yahoo.fr" target="_blank">jseigneuret-pro@yahoo.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>@Philippe :<div>Le alt_name n'est pas la solution car par défaut il n'est pas prioritaire vu que c'est name qui l'est</div></div></div></blockquote><div><br></div><div>Il n'y a pas de priorité : "alt_name=*" complète le "name=*" en y ajoutant de la sémantique. Il ne la remplace pas comme le font entre eux les "name:lang=*"</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>- les tag name et name* avec les priorités utilisés pour le guidage vocal de l'application,</div></div></div></blockquote><div>Pas de priorité, s'il y a ambiguité pour lire un name=* (après avoir sélectionné la langue) les autres noms alt_name=* sont encore accessibles pour lever ces ambiguités : si la seule différence entre les deux porte entre "V" et "5" on a une interprétation non ambigue.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div> </div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>- quel est l'algo d'interprétation utilisé par l'appli GPS (dixit le message de Philippe sur le CLDR)</div></div></div></blockquote><div><br></div><div>Tu mélanges deux choses séparées:</div><div> </div><div>- d'une part il y a l'algo de reconnaissance qui peut détecter certains petits "mots" formés uniquement de lettres latines formant un nombre romain.</div><div><br></div><div>- d'autre part il y a l'algo décrit dans CLDR permettant de convertir un nombre au format romain.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>- CLDR est-il capable de lire une chaîne date en chiffre romain (Pour voir si un cas un peu tordu est bien traité). Perso j'ai pas testé et je pense que ça dépend du langage de programmation utilisé et de l'intégration des évolution de la dite norme.</div></div></div></blockquote><div><br></div><div>CLDR décrit l'algo entièrement dans les DEUX sens avec un système de règles de conversion et substitution (au format "RBNF", "Rule-Based Number Format").</div><div>Et c'est bel et bien utilisé dans la bibliothèque ICU (et d'autres qui savent lire les règles RBNF).</div><div><br></div><div>On n'est pas obligé d'utiliser un moteur de règles RBNF pour écrire ou décoder un nombre romain mais les règles utilisées devraient fonctioner de façon équivalente. Mais sans moteru RBNF on ne pourra pas traiter correctement toutes les données CLDR (il faudra en revanche reconnaitre les noms symboliques de formats de nombres romains), mais un moteur RBNF est indispensable pour pouvoir épeler un nombre en mots dans de nombreuses langues (et aussi pouvoir les convertir en sens inverse)</div><div><br></div></div></div></div>