Apparemment le moteur de recherche n'indexe plus les textes en persan.
Oups ?
Je
pense que, quand on demande une translittération, si le retour est vide il
ne faut pas se décourager et indexer la chaine en brut d'unicode, plutôt
qu'une chaine vide. C'était comme ça dans ma version, non ?
C'est possible, je n'ai pas un corpus multilingue énorme 
> Apparemment le moteur de recherche n'indexe plus les textes en persan.
> Je
> pense que, quand on demande une translittération, si le retour est vide il
> ne faut pas se décourager et indexer la chaine en brut d'unicode, plutôt
> qu'une chaine vide. C'était comme ça dans ma version, non ?C'est possible, je n'ai pas un corpus multilingue énorme
OK, je viens de vérifier le code, et c'est bien ça : auparavant on tentait
la translittération et si c'était concluant (pas que des '?') on conservait
la trans, sinon on gardait la chaine telle quelle (charset local du site,
probablement utf8).
On peut agir à plusieurs niveaux : translitteration() ou
nettoyer_chaine_indexation() ou indexer_chaine().
=) translitteration(), à mon sens, doit rendre ??? quand elle ne connaiot
pas le caractère demandé ; d'ailleurs elle est utilisée aussi dans
spip_image.php3 pour l'upload de fichiers aux titres accentués (et ça
marche… parfois, en fonction du brouteur)
=) nettoyer_chaine_indexation() est le meilleur candidat, je pense, car elle
assurera un traitement identique à l'indexation et à la recherche. Mais la
difficulté est de ne pas se baser sur la présence des '?' qui peuvent se
trouver dans la chaîne AVANT translittération !
De plus, comme on le passe sur l'ensemble d'un texte, la présence d'une
chaîne non translittérable dans le texte ne doit pas nous dégoûter de
translittérer ce qui est possible. (Dans ma version, on travaillait mot par
mot, mais ça devait être un peu moins rapide...)
Bref, je cherche une manière clean de procéder, mais je ne vois que des
hacks un peu crados : supprimer les ?, exploser la chaîne pour repérer les
mots, créer une chaîne reliée par un séparateur spécifique, translittérer,
reprendre les mots résultats, et en cas de '?' se rabattre sur le mot
correspondant dans l'explosion initiale. Si quelqu'un a une meilleure
solution...
(Sinon, au pire et en attendant, je ferai une table de translittération à la
mano pour le persan, mais ça n'est pas très satisfaisant...)
-- Fil
(Dans ma version, on travaillait mot par
mot, mais ça devait être un peu moins rapide...)
Plus qu'un peu, à mon avis (vu la tartine de code).
+ // se debarrasser des ?
+ $texte = strtr('?', '.', $texte);
Ca ne va pas gêner le vietnamien translittéré ?
(Sinon, au pire et en attendant, je ferai une table de translittération à la
mano pour le persan, mais ça n'est pas très satisfaisant...)
Et les tables de lynx ?
> + // se debarrasser des ?
> + $texte = strtr('?', '.', $texte);
Ca ne va pas gêner le vietnamien translittéré ?
OUPS c'est un bout de tests qui est passé dans le commit !
> (Sinon, au pire et en attendant, je ferai une table de translittération
> à la mano pour le persan, mais ça n'est pas très satisfaisant...)Et les tables de lynx ?
Je ne sais pas, je n'ai pas les idées assez claires pour trancher.
-- Fil
Deux remarques / questions:
1.
Je viens de passer de 1.6b7 à 1.6b8. Ensuite j'ai effacé les données d'indexation. Et
boum, mon SPIP ne trouve plus que les sites référencés.
J'ai remarqué qu'il ne suffit plus de visionner un article dans l'espace public pour le faire
indexer par le moteur der recherche. Seulement une fois qu'un article est mis "en cours
de rédaction" et publié à nouveau il est indexé et accessible par le moteur de
recherche.
Est-ce que mon observation est correcte? Suis-je trop impatient? Est-ce un bug?
2.
Pour un site allemand il est important de faire la différence entre les lettres uoa et les
"Umlaute" üöä (il y a encore d'autres caractères spéciaux qu'il faudrait prendre en
compte). Le moteur de recherche ne fait pas cette différence. Est-ce qu'on peut
changer cela?
Klaus.
Je viens de passer de 1.6b7 à 1.6b8. Ensuite j'ai effacé les données
d'indexation. Et boum, mon SPIP ne trouve plus que les sites référencés.
Oui, il faut qu'il réindexe : regarde l'évolution de ecrire/data/.index et
jette un oeil à ecrire/data/spip.log, tu verras comment ça fonctionne
2.
Pour un site allemand il est important de faire la différence entre les
lettres uoa et les "Umlaute" üöä (il y a encore d'autres caractères
spéciaux qu'il faudrait prendre en compte). Le moteur de recherche ne fait
pas cette différence. Est-ce qu'on peut changer cela?
Dans quel cas est-ce important de faire la différence ? Si je cherche Köln
et que le moteur indexe koln au lieu de koeln, c'est grave ?? Parce que si
on s'engage dans cette voie, il sera impossible d'indexer à la fois de
l'allemand et du français, et c'en sera fini des sites multilingues...
-- Fil
la translittération et si c'était concluant (pas que des '?') on conservait
la trans, sinon on gardait la chaine telle quelle (charset local du site,
probablement utf8).
Bon, j'ai remis le couvert sur cette question, et probablement au passage
accéléré un peu le truc. Au final quand on ne connaît pas, plutôt que de
renvoyer le ??? non indexable, mieux vaut renvoyer le mot en utf-8 ; il
sera au moins indexable et cherchable.
Ce qui serait bien, serait d'avoir une translittération de tous les
guillemets et autres symboles séparateurs, histoire de ne pas avoir trop de
mots collés...
-- Fil
accéléré un peu le truc. Au final quand on ne connaît pas, plutôt que de
renvoyer le ??? non indexable, mieux vaut renvoyer le mot en utf-8 ; il
sera au moins indexable et cherchable.
Du coup, malheureusement, on ne peut plus utiliser iconv.
Le code qui se trouve là :
// 3. Translitterer grace a iconv
if ($GLOBALS['flag_iconv'] && ereg('�*([0-9]+);', $texte)) {
$texte = iconv('utf-8', 'ascii//translit', $texte);
}
qui appelait iconv si jamais il restait un caractère au format unicode,
n'est plus invoqué (car la chaîne est en utf8).
Le problème, si on appelle iconv, c'est qu'il risque de flinguer la chaîne
en ajoutant des ? ; c'est pour ça que j'avais pris la précaution de
l'appeler caractère (inconnu) par caractère...
-- Fil
Le code qui se trouve là :
// 3. Translitterer grace a iconv
if ($GLOBALS['flag_iconv'] && ereg('�*([0-9]+);', $texte)) {
$texte = iconv('utf-8', 'ascii//translit', $texte);
}qui appelait iconv si jamais il restait un caractère au format unicode,
n'est plus invoqué (car la chaîne est en utf8).
Heu, c'est quoi l'intérêt de passer en utf-8 ?
Heu, c'est quoi l'intérêt de passer en utf-8 ?
Oui, tu as raison ; c'est que je ne voulais pas abandonner iconv(), mais
effectivement on peut travailler en unicode ça marchera aussi bien.
Moment...
-- Fil
> Heu, c'est quoi l'intérêt de passer en utf-8 ?
Ah non, voilà, j'ai retrouvé : quand tu indexes du persan,
si translitteration() te renvoie Ӓӓetc...., le truc qui ensuite
coupe le texte en mots va couper sur les ;, et casser tes mots. En
utf-8 ça tient le choc.
Du coup dans la table spip_index_dico, tu as :
ÙÙدا٠| (un mot persan, stocké en utf-8)
m6___ | (un sigle)
philippe | (un mot latin)
-- Fil
Tu n'en est qu'au début de ton cauchemard Fil.
En norvégien le "aa" est une lettre à part entière, rigoureusement égale au å
Si tu cherche le no de tel de ton ami "flaarønning" dans l'annuaire
téléphonique, tu le trouveras classé après FLZ, encadré par des flaar et flår
T'y avait pensé à cela quand tu indexes ?