liste étrange format modèle dans locale CLDR-arabe

Question

Je l'ai observé dans CLDR-25 les données suivantes entrées pour les formats de modèle de liste dans locale arabe (similaires également Hebrew):

<listPatterns> 
    <listPattern> 
    <listPatternPart type="start" draft="contributed">{0}، {1}</listPatternPart> 
    <listPatternPart type="middle" draft="contributed">{0}، {1}</listPatternPart> 
    <listPatternPart type="end" draft="contributed">{0}، و {1}</listPatternPart> 
    <listPatternPart type="2" draft="contributed">{0} و {1}</listPatternPart> 
    </listPattern> 
</listPatterns> 

Notez que la LDML spécification ne parle que des espaces réservés de la forme "{0}" ou "{1}" (pas comme dans les parties de modèle de liste pour les types "fin" et "2"). Voir aussi:

http://cldr.unicode.org/development/development-process/design-proposals/list-formatting

ou

http://cldr.unicode.org/translation/lists

Je soupçonne que cela a quelque chose à voir avec le style de droite à gauche, mais comment en détail?

---

MISE À JOUR:

Maintenant, je l'ai écrit un petit programme Java pour voir la séquence réelle des caractères.

String s = "{0} و {1}"; // as displayed in browser or IDE-window 
for (char c : s.toCharArray()) { 
    System.out.println(c); 
} 

La sortie est:

{ 
0 
} 

و 

{ 
1 
} 

Il semble y avoir un problème d'affichage, pas un problème de la séquence char lui-même ?! J'utilise Internet Explorer version 9 et Eclipse 4.3.

Answer 1

La séquence de carbonisation est ici (en codepoints):

123=>{ 
48=>0 
125=>} 
32=> 
1608=>و // DIRECTIONALITY_RIGHT_TO_LEFT_ARABIC=true 
32=> 
123=>{ 
49=>1 
125=>} 

Unicode en déduit le style d'affichage également d'évaluer le contexte bidirectionnel. Donc ici l'algorithme unicode semble appliquer d'abord le contexte LTR standard aux premiers caractères trouvés - conservant ainsi la séquence de caractères "{0}".

Lorsque l'algorithme entre dans le caractère arabe, il indique son statut bidirectionnel et l'applique aux caractères suivants suivants. Selon le official paper of W3C cela signifie:

La forme du glyphe de parenthèse d'ouverture "{" devient "}" dans le contexte RTL (de droite à gauche). Ainsi, du point de vue du caractère arabe, la suite du caractère arabe est "1}", ce qui équivaut à la forme habituelle du LTR "{1". Après avoir lu l'ASCII-char "1", l'algorithme Unicode évalue que le contexte est de nouveau LTR, affichant ainsi le crochet de fermeture sous la forme normale "}". Le résultat visuel final (mais pas en termes de points de code cependant) est alors comme s'il y avait une parenthèse fermante supplémentaire et une parenthèse ouvrante moins.

J'espère que les lecteurs SO trouveront cette explication utile s'ils rencontrent des effets visuels étranges similaires dans un contexte bidirectionnel.