Salut,
j'intègre le support du charset windows-1251 dans SPIP. Question : est-ce
que je le mets au même niveau que l'iso-latin et l'utf-8, dans la
configuration du site, ou est-ce qu'on le laisse comme une feature masquée ?
-- Fil
Plutôt masqué, ce n'est pas un standard ("windows-"). C'est quoi
le charset ISO pour le russe ? Qu'est-ce qui empêche de l'utiliser ?
a+
Antoine.
Plutôt masqué, ce n'est pas un standard ("windows-"). C'est quoi
le charset ISO pour le russe ? Qu'est-ce qui empêche de l'utiliser ?
Les anciens navigateurs connaissent 'windows-1251', les nouveaux l'utf-8;
c'est donc plus par souci de compatibilité maxi que de respect des standards
que les Russes continuent à utiliser ce charset (à ce que j'en ai compris).
Autre avantage, j'ai codé la translittération pour ce charset... je pourrais
changer de tactique, et tout coder en utf-8 (y compris la translittération
du bout de russe dans l'utf-8), puis faire un 'kodo' à la volée pour les
anciens navigateurs... ça serait un peu de boulot, mais peut-être plus
conforme à l'iso-truc... Qu'en pensez-vous ?
-- Fil
> Plutôt masqué, ce n'est pas un standard ("windows-"). C'est quoi
> le charset ISO pour le russe ? Qu'est-ce qui empêche de l'utiliser ?Les anciens navigateurs connaissent 'windows-1251', les nouveaux l'utf-8;
c'est donc plus par souci de compatibilité maxi que de respect des
standards que les Russes continuent à utiliser ce charset (à ce que j'en ai
compris).
Le charset le plus utilisé chez les russes, c'est KOI8-R
Ph.
> Le charset le plus utilisé chez les russes, c'est KOI8-R
Cf. http://czyborra.com/charsets/cyrillic.html
Tout ça me donne une idée : pour le support de tous les charsets 8bits (sauf
iso-8859-1, notre charset de référence) il suffirait d'extraire les données
de conversion du code actuel et de le mettre dans un fichier texte dans le
répertoire lang/, et ce serait bon.
Exemple : le charset windows-1251 serait "supporté" par SPIP à condition
qu'un fichier charset_windows_1251.txt se trouve dans lang/ et contienne une
liste complète des code + équivalent unicode + translittération, de la façon
suivante :
#code unicode translitteration
129 1027 G
131 1107 D
...
Pour "charger" un code il suffit alors de lire ce petit fichier et hop. La
partie translittération sert à nourrir le moteur de recherche, et
éventuellement à afficher le texte en "translittéré" -- pour le wap ;-).
Seule inconnue, comment décrire les caractères "interdits" : ceux qui
servent à délimiter des mots (guillemets, etc...) ; ceux qu'il faut
nettoyer.
Ensuite, dans la configuration de SPIP, on propose autant de charsets qu'on
arrive à lire de fichiers dans lang... ou on décide de laisser ça
relativement "secret", sachant que le support utf-8 est le plus important ?
-- Fil
Tout ça me donne une idée : pour le support de tous les charsets 8bits (sauf
iso-8859-1, notre charset de référence) il suffirait d'extraire les données
de conversion du code actuel et de le mettre dans un fichier texte dans le
répertoire lang/, et ce serait bon.Exemple : le charset windows-1251 serait "supporté" par SPIP à condition
qu'un fichier charset_windows_1251.txt se trouve dans lang/ et contienne une
liste complète des code + équivalent unicode + translittération, de la façon
suivante :#code unicode translitteration
129 1027 G
131 1107 D
...
Autant faire un tableau PHP dans le même style que les spip_fr.php3 :
$GLOBALS['charset_unicode'] = array(
129 => 1027,
...
);
$GLOBALS['charset_translitteration'] = array(
129 => 'G',
...
);
Bon, mais je n'ai pas d'avis sur l'importance et la priorité de la
chose.
Autant faire un tableau PHP dans le même style que les spip_fr.php3 :
$GLOBALS['charset_unicode'] = array(
129 => 1027,
...
);
Pas faux. Le format CSV a l'avantage d'être relativement standard (si tu vas
sur l'URL susmentionnée concernant les charsets russes, il y a pas mal de
ces tableaux). Mais le format php marchera aussi, et sera peut-être plus
adaptable si jamais il y a d'autres éléments à prendre en compte par la
suite.
-- Fil
> Autant faire un tableau PHP dans le même style que les spip_fr.php3 :
> $GLOBALS['charset_unicode'] = array(
> 129 => 1027,
> ...
> );
A y re-réfléchir, le charset devrait donner uniquement les paires
code-unicode ; pour la translittération, il faut plutôt la faire au niveau
d'unicode-translit, ce qui permettra à une même translittération de
s'appliquer à tous les charsets. Une fois que je sais translittérer tous les
caractères cyrilliques, le moteur de recherche marchera donc, pour les
caractères cyrilliques, que je me trouve en utf-8, en KOI8-R, en
windows-1251 -- voire même en iso8859-1 en ayant des caractères marqués
Ӓ !
a +
-- Fil