J'ai 2 premières questions :

1/ Qu'est ce qui change pour réaliser un fichier en Utf-8 ? (je ne voie pas de différence dans les nouveaux fichiers)
Est ce que la façon de rentrer les champs $lang['ggg'] reste la même ?

2/ Si je change dans mon éditeur de texte en Utf-8 mes fichiers langues espagnol tout mes o, a avec accent sont remplacer par des "merdes" il y a t-il une autre manip que la patience pour reprendre toute les lignes (faut il que je change d’éditeur Notepad++)

Merci

ddtddt a écrit:

J'ai 2 premières questions :

1/ Qu'est ce qui change pour réaliser un fichier en Utf-8 ? (je ne voie pas de différence dans les nouveaux fichiers)
Est ce que la façon de rentrer les champs $lang['ggg'] reste la même ?

2/ Si je change dans mon éditeur de texte en Utf-8 mes fichiers langues espagnol tout mes o, a avec accent sont remplacer par des "merdes" il y a t-il une autre manip que la patience pour reprendre toute les lignes (faut il que je change d’éditeur Notepad++)

Merci

1: les éè vont se transformer en double caractère
2:Tu prends ton fichier, tu sélectionnes tout, tu fais un copier, tu le convertis en UTF8, tu fais un coller .
Ca devrait le faire!

J'ai testé le message:

Hello!
Bonjour!
مرحبا!
Здрав??твулте!!

lors de la notification et le test n'est pas concluant pour le texte ajouté (le reste est ok).

A suivre donc! Je vais creuser!

Concernant les IPTC, je viens de tester car j'ai vu que la révision 2132 apportait des modifications à ce sujet.
Testé avec quelques photos en latin1 et utf-8, tout est passé sans problème.

Rien à voir, mais j'ai constamment deux avertissements dans la zone admi :

Warning: array_merge() [function.array-merge]: Argument #2 is not an array in /media/sda3/sites/bacasable/photos/include/functions.inc.php on line 1603

Warning: Cannot modify header information - headers already sent by (output started at /media/sda3/sites/bacasable/photos/include/functions.inc.php:1603) in /media/sda3/sites/bacasable/photos/include/page_header.php on line 102

La ligne 1603 étant :

$lang_info = array_merge( $lang_info, $load_lang_info );

Dernière modification par galain (2007-10-10 09:39:02)

load_language:
o en php5: il y a la soucis du array_merge
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à?

rvelices a écrit:

en fait j'avais fait express... histoire que peut etre un jour on utilise des vrais fichiers de localization (gettext)...

Est-ce que tu sais s'il existe une appli web qui permettrait de maintenir à jour en coopératif les fichiers .po ?
Genre Wiki... vois-tu?

8-)

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)...

Oui d'accord si l'extension n'est pas la, mais sinon il faudrait peut-être éviter de rajouter l'extention ".php".
Ensuite par défaut ajoutons en php ou en po si pas d'extension!

Je connaissais pas le .po et .mo, ca semble bien tout ca!

[HS = réponse à VDigital]

Je vais essayer de donner une réponse cohérente (j'ai plein d'idée dans la tête cela va être dur).

1/ Je suis allé (et je vais) sur svn et il me semble que cela est un belle outil qui devrai être suffisant. Cependant j'aurai besoin d'aide car je n'ai pas tout compris et il n'est pas toujours facile de poser des questions en se disant "la réponse doit être toute simple, il faut que j'ouvre les yeux".
Pour les \, oubli un %s c’est aussi au traducteur d’être rigoureux comme doivent l’être les programmateur.
Le 2ème problème c'est ce que je faits aujourd'hui de mes fichier pour la 1.8 ou 1.7.1 une fois que je les ai traduits !
Intérêts supplémentaires :
-    je suis responsable de mes fichiers si il y a une erreur on sais d’où cela viens et plus facile à corriger ;
-    En montant une galerie en 1.7.1 et une en 1.8 je peut tester mes fichiers avant de les donner à la collectivité (cela supprime les premiers défaut qui bloque le système).

2/ L’idée de Vincent semble intéressante. Cela permettrai peut être plus facilement de traduire dans plus de langues.
Cela permettrait de ne rien oublier (car on ne regarde que dans la partie langue pour traduire)
Cela permettrai de vérifier les traductions (un français qui traduit dans un langue étrangère loupe toujours des subtilités) et peut être plus rapidement dispos.

3/ Il me semble que tout le monde est bénévole est a du temps limité. Le plus difficile étant, a mon sens de rentrer et programmer pour PWG. (je suis toujours en phase d'observation de la programmation sans m'être encore lancer dans des plugins ) Il ne faut donc pas qu’un nouveau système ralentisse le développement.

Mon point de vu (je croix que c’était ça la question) :
-    Si cela prend plus de temps pour les développeurs et programmateur il ne faut pas le faire et donner une petite formation rapide au traducteur (promis mathiasm il font des recherche avant) qui je pense devrai y arriver ;
-    Si cela ne prend pas plus de temps pour les développeur et programmateur il faut réfléchir et essayer de mettre en place la solution de Vincent pour augmenter et développer la traduction de PWG, pour gagner en rapidité et en qualité de traduction.

PS : j’espère que ma réponse n’est pas trop confuse car j’ai rajouté des éléments en cours de rédaction.
PS2 : j’ai quand même 2/3 notions d’informatique et je ne suis pas effrayé par svn ce qui n’est et ne sera pas forcement le cas de tous les traducteurs.
[/hs]

Dernière modification par ddtddt (2007-10-11 21:57:22)