On devrait changer de post! Ca devient HS!
Je suis d'accord avec VDigital et pleins de d&t.
D'ailleurs, ca reprend ce qui a été dit dans un post privé.
Mais, c'est un "sacré" chantier.
Vu qu'on est en UTF8, je pense qu'une solution light, serait un plugin comme LocalFileEditor.
Avantages:
o simple à implémenter
o permet de tester
o ...
Ensuite, allons vers une solution (.po.mo (de douche)) centralisé au niveau de PWG et permettant les traductions des $lang et des helps!
Hors ligne
rvelices a écrit:
rub a écrit:
o en php5: il y a la soucis du array_merge
je corrige ce soir
rub a écrit:
o lorsque l'on passe un fichier du style load_language('plugin.lang.php', DYNARECEPERIO_PATH), il faudrait peut-être ne pas rajouté l'extension php si elle existe déjà?
en fait j'avais fait express... histoire que peut etre un jour on utilise des vrais fichiers de localization (gettext)...
L'avantage de l'édition en ligne des fichiers de localisation est l'assurance d'avoir une saisie en utf-8.
Exemple: http://pootle.wordforge.org/projects/pootle/
Hors ligne
ddtddt je ne veux plus polluer le topic de l'utf-8...
Je posais et répondais à l'axe utf-8 de rvelices.
Pour parler de pootle... J'ouvre un autre topic.
8-)
Hors ligne
Le problème pour la NBM (caractéres incorrect dans le mail en HTML) est le même soucis que celui corrigé par rvelices pour les commentaires.
htmlentities remplacé par htmlspecialchars.
rvelices sait si le problème est présent sur toutes les versions de php? Pourquoi cette différence?
J'ai fait le test en passant le charset à la fonction,
htmlentities($customize_mail_content, ENT_COMPAT, "UTF-8")
et ca fonctionne aussi.
Il reste encore des htmlentities dans le code.
Faut-il mieux ?
o remplacer les htmlentities par des htmlspecialchars
o passer le charset aux fonctions htmlentities
Hors ligne
rub, tu peux télécharger LocalFiles Editor compatible avec la 1.8 ici.
Pour UpToD@te, c'est ici.
Dis-moi si ca fonctionne bien... je convertirai d'autres plugins...
PS: j'ai converti les fichiers plugin.lang.php en UTF8 sans BOM... et j'ai aussi converti le fichier tpl et le fichier main.inc.php pour les infos du plugin (je ne sais pas si c'est nécessaire)
J'ai également utilisé le code que tu m'as donné pour inclure le fichier langue.
Dernière modification par P@t (2007-10-17 19:53:18)
Hors ligne
sur ma galerie de test en 1.8 en langue espagnol pas de problème rev 2040 pour aucun des 2
Hors ligne
Ca fonctionne impec en 1.7 et BSF!
Normalement, tu dois convertir uniquement:
o les fichiers de traductions
o le main.inc.php s'il y a des descriptions accentuées utilisées dans la liste des plugins
Hors ligne
P@t a écrit:
rub a écrit:
Ca fonctionne impec en 1.7 et BSF!
Pas sur le site de démo en tout cas ;-)
Voila, c'est fait!
Par contre, il faudrait qu'en mode adviser on ne puisse pas valider.
Le bouton est grisé mais ce n'est pas suffisant, il faut ajouter is_adviser() pour annuler le post!
Hors ligne
Je suis entrain de vérifier mes fichiers langue.
J’utilise Notepad++. J’utilise l’option « encoder en UTF-8 (sans BOM) ».
En affichant les pages html le résultat n’est pas celui que j’attendais. Pour vous dire toute la vérité c’était mieux en ANSI ! :-((
"La traduzione italiana è stata fatta"
ai lieu de
"La traduzione italiana è stata fatta"
Une idée?
Hors ligne
quand tu ouvres le fichier en UTF-8 dans notepad++, les caractères bizarres sont là ?
Hors ligne
Non justement. En text avec Notepad++ ça s'affiche correctement.
En html avec IE : "La traduzione italiana è stata fatta"
En txt avec N++ : "La traduzione italiana è stata fatta"
Le problème c'est que c'est une page HTML ...
:-/
Hors ligne
et tu as bien <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> dans le code source du fichier HTML ?
Dernière modification par grum (2007-10-27 21:33:30)
Hors ligne
Maintenant oui et c'est ok.
Je comprends mieux!
Merci
:-))
Hors ligne