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" endedEt "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
Hors ligne
z0rglub a écrit:
Par contre, pour l'upgrade.php (pas l'upgrade_feed.php) on proposera 2 options : avec et sans conversion des données en base. La conversion étant par défaut et recommandée. Ca te va ?
pas de probleme. en fait maintenant tes accents ne devrait pas partir en fumee (l'admin etait en utf-8, je convertis les tables en binaire ensuite en utf8 ce qui devrait etre bon).
Hors ligne
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
Hors ligne
rvelices a écrit:
pas de probleme. en fait maintenant tes accents ne devraient pas partir en fumee (l'admin etait en utf-8, je convertis les tables en binaire ensuite en utf8 ce qui devrait etre bon).
Excellent, et evident.
Ç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.
8-)
Hors ligne
rvelices a écrit:
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.:-)
Excellent....
Hors ligne
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?
Hors ligne
rub a écrit:
Et si je veux mettre ½ ou ¾ ou ¿ ou Ø ou ß dans mes traductions en anglais, comment je fais?
½ ¾ ¿ Ø ß
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...
Hors ligne
rvelices a écrit:
rub a écrit:
Et si je veux mettre ½ ou ¾ ou ¿ ou Ø ou ß dans mes traductions en anglais, comment je fais?
½ ¾ ¿ Ø ß
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
Hors ligne
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.
N'ayons pas peur de passer intégralement et vraiment en utf-8 :-)
Hors ligne
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 ?
Hors ligne
rvelices a écrit:
pas de probleme. mais je vous laisse faire (j'ai pas d'outil en ligne de commande qui transforme recursivement l'encodage des fichiers).
OK, je m'en occupe ce soir (oula... ça fait longtemps que j'ai pas commité sur PWG)
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 ?
Hors ligne
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)
Hors ligne
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?
Hors ligne
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!)
Hors ligne