je viens de découvrir un dysfonctionnement sur ma version de spip 1.307.
Une fois un logo attribué à une rubrique, le remplacement de celui ci par un
autre logo (après suppression bien sur) ne prend pas effet.
Cependant la taille du logo est bien modifiée et égale à celle du nouveau
logo.
Je n'ai pas trouvé ou était stockée cette information dans la base.
Il faut forcer le rechargement de l'image dans ton butineur. En effet, quand tu installes la nouvelle image pour le logo, elle adopte le même nom que l'ancienne. De ce fait, ton butineur croit que c'est la même image, et ne la recharge pas (il va la chercher dans ton propre cache, sur ton disque dur). Il faut donc que tu fasses un "hard reload" (parfois simplement le bouton "recharger", ou "controle-recharger" ou une variante selon les navigateurs).
J'étais confronté à la problématique de savoir si spip allais bien me gérer
les caractéres chinois et japonais.
J'ai reçus des fichiers traduis dans des fichiers word2000 que je devais
mettre dans mes fichiers HTML ou dans la base, mais en faisant des copier
coller j'ai juste eu des "???" qui ne donnais rien d'autre. Cela
surrement à cause des encodages.
Mais au lieu de tout régler comme il faut, j'ai tout simplement "enregistrer
sous format HTML" le fichier word.
Et là, ôooo suprise mes caractéres chinois se sont transformés en :
滑动门的质
Ce qui a priori ne devrait pas poser de probléme de prise en charge. Donc
peut-être qu'il est possible de directement faire un filtre qui change les
caractéres chinois en ces codes sans passer par la case "enregistrement
HTML" qui est tout de même assez fastidieuse quand l'on dois Virer tout le
code que word nous pond on sait pas pq...
Voilà si ça peu vous aider Ou alors s'il y a des choses que cette
technique ne permet pas, merci de me le dire...
Et là, ôooo suprise mes caractéres chinois se sont transformés en :
滑动门的质
Pour avoir fait un site en cyrillique (Мир дипломатии)
je peux te dire que cet encodage passe mal. En revanche, on peut peut-être
avoir un truc qui accepte cet encodage et le remet dans un charset cohérent.
1) La solution est sans doute de passer en UTF8 qui supporte tous les
caractères Unicode.
Un filtre convient parfaitement pour réaliser l'encodage UTF8. Il faut:
a- créer et mettre dans mes_functions.php3
<?
function utf8($texte)
{
return utf8_encode($texte);
}
?>
b- modifier article.html pour y glisser le méta
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
et
appliquer le filtre utf8 sur tous les champs #TITRE|utf8, #CHAPO|utf8
#TEXTE|utf8....
Cette solution est plus universelle que de prévoir des charsets iso pour
chaque langue. Elle évite donc de multiplier les squelettes et permet de
mixer différentes langues dans un même article. C'est tout l'intérêt de
Unicode.
2) En visitant la version cyrillique du monde diplomatique, j'ai vu que
le charset est windows-1251. J'en profite pour réitérer ma question
restée sans réponse (cf mail 'Moteur de recherche et UTF8/ISO'):
Comment faire marcher le moteur de recherche de Spip quand l'encodage
charset du site public est différent de l'encodage charset du site
privé?
Par exemple windows-1251/iso-8859-1.
(problème d'encodage des paramétres dans URL de recherche et de
l'article)
1) La solution est sans doute de passer en UTF8 qui supporte tous les
caractères Unicode.
Tu l'utilises quelque part, cette solution ?
2) En visitant la version cyrillique du monde diplomatique, j'ai vu que
le charset est windows-1251. J'en profite pour réitérer ma question
restée sans réponse (cf mail 'Moteur de recherche et UTF8/ISO'):
Comment faire marcher le moteur de recherche de Spip quand l'encodage
charset du site public est différent de l'encodage charset du site
privé?
Le moteur de recherche ne fonctionne pas sur la version cyrillique, qui
n'est pas (pas encore?) spipée. J'aimerais qu'on aboutisse, de manière à
spiper cette version aussi. Tu as l'air d'être le plus en pointe sur la
question...
(problème d'encodage des paramétres dans URL de recherche et de
l'article)
Ici ca semble marcher très bien... Mais je suis (exceptionellement;) sous
une plateforme microsoft (avec ie)...
Pierre annonçait deux versions différentes, je n'ai pas vu la différence
entre les deux. De toutes façons pour moi aucune ne marche, parce que je
n'ai pas installé les polices !
1) >je n'ai pas vu la différence entre les deux
Pas exactement, les versions UTF8 passée par le filtre d'encodage UTF8.
Mais tu as raison la fonction PHP utf8_encode n'encode pas les entités
numériques &#xxxx. Mais, en faisant attention, dans mes pages exemples,
on voit des petites différences. Par exemple:
ISO: Như hà nghịch lỗ lai xâm phạm
Utf8: Như hà nghịch lỗ lai xâm phạm
Il semble que la notation des entités numérique soit le mode de stockage
par défaut de Mysql pour les caractères Unicode. J'ai essayé de passer
la partie privé en UTF8 avec le même résultat: les caractères exotiques
sont transformés en entité.
Et je n'ai pas réussi à utiliser la fonction mb_decode_numericentity
pour décoder ces entités en caractère. D'après la doc, il semble que la
fonction soit toujours au stade expérimentale dans PHP4.
On peut utiliser un preg_replace pour faire ce transcodage. Mais, c'est
loin d'être une solution universelle, surtout pour le chinois où il y a
des dizaines de milliers de caractères.
Le meilleur que j'ai pu obtenir est donc une solution mélangeant UTF8 et
les entités numériques.
2) Compatibilité des caractères exotiques avec les navigateurs.
Sous plateforme Window, il semble que la notation des entités numériques
&#xxx soient bien accepté par IE et Netscape 6.x quelques soit le
charset défini pour la page.
Mais avec Netscape 4.7x il n'y a que le charset UTF8 qui soit bien
accepté.
@ Yannick Patois <patois@calvix.org> :
> > "Bảo Vệ Bờ Cõi Việt Nam"
>
> Ici ca semble marcher très bien... Mais je suis (exceptionellement;) sous
> une plateforme microsoft (avec ie)...
Ca marche meme très bien avec Konqueror sous Linux, et incroyablement
bien avec Lynx et Links : bien que le terminal ne soit que ISO-8859-1 il
se débrouille pour 'coder' les chapeaux et autres accentuations (genre