Juste pour dire que je me prepare a rendre la prochaine version compatible avec le charset UTF-8.
Dans un premier temps ca ne sera pas obligatoire d'utiliser utf-8. En grande lignes
A. virer str_translate_to_ascii7bits et $lang_table_translate_ascii7bits (deja commence) - ca sera commite en 1.7 egalement
B. rendre la fonction str2url compatible UTF-8 (elle utilise en dur php les caracteres accentues) - ca sera commite en 1.7 egalement
ensuite seulement pour le trunk:
C. rendre les langues independantes de charset (trunk uniquement)
C.1 remplacer $lang_info['charset'] avec $conf['charset']; le seuls $conf['charset'] supportes seront ISO-8859-1 et UTF-8
C.2 #user_infos.language ne contient plus iso-8859-1 ...
C.3 modification de qq fonctions pour charger et convertir les langues de iso-8859-1 vers utf-8 et vice-versa ...
D. mettre la connection a MySql dans le bon charset ( latin1 pour iso-8859-1 et utf8 pour utf-8) - seulement pour MySql>4.1
E. gerer l'encodage des iptc pour l'affichage et la synchronisation avec la base ...
des idees ?
Hors ligne
Tu es un mec génial.
La migration optionnelle est pour moi la priorité numéro 1.
Pas le temps de réfléchir ce soir, mais je le trouverai.
Je sens que cela va motiver l'ami z0rglub.
8-)
Hors ligne
Excellente initiative rvelices.
Le plus compliqué, c'est la migration.
Pour information, ma galerie personnelle est en UTF-8 depuis plusieurs années, avec le code 100% standard de PWG, j'ai simplement une nouvelle langue : fr_FR.utf-8 (et ça marche assez bien).
Hors ligne
z0rglub a écrit:
Pour information, ma galerie personnelle est en UTF-8 depuis plusieurs années, avec le code 100% standard de PWG, j'ai simplement une nouvelle langue : fr_FR.utf-8 (et ça marche assez bien).
Oui, mais je pense qu'il y a peut-etre un pb sur ta galerie. Le charset vers le client est UTF-8 donc toutes les formes seront soumises en UTF8 et par consequent les requetes SQL seront encodes en UTF ... Mais qu'est-ce que MySql pense qu'il recoit ? Si tu n'appeles pas SET NAMES utf8 juste apres mysql_connect, alors ca depend de certaines variables serveur et ce qui'il va stoquer vraiment dans la base c'est encore plus flou...
Le plus compliqué, c'est la migration.
Je pense que je n'ai pas de solution miracle surtout que ca depend d'une panoplie de combinaisons concernant ce qu'on a fait jusqua maintenant...
Je pense que je ne vais rien faire pour la migration en automatique. Mais s'il ya de pb qqun pourra modifier le config_local.inc.php ...
Ca va marcher comme ca:
a. config_default -> $conf['charset'] = 'utf-8';
b. toute nouvelle installation de pwg va automatiquement creer les tables en utf-8 ...
c. dans common.inc.php, apres mysql_connect
if ( !empty(@$conf['db_connection_charset']) ) { pwg_query( 'SET names="'.$conf['db_connection_charset'].'"'); } else { // by default we tell mysql what charset we are talking pwg_query( 'SET names="'. translate_iso_charset_to_mysql_charset($conf['charset']). '"'); }
maintenant selon l'etat d'une pwg actuelle qqun peut modifier $conf['charset'] et optionnellement $conf['db_connection_charset'] s'il a des problemes avec le charset. 2 grand cas:
- on etait deja en utf-8 et on a des problemes d'affichage alors on met $conf['db_connection_charset']='latin1' et on continue comme jusqua maintenant
- on etait en iso-8859-1 et on a des problemes alors on met $conf['charset']='iso-8859-1' --> c'est bon mais on est pas en utf-8
Le pire - pour lequel je n'ai pas de solution - quelqu'un a utilise pwg avec une langue iso-8859 et ensuite est passe avec une langue utf-8 (ou les 2 en parallele ...) -> c'est "la cata" il faut choisir une et passer a la mano pour changer.
d. pour les langues c'est un peu plus facile - je peux assurer une compatibilite -> si on est en utf-8, mais on trouve une langue en iso-8859-1, on peut la charger et faire manuellement la conversion
Dernière modification par rvelices (2007-10-05 02:12:45)
Hors ligne
Quelle bonne nouvelle tout ca!
Compatibilité PostgreSQL en même temps?
C'est vrai qu'il serait bon de fixer des nouveaux niveaux pour les versions de MySql et Php, il faudrait le tour des providers et voir le max qu'on puisse prendre?
Hors ligne
rub a écrit:
Quelle bonne nouvelle tout ca!
Compatibilité PostgreSQL en même temps?
C'est vrai qu'il serait bon de fixer des nouveaux niveaux pour les versions de MySql et Php, il faudrait le tour des providers et voir le max qu'on puisse prendre?
Où alors on part sur la même approche qu'un autre GPL et on vérifie qq hébergeurs et providers?
8-)
Hors ligne
VDigital a écrit:
rub a écrit:
Quelle bonne nouvelle tout ca!
Compatibilité PostgreSQL en même temps?
C'est vrai qu'il serait bon de fixer des nouveaux niveaux pour les versions de MySql et Php, il faudrait le tour des providers et voir le max qu'on puisse prendre?Où alors on part sur la même approche qu'un autre GPL et on vérifie qq hébergeurs et providers?
8-)
C'est ce que je voulais dire.
Php5 & MySql5, c'est possible partout?
Et on laisse une 1.7 avec plugin compatible avec php4 & MySql 4.
Pour le puristes, Php5 comme limite ne veut pas dire qu'il faille ré-écrire!
Hors ligne
rub a écrit:
Php5 & MySql5, c'est possible partout?
Et on laisse une 1.7 avec plugin compatible avec php4 & MySql 4.
Php5, je pense que c'est "possible" partout, mais la plupart des hébergeurs proposent le php 4 par défaut, ce qui implique une manip à faire pour passer en php5...
Enfin en tout cas, c'est le cas avec les 2 que je connais (free et 1and1)
Donc à voir...
Hors ligne
P@t a écrit:
rub a écrit:
Php5 & MySql5, c'est possible partout?
Et on laisse une 1.7 avec plugin compatible avec php4 & MySql 4.Php5, je pense que c'est "possible" partout, mais la plupart des hébergeurs proposent le php 4 par défaut, ce qui implique une manip à faire pour passer en php5...
Enfin en tout cas, c'est le cas avec les 2 que je connais (free et 1and1)
Donc à voir...
La manip pour free et 1and1 est assez simple.
Une bonne doc & des bons pré-requis pour l'installation devrait être suffisant, non?
On peut même les intégrer directement dans l'installation!
Hors ligne
Attention aux Hosts US et autres qui fournissent un hébergement IIS.
MySQL 5 n'est pas disponible partout, loin de là.
8-)
PS: Php pose moins de pb.
Hors ligne
VDigital a écrit:
Attention aux Hosts US et autres qui fournissent un hébergement IIS.
On n'est pas capable de faire du lobbying pour qu'il migre leurs serveurs US ;-)
Hors ligne
Pour nous, c'est très facile de passer en php5...
Mais pour un utilisateur lambda, pour qui c'est déjà un peu fastidieux d'installer pwg, ca risque de le rebuter plutot qu'autre chose...
Donc, à mon avis, soit on a vraiment besoin de php5 pour diverses évolutions, et dans ce cas, on y passe...
Soit on peut s'en passer pour le moment, et mieux vaut attendre un peu.
PS: Je me rapelle d'un serveur webmail que j'avais installé il y a quelque temps, et qui necessitait php5... Et ben j'avais mis pas loin d'une heure à trouver enfin la manip pour passer en php5 sur 1and1 (et je devais etre à jeun!)
Dernière modification par P@t (2007-10-05 19:52:26)
Hors ligne