A mon avis il faut utiliser un pipeline de traitement pre-post propre
ou pre-post typo pour ca, mais comme je me perd completement dans ces
fonctions, je ny arrive pas.
George
Quoting Gandalf <gandalf_legris44@hotmail.com>:
Hello,
J'ai aussi remarqué que le filtre mangeait les entités HTML comportant des chiffres (typiquement le nom du mois en lettres codé en HTML), ce qui n'est pas top non plus. J'ai contournée en saucissonnant la date avant d'appliquer le filtre.
Pour les chiffres en plein texte, il y a sans doute moyen d'utiliser une expression régulière bien sentie et une autre fonction PHP au lieu de strtr, comme preg_replace pour ne remplacer que les séquences de chiffres entourés de blancs par exemple... Il faut voir si ça couvre tous les cas et si on n'a pas de séparateurs de milliers ou autres particularités typographiques dont il faut tenir compte.
GLG
P.S.: On pourrait en faire une contrib intéressante.
george@diwanalarab.com a écrit :
Hi
Puisque le sujet a ete aborde j'utilise exactement la meme fonction pour mes dates (sans la variable de mes_options mais cette variable est une tres bonne idee).
Mon probleme est que j'aimerai aussi que les chiffres des textes des articles soit en hindi aussi mais en appliquant une fonction de ce genre sur le texte, les chiffres des leins hypertexte et des notes de bas de page sont aussi convertis, et ca, ca ne va pas. Une idee?
A mon avis il faut utiliser un pipeline de traitement pre-post propre
ou pre-post typo pour ca, mais comme je me perd completement dans ces
fonctions, je ny arrive pas.
voilà donc un truc qui devrait le faire...
(testé en 2.0.3 sous php 5.2.6)
Je reviens un peu tard sur ce code mais il m'a fallu une semaine pour savoir d'ou venait le probleme:
J'ai essaye les fonctions ci-dessous sur deux sites (SPIP 2.0.3 et langue principale arabe) et certaines rubriques n'affichaient plus que des pages blanches. Apres une semaine j'ai remarque que les rubriques qui affichaient des pages blanches etaient celles qui contenaient des articles avec des notes de bas de pages (meme si l'introduction des ces articles ne contenait pas des notes de bas de page), les articles eux-memes s'affichent correctement (avec des chiffres hindi).
Accessoirement, une introduction d'un article dans une page rubrique contient un lien hypertexte qui s'est affiche:
j'ai remarque que les rubriques qui affichaient des pages blanches etaient celles qui contenaient des articles avec des notes de bas de pages (meme si l'introduction des ces articles ne contenait pas des notes de bas de page), les articles eux-memes s'affichent correctement (avec des chiffres hindi).
argh.
je n'arrive pas à reproduire avec la dist...
quel squelette est utilisé ? (la page rubrique.html)
la balise #INTRODUCTION (ou DESCRIPTIF) est présente ?
avec un filtre |couper{} ?
(les notes ne passant pas dans post_typo elles restent normalement en chiffres arabes.)
j'ai remarque que les rubriques qui affichaient des pages blanches etaient celles qui contenaient des articles avec des notes de bas de pages (meme si l'introduction des ces articles ne contenait pas des notes de bas de page), les articles eux-memes s'affichent correctement (avec des chiffres hindi).
argh.
je n'arrive pas à reproduire avec la dist...
quel squelette est utilisé ? (la page rubrique.html)
la balise #INTRODUCTION (ou DESCRIPTIF) est présente ?
avec un filtre |couper{} ?
C'est la balise #INTRODUCTION sans filtres. D'ailleurs les deux site sont:
ah mais oui mais non...
le filtre |arabe_2_hindi (|num_ar chez toi) ne doit être appliqué que sur les #DATE ! pas sur d'autres balises.
il traduit *brutalement* les chiffres qu'il rencontre car je suis parti du principe que, ne s'appliquant qu'aux dates, il n'avait pas à vérifier la présence de tag html ou d'entités html...
pour les autres chiffres dans les textes, le pipeline est suffisant... (sans avoir à ajouter de filtre donc)
pour résumer :
- pour les *textes*, rien à faire d'autre que déclarer le pipeline dans mes_options.php (les fonctions appelées par ce pipeline sont dans mes_fonctions.php)
- pour les *dates* (et spécifiquement pour elles seules), appliquer le filtre (la fonction appelée étant aussi dans mes_fonctions.php)
pour résumer :
- pour les *textes*, rien à faire d'autre que déclarer le pipeline dans mes_options.php (les fonctions appelées par ce pipeline sont dans mes_fonctions.php)
- pour les *dates* (et spécifiquement pour elles seules), appliquer le filtre (la fonction appelée étant aussi dans mes_fonctions.php)
C'est exactement ce que j'ai fait et j'ai eu le probleme des rubriques qui ne s'affichent pas. Quand j'ai parle de l'application du filtre sur les textes des articles c'etait par curiosite, pour voir ce que ca donnait.
En tout cas le probleme vient definitivement de la balise #INTRODUCTION qui contient des notes de bas de page. J'ai essaye sans cette balise et avec plein de nombre dans les titres des articles et la rubrique s'affiche.
Les tests continuent (spip 208, linux, PHP Version 4.3.9, Apache/2.0.52):
Je constate que cette méthode affecte l'espace privé aussi :
- les raccourcis spip pour les liens internes du type [texte->rub18] sont converties à tort dans le texte explicatif des rubriques. Idem pour [texte->18]
Serait-il possible de rajouter une exception dans la fonction chiffres_hindi ci-dessous pour les chaînes du type [texte->aaaXXX]
avec aaa ayant pour valeur art|article|rub|rubrique et XXX un nombre ?
Apparemment je suis trop fâché avec les regex pour proposer un patch qui marche...
Je continue mes tentatives. Voici une regex qui capture avec succès les chaînes sous la forme [texte->art18] :
^\[.*-\>(art|article|rub|rubrique)*\d+\]
Comment intégrer ça dans la fonction de denisb ? That is the question. J'essaye au hasard :
function chiffres_hindi($texte) {
if ($GLOBALS['spip_lang'] !== 'ar') {
return $texte;
}
return preg_replace_callback("|(?![^\&#]\d*;)(?!\[.*-\>(art|article|rub|rubrique)*\d+\])(?![^\<]*?\>)\d|",
"to_hindi",
$texte);
}
Ca ne marche pas : le texte explicatif de la rubrique qui contient un lien de type [texte->art18] ne s'affiche plus dans la partie privée et le traitement de la page côté public semble arrêté prématurément.
-----Message d'origine-----
De : Gandalf [mailto:gandalf_legris44@hotmail.com]
Serait-il possible de rajouter une exception dans la fonction
chiffres_hindi ci-dessous pour les chaînes du type
[texte->aaaXXX] avec aaa ayant pour valeur
art>article>rub>rubrique et XXX un nombre ?
Attention, [texte->XXX] renvoie aussi vers l'article XXX.
D'après mes souvenirs, cela dépend du contexte ; [texte->XXX] renvoie vers l'article XXX quand on est dans un article et vers la rubrique XXX si on est dans une rubrique.
La regex que je propose capture cette forme de lien aussi. Mais :
1. je n'arrive pas à l'intégrer à la fonction de denisb.
2. je ne comprends pas pourquoi la conversion déborde sur l'espace privé alors qu'elle est censée agir sur l'espace public d'après les explications de Denis.
Serait-il possible de rajouter une exception dans la fonction chiffres_hindi ci-dessous pour les chaînes du type [texte->aaaXXX]
avec aaa ayant pour valeur art|article|rub|rubrique et XXX un nombre ?
l'explication :
(?![^@]*?@) => on ne traduit pas les chiffres dans la cible des
liens [intitulé_lien->adresse_cible], mais bien ceux
de l'intitulé
(exemple : [intitulé 123->art45]
45 n'est pas traduit mais 123 oui ;
[intitulé 123|infobulle45->http://site.com/page89\]
89 n'est pas traduit ; 45 non plus mais 123 oui)
