vietnamien

Monde Trad
1

On y serait presque, mais je pense à une nouvelle difficulté : les accents
simples figurent dans le bas de l'unicode, ce qui signifie que le "à"
vietnamien doit être traité à la même enseigne que le "à" français (c'est le
même caractère)...

On aurait donc :
   langue <> 'vi' : pas de translittération particulière des caractères
                     vietnamiens, on laisse le comportement standard
                     de SPIP : à => 'a', a? => '.' ou 'a', selon que
                     le serveur dispose ou pas de l'extension iconv

   langue == 'vi' : translittération complexe a? => 'a3'... du coup,
                     pour la recherche, on peut ajouter un petit filtre
                     automatique histoire d'accepter comme clés de
                     recherche aussi bien &#7888; que Ô, O ou O^.

C'est dommage de devoir faire ça, mais j'ai beau retourner la question dans
tous les sens, je ne vois pas d'issue "universelle".

Cela semble en effet plus raisonnable. Rien que la support des langues latines sous unicode, cela nous aurait fait 944 entités à gérer.

Basic Latin 128
Latin-1 Supplement 128
Latin Extended-A 128
Latin Extended-B 208
Latin Extended Additional 256
IPA Extensions 96

En l'absence de solution de universelle, je propose de:
  - Remonter le tableau de translittération dans le fichier langue.
  - Idem pour un tableau de correspondance Majuscules/minuscules accentuées pour le filtre majuscules.

Je ne vois pas d'autre solution que d'adopter un mode d'indexation différent
si la langue du site est 'vi'.

Non, si je suis bien ton idée, cela revient à marquer les articles par un identifiant de langue, car sinon je ne voie pas comment gérer les conflits dans un site multilangue.

Je fais fausse route ?

Pierre

2

  - Remonter le tableau de translittération dans le fichier langue.

Non, non, c'est dans le code : tu peux avoir un site en vietnamien mais
utiliser l'interface privée en anglais :wink:

  - Idem pour un tableau de correspondance Majuscules/minuscules
     accentuées pour le filtre majuscules.

Pas la peine : pour un site en utf-8 le filtre majuscules fonctionnera dans
toutes les langues (il envoie juste un truc du genre <span text-transform:
capitals>) ; on ne garde l'ancienne fonction pour l'iso-8859-1 que par souci
de compatibilité ascendante.

>Je ne vois pas d'autre solution que d'adopter un mode d'indexation différent
>si la langue du site est 'vi'.

Non, si je suis bien ton idée, cela revient à marquer les articles par un
identifiant de langue, car sinon je ne voie pas comment gérer les conflits
dans un site multilangue. Je fais fausse route ?

Le concept de "site multilangue" n'existe pas sous SPIP :wink:

Sérieusement, pour ton site contenant du français et du vietnamien, il
faudra que tu sélectionnes "langue principale du site = vietnamien", et à ce
moment-là tu auras une indexation vietnamienne correcte, mais plus de moteur
typographique français (ce qui est préférable pour les textes en vietnamien,
je suppose). Et, de toutes façons, tu auras intérêt à travailler en utf-8.

Tu as un site de tests ?

-- Fil

3

   langue <> 'vi' : pas de translittération particulière des caractères
                     vietnamiens, on laisse le comportement standard
                     de SPIP : Ã => 'a', a? => '.' ou 'a', selon que
                     le serveur dispose ou pas de l'extension iconv

   langue == 'vi' : translittération complexe a? => 'a3'... du coup,
                     pour la recherche, on peut ajouter un petit filtre
                     automatique histoire d'accepter comme clés de
                     recherche aussi bien &#7888; que Ô, O ou O^.

C'est dommage de devoir faire ça, mais j'ai beau retourner la question
dans
tous les sens, je ne vois pas d'issue "universelle".

Est-ce que le seul vietnamien pose problème ? Je ne pense pas que des
langues comme le chinois ou le japonais permettent une translittération
"simple"...

Une autre possibilité est de ne translittérer que pour les langues où
cela n'entraîne pas d'ambiguïtés (langues occidentales + hébreu, grec,
russe... ?). Les autres langues seraient indexées en "natif", avec juste
une éventuelle transformation des caractères unicode en &#123; (ou
l'inverse).

  - Idem pour un tableau de correspondance Majuscules/minuscules accentuées
pour le filtre majuscules.

Je pense que le filtre majuscules devrait être transformé en un simple
code HTML du type <span style='test-transform: uppercase'>...</span>,
de façon à laisser le brouteur traiter le problème de la locale lui-même.
Il faut juste tester si les navigateurs récentes (Mozilla, IE) remplissent
la tâche correctement.

Non, si je suis bien ton idée, cela revient à marquer les articles par un
identifiant de langue, car sinon je ne voie pas comment gérer les conflits
dans un site multilangue.

SPIP ne gère pas les sites multilingues ;-))) Du reste cela ne dépend
que du charset, qui est global au site (le HTML ne permet pas de mixer
différents jeux de caractères).

Amicalement

Antoine.

4

Est-ce que le seul vietnamien pose problème ?

Pour l'instant, oui, pour deux raisons :

1) les mots sont très courts, il faut donc impérativement différencier les
   caractères accentués si on veut que la recherche soit discriminante

2) la graphie étant latine, il paraît en même temps "naturel" de pouvoir
   faire une recherche sur un mot sans composer les caractères

Il faut de plus que la fonction translitteration() fasse une jolie
translittération, de manière à éventuellement 1) pouvoir servir dans un
squelette. 2) être compatible avec d'autres systèmes de translittération
(donc plus facile à maintenir).

Je ne pense pas que des langues comme le chinois ou le japonais permettent
une translittération "simple"...

SPIP ne supporte ni l'un ni l'autre, pour l'instant :wink:

Une autre possibilité est de ne translittérer que pour les langues où
cela n'entraîne pas d'ambiguïtés (langues occidentales + hébreu, grec,
russe... ?). Les autres langues seraient indexées en "natif", avec juste
une éventuelle transformation des caractères unicode en &#123; (ou
l'inverse).

Non, on perdrait trop d'avantages du système actuel.

SPIP ne gère pas les sites multilingues ;-))) Du reste cela ne dépend
que du charset, qui est global au site (le HTML ne permet pas de mixer
différents jeux de caractères).

Sauf que le vietnamien fait la différence entre à et ä, ce que le français
ne fait pas : d'où le besoin d'un traitement différencié.

Mais, pas de panique, je viens de finir de le coder :wink: C'est un peu
délirant, vous allez voir... mais fonctionnel, et le code n'est pas trop
sale.

On peut chercher un mot en tapant, au choix, hien, hie^.n, hie65n ou la
version composée du même mot (un e avec un accent ^ et un . en-dessous).
Joli non ?

-- Fil

5

Je ne pense pas que des langues comme le chinois ou le japonais
permettent
une translittération "simple"...

SPIP ne supporte ni l'un ni l'autre, pour l'instant :wink:

Oui mais ce que je veux dire c'est que le problème est loin de se limiter
au vietnamien. Et il est possible (je n'en sais rien) que dans d'autres
langues à base latine, il soit crucial de conserver les accents.

Une autre possibilité est de ne translittérer que pour les langues où
cela n'entraîne pas d'ambiguïtés (langues occidentales + hébreu, grec,
russe... ?). Les autres langues seraient indexées en "natif", avec juste
une éventuelle transformation des caractères unicode en &#123; (ou
l'inverse).

Non, on perdrait trop d'avantages du système actuel.

Non pas forcément : tu peux simplement anti-translittérer le champ
"recherche" entré par l'utilisateur. Cela permet de faire un traitement
complexe sur ce champ, ce qui serait prohibitif lors de l'indexation
(gros textes => gros temps de traitement).

La translittération lors de l'indexation sert principalement à permettre
les simplifications alphabétique dans les langues où ce n'est pas
gênant.

a+

Antoine.

6

Non pas forcément : tu peux simplement anti-translittérer le champ
"recherche" entré par l'utilisateur.

Oui, c'est vrai, je n'avais pas pensé à ça...

-- Fil