VDigital a écrit:

1 upgrades to apply

=== upgrade 65
>>user_lang    fr_FR.iso-8859-1    3

>>admin_charset    iso-8859-1
>>mysql_ver    5.0.45-community-nt
< conversion    change utf8

"PWG charset migration" ended

Et "Voyons voir ce UTF-8 une œuvre remarquable de rvelices?" Exactly! Incredible! So many thanks...
8-)

Migration réussi en:
  PHP: 4.3.10
  MySQL: 4.1.9-max

1 upgrades to apply

=== upgrade 65
>>user_lang  en_UK.iso-8859-1  31
>>user_lang  fr_FR.iso-8859-1  1

>>admin_charset  iso-8859-1
>>mysql_ver  4.1.9-max
< conversion  change utf8

"PWG charset migration" ended

rub a écrit:

J'ai pas encore migré mais j'ai quand même des petites remarques:

je suis alle un peu vite, alors si ce n'est que quelques remarques, c'est plutot tres bon signe :-)

rub a écrit:

o get_language_filepath est garder pour compatibilité, on ne devrait pas la supprimer?
    Ou tu compter le faire par la suite en attendant qu'on s'adapte!
  o Pourquoi ne pas appeler la méthode load_language dans la méthode get_language_filepath?

en fait il faudrait supprimer l'ancien. ou effectivement retourner toujours false et appeler load_langugae (pour avoir une compatibilite ascedente)

rub a écrit:

o Pourquoi ne pas utliser aussi get_default_language dans la méthode load_language (comme dans la méthode get_language_filepath)

oubli de ma part

rub a écrit:

o Pourquoi s'embete à tester "universal language"? C'est à dire le ascii 7 bits ou l'asciiUS?

je comptais renommer le repertoire en_UK.iso-8859-1 en en_UK - histoire d'avoir un seul repertoire qui ne necessite pas un transcodage interne que l'on soit en iso-8859-xxxx ou utf-8

VDigital a écrit:

Ça va que nous sommes habitués à lire tes messages sans accent.
Pour quelqu'un qui met tout en oeuvre pour conserver nos accents, tu dois en surprendre plus d'un.

:-)

rvelices a écrit:

rub a écrit:

J'ai pas encore migré mais j'ai quand même des petites remarques:

je suis alle un peu vite, alors si ce n'est que quelques remarques, c'est plutot tres bon signe :-)

;-)

rvelices a écrit:

rub a écrit:

o get_language_filepath est garder pour compatibilité, on ne devrait pas la supprimer?
    Ou tu compter le faire par la suite en attendant qu'on s'adapte!
  o Pourquoi ne pas appeler la méthode load_language dans la méthode get_language_filepath?

en fait il faudrait supprimer l'ancien. ou effectivement retourner toujours false et appeler load_langugae (pour avoir une compatibilite ascedente)

Moi, je suis pour la supprimer ca ne sert à rien au sein de PWG de garder des versions obsolétes.

rvelices a écrit:

rub a écrit:

o Pourquoi ne pas utliser aussi get_default_language dans la méthode load_language (comme dans la méthode get_language_filepath)

oubli de ma part

D'ailleurs, vu que le charset n'est plus au niveau utlisateur, je fais faire qqes modifs sur les fonctions mails. (Supprimer de la dimension "charset" dans les tableaux).

rvelices a écrit:

rub a écrit:

o Pourquoi s'embete à tester "universal language"? C'est à dire le ascii 7 bits ou l'asciiUS?

je comptais renommer le repertoire en_UK.iso-8859-1 en en_UK - histoire d'avoir un seul repertoire qui ne necessite pas un transcodage interne que l'on soit en iso-8859-xxxx ou utf-8

J'aime pas trop!
Et si je veux mettre ½ ou ¾ ou ¿ ou Ø ou ß dans mes traductions en anglais, comment je fais?

rvelices a écrit:

rub a écrit:

Et si je veux mettre ½ ou ¾ ou ¿ ou Ø ou ß dans mes traductions en anglais, comment je fais?

&frac12; &frac34; &iquest; &Oslash; &szlig;

Pour de l'HTML mais pour l'envoi, par exemple, d'un message en texte brut?

rvelices a écrit:

si ce n'est pas acceptable, on doit effectivement definir en_UK.utf-8 ... je voulais juste nous simplifier la tache et ne pas devoir maintainir 2 repertoires en_UK.iso-8859-1 et en_UK.utf-8 ou eviter les conversions internes pwg...

Pas 2 répertoires par langue! Surtout pas!
Pourquoi, tu ne veux pas qu'on mette tout en UTF-8 pour le langues.
Car:
  1: Rien à faire pour l'anglais car quelque soit la norme UTF8, IS0-8859-1, ASCIIUS, ASCII 7 bits, c'est pareil (à mes exemples près)
  2: Pour le français, notepad, scite, ... gére l'encodage en UTF8 => pas de sousis pour maintenir des fichiers en UTF8

z0rglub a écrit:

Je continue à être d'accord avec Rub. Les valeurs dans les fichiers de langue peuvent être écrit directement en utf-8. Les éditeurs de texte récent gèrent parfaitement l'utf-8.

pas de probleme. mais je vous laisse faire (j'ai pas d'outil en ligne de commande qui transforme recursivement l'encodage des fichiers).

on laisse quand meme la possibilite aux plugins de definir en_UK ou fr_FR.iso-8859-1 ?

EDIT Pierrick a été plus rapide!

rvelices a écrit:

on laisse quand meme la possibilite aux plugins de definir en_UK ou fr_FR.iso-8859-1 ?

Je pense que oui sachant que cette norme impliquera une conversion à chaque fois.

Dernière modification par rub (2007-10-09 18:16:30)

rub a écrit:

z0rglub a écrit:

rvelices a écrit:

on laisse quand meme la possibilite aux plugins de definir en_UK ou fr_FR.iso-8859-1 ?

non, je ne vois pas l'intérêt, et toi ?

Est-ce que tous les développeurs de plugin vont être à l'aise avec des fichiers UTF8 dans un premier temps?

Finalement après réflexion, abandonnons la possibilité du  fr_FR.iso-8859-1.
On aura  fr_FR sans charset et on aidera les développeurs de plugins à encoder en UTF8 (sachant que c'est pas si compliquer de nos jours!)