Si tu veux des fichiers de langue en unicode, on modifie la fonction
d'export de trad_lang (ça nous facilitera la vie, d'ailleurs) ; mais ne
passons pas chaque chaine dans html2unicode, ça va vraiment ramer.
Cela dit, il y a un ou deux détails à vérifier de toute façon :
1) fait-on usage de la fonction majuscules(_T('...')) ?
2) pourquoi ne pas les coder en utf-8 plutôt ? (ça ramera un peu sur les
sites en iso-latin, mais ça sera plus léger en mémoire et en espace
disque)
1) fait-on usage de la fonction majuscules(_T('...')) ?
2) pourquoi ne pas les coder en utf-8 plutôt ? (ça ramera un peu sur les
sites en iso-latin, mais ça sera plus léger en mémoire et en espace
disque)
Y a surtout le problème des clients FTP qui transfèrent certains
fichiers en essayant de "réécrire" les accents, ou en utilisant le mode
Ascii, ce qui provoque des bugs qui ont le don de dérouter les
débutants. Historiquement c'est pour ça qu'on a codé tous les accents
avec des entités HTML.
Sinon, oui, la fonction _T() devrait être la plus rapide possible...
Y a surtout le problème des clients FTP qui transfèrent certains
fichiers en essayant de "réécrire" les accents, ou en utilisant le mode
Ascii, ce qui provoque des bugs qui ont le don de dérouter les
débutants. Historiquement c'est pour ça qu'on a codé tous les accents
avec des entités HTML.
Il faudrait d'abord voir si le problème est toujours problématique ; mais on
peut aussi peut-être le contourner de manière assez simple en donnant aux
fichiers de langue un nom autre que .php3 ?
Si tu veux des fichiers de langue en unicode, ...
(...)
pourquoi ne pas les coder en utf-8 plutôt ? (ça ramera un peu sur les
sites en iso-latin, mais ça sera plus léger en mémoire et en espace
disque)
O oui, stp !
Et cela faciliterait la maintenance / première traduction des fichiers que
nous pourrions désormais éditer avec n'importe quel éditeur de texte
compatible UTF-8.
> Y a surtout le problème des clients FTP qui transfèrent certains
> fichiers en essayant de "réécrire" les accents, ou en utilisant le mode
> Ascii, ce qui provoque des bugs qui ont le don de dérouter les
> débutants. Historiquement c'est pour ça qu'on a codé tous les accents
> avec des entités HTML.
Il faudrait d'abord voir si le problème est toujours problématique ; mais on
peut aussi peut-être le contourner de manière assez simple en donnant aux
fichiers de langue un nom autre que .php3 ?
A mon avis, le problème n'a pas disparu, vu que les clients FTP grand
public ont dû assez peu changer en quelques années...
D'autre part, c'est le seul moyen de ne pas convertir le charset à
chaque appel de _T, ce qui est assez coûteux en temps machine (il y a au
moins autant de sites en iso-latin qu'en utf-8).
Autre idée, peut-être plus simple : n'appeler ces machins de conversion que
si $GLOBALS['xhtml'] == true et tidy pas dispo [sinon laisser tidy s'en
occuper).
Mais pour tidy, c'est justement parce que les formulaires de l'espace public balancent leur code directos, après tidy.
-> Tidy passe sur le cache, et non plus en global quand on répond au client. (Sinon les perfs, là...).
-> Du coup, tout ce qui est balancé au moment où on envoie au client, ça ne passe pas par Tidy.
=> C'est pour ça, d'ailleurs, que j'ai passé beaucoup de temps à nettoyer le code des formulaires: ils ne passent pas par Tidy, donc ils doivent être nickels d'origine...