Coucou,
je viens de préparer l'annonce de la 1.6pr1, j'aimerais notamment qu'on
discute de ça avant de passer en 1.6 finale :
REMARQUE IMPORTANTE : il est très probablement préférable de commencer, lors
d'une nouvelle installation, par aller dans la configuration avancée pour
choisir le jeu de caractères 'utf-8' plutôt que le traditionnel et
vieillissant 'iso-8859-1'. A mon avis il serait même bien, maintenant,
de mettre ça comme standard.
-- Fil
REMARQUE IMPORTANTE : il est très probablement préférable de commencer, lors
d'une nouvelle installation, par aller dans la configuration avancée pour
choisir le jeu de caractères 'utf-8' plutôt que le traditionnel et
vieillissant 'iso-8859-1'. A mon avis il serait même bien, maintenant,
de mettre ça comme standard.
Il me semble qu'il y a des filtres et autres machins qui risquent de
ne pas marcher correctement (ou pire, de produire de l'utf-8 invalide),
vu que PHP traite les chaînes de caractères comme de bêtes séquences
d'octets.
Il me semble qu'il y a des filtres et autres machins qui risquent de
ne pas marcher correctement (ou pire, de produire de l'utf-8 invalide),
vu que PHP traite les chaînes de caractères comme de bêtes séquences
d'octets.
Des filtres SPIP ou des filtres faits-main ? Si c'est des filtres
faits-main, ça ne pose pas de problème, car ça n'existe que sur des sites
déjà installés (on ne va pas modifier leur charset!) ; si c'est des filtres
de spip, je crois que j'ai tout vérifié (c'était juste majuscules(), en
fait, qui posait problème).
-- Fil
Des filtres SPIP ou des filtres faits-main ? Si c'est des filtres
faits-main, ça ne pose pas de problème, car ça n'existe que sur des sites
déjà installés (on ne va pas modifier leur charset!) ; si c'est des filtres
de spip, je crois que j'ai tout vérifié (c'était juste majuscules(), en
fait, qui posait problème).
A moins de connaître la liste des fonctions PHP qui respectent utf-8,
on ne peut pas vraiment être sûrs, et ça risque de nous gêner par la
suite.
Accessoirement il faudrait être sûr que les brouteurs n'ont pas de
problèmes (notamment l'entrée des formulaires).
Sinon c'est vrai que ce serait bien mieux de proposer utf-8 par défaut.
A moins de connaître la liste des fonctions PHP qui respectent utf-8,
on ne peut pas vraiment être sûrs, et ça risque de nous gêner par la
suite.
Si ça "peut nous gêner par la suite", ç nous gêne déjà, vu qu'on autorise
(et même incite, dans le cas de sites non latins) à y passer.
Accessoirement il faudrait être sûr que les brouteurs n'ont pas de
problèmes (notamment l'entrée des formulaires).
Ouaips. Mais je pense que c'est mûr. De toutes façons les gens peuvent
revenir en isolatin s'ils trouvent qu'il y a des problèmes (on peut même
faire la moulinette isolatin <-> utf-8, de toutes façons je compte bien la
faire si personne ne se dévoue 
Sinon c'est vrai que ce serait bien mieux de proposer utf-8 par défaut.
Voyons ce que disent les autres. Bonne nuit.
-- Fil
Ouaips. Mais je pense que c'est mûr. De toutes façons les gens peuvent
revenir en isolatin s'ils trouvent qu'il y a des problèmes (on peut même
faire la moulinette isolatin <-> utf-8, de toutes façons je compte bien la
faire si personne ne se dévoue
Petite question bête, le codage influe sur les données a quel niveau ?
dans le stockage dans la base ?
dans les pages générées ?
A priori j'ai cru comprendre en vous lisant que l'on pouvait pas changer son
charset comme ca une fois des articles saisies ?
(En fait ca me permettrait peut etre de comprendre un de mes soucis vu que
je suis passé d'un Charset iso-8859-15 à iso-8859-1 au cours de mes tests de
SPIP)
Et comment transformer les données ?
> Sinon c'est vrai que ce serait bien mieux de proposer utf-8 par défaut.
Ca devient la référence. Il y a qu'a installer un Linux récent pour s'en
apercevoir !
Et découvrir les effets nefaste sur les application déjà éxistante 
(lettre accentué qui se transforme en ?)
@+
Etienne
Tinou a écrit:
Petite question bête, le codage influe sur les données a quel niveau ?
dans le stockage dans la base ?
dans les pages générées ?
C'est le codage affiché dans les pages, donc celui que vont renvoyer les
navigateurs lorsque tu entreras des données dans les formulaires ; et, par
conséquent, tout ce que tu entres à partir de ce moment-là dans la base SQL
à partir de l'interface SPIP est dans le codage en question.
A priori j'ai cru comprendre en vous lisant que l'on pouvait pas changer son
charset comme ca une fois des articles saisies ?
Oui, c'est un problème.
(En fait ca me permettrait peut etre de comprendre un de mes soucis vu que
je suis passé d'un Charset iso-8859-15 à iso-8859-1 au cours de mes tests
de SPIP)
Exact.
Et comment transformer les données ?
Il faut programmer. Soit en php/sql, soit exporter la base, la convertir
d'un coup, et la réintégrer dans la base.
-- Fil
Un site spip s'articule autour de rubriques, d'articles et de brèves...
Pourras-t-on ?
- Créer un rubrique et une ou plusieurs traductions
- Un article et une ou plusieurs traductions
- Une brève et une ou plusieurs traductions
et naviguer dans le site dans la langue de son choix...
si je navique en anglais, je vois toutes les rubriques en anglais, idem en
français...
note : si un article ou une brève n'a pas de traduction, afficher
éventuellement l'article dans sa langue originale...
voici ce que je veux dire par un contenu multilingue...
Note: je suis en train de faire des essais sur la traduction des articles...
(voir un messageprécédent...)
@+ Coyote
Un site spip s'articule autour de rubriques, d'articles et de brèves...
Pourras-t-on ?
- Créer un rubrique et une ou plusieurs traductions
- Un article et une ou plusieurs traductions
- Une brève et une ou plusieurs traductionset naviguer dans le site dans la langue de son choix...
si je navique en anglais, je vois toutes les rubriques en anglais, idem en
français...note : si un article ou une brève n'a pas de traduction, afficher
éventuellement l'article dans sa langue originale...voici ce que je veux dire par un contenu multilingue...
SPIP 1.6 n'a pas d'outil particulier pour faire ce genre de choses, non.
-- Fil