Dans la série traitement typo, il me semble avoir remarqué que si l'on pose
un texte où les guillemets sont tapé avec des "blancs" (exemple : « mot »)
SPIP opère correctement le placement des insécables.
Il n'est peut-être pas utile de modifier la "moulinette" de SPIP pour ce
genre de cas de figure (histoire de ne pas alourdir l'ensemble). Par contre
si le mot est saisi sans les "blancs" (exemple : «mot») SPIP ne fait rien.
Il faudrait peut-être le péciser dans la doc pour ceux (nombreux et
nombreuses) qui ne savent pas taper.
Dans la série traitement typo, il me semble avoir remarqué que si l'on pose
un texte où les guillemets sont tapé avec des "blancs" (exemple : « mot »)
SPIP opère correctement le placement des insécables.
Il n'est peut-être pas utile de modifier la "moulinette" de SPIP pour ce
genre de cas de figure (histoire de ne pas alourdir l'ensemble). Par contre
si le mot est saisi sans les "blancs" (exemple : «mot») SPIP ne fait rien.
Salut Aris,
Je viens de revoir entièrement la partie typographie de spip, que j'ai
déplacé dans une fonction spéciale -- on peut l'appeler séparément :
$textecorrige = typo($texte)
Il s'agit du fichier ecrire/inc_texte.php3
J'y ai ajouté quelques trouvailles du Mémento typographique de Ch. Gouriou
(la "Bible") : ainsi M. MM. Mme Mmes Melle Mr. etc. sont bien traités, de
même que M°~Bastille, N°~250, 25~F. ou 100~000~°C, etc.
Pour les guillemets français il y a pas mal de manières de les coder, le
code spip en avait oublié une (je l'ai rajoutée : « »). Peut-être
cela va-t-il résoudre ton pb ?
Pour les insécables, si vous entriez dans le navigateur des "blancs durs"
(alt-espace sur Macintosh) ils n'étaient pas gérés : c'est maintenant fait
(merci de vérifier sur vos PC)
Certains caractères nordiques ne tenaient pas le choc de la traduction en
majuscules. Le problème devrait être corrigé en bloc dans cette version.
Maintenant qu'on a la liste spip-dev, il manque peut-être un
début de "méthodologie". Pour y aller mollo, je pense qu'on
peut commencer avec simplement un espace FTP commun. Ca
existe déjà pour Arno et moi sur minirezo.net, mais d'une
part ça donne aussi accès à uzine2, et d'autre part le serveur
est super lent (pénible quand il faut transférer 50 fichiers).
Donc peut-être qu'on pourrait avoir un accès FTP dans un compte
sur rezo.net ?
A part ça, les diff ne sont pas très utilisables pour Arno
(macintosh) et moi (windows). Il vaut mieux travailler par
fichiers entiers (en utilisant le FTP).
Enfin, sur la validation des modifs, je pense que toute
personne proposant une modif conséquente devrait la tester
d'abord sur une certaine variété de configs : notamment les
hébergeurs (Arno et moi testons pour l'instant sur : Free, rezo.net, freedom2surf, lautre.net, altern...). Egalement
sur un contenu existant et réel. Je peux fournir un dump.xml
correspondant à un sous-ensemble d'un vieux back-up
d'uzine, afin d'avoir une certaine base commune (en plus
des sites spécifiques à chacun).
Plutôt d'accord ! Je completerais la proposition d'Antoine en faisant (ou
refaisant) aussi quelques propositions :
1) Je peux probablement nous obtenir rapidement un compte sur "Savannah"
(http://savannah.gnu.org), une sorte de "Source Forge" du GNU qui doit
s'ouvrir à tous les logiciels libres sous GPL ou licenses compatibles.
Cela donne accès, comme sur SF, à un FTP, à des mailing lists (on est déjà
équipé), à des forum, à un gestionnaire de tâches, à un CVS, etc.
La bande passante et l'espace disque y est qui plus est confortable.
Vous en pensez quoi ?
2) Pour le FTP nous pourrions l'organiser de façon à séparer la dernière
version stable des versions en développements ou en betat-test (dans des
répertoire différents par exemple).
3) Utiliser le gestionnaire de tâche de "Savannah" pour avoir une sorte de
"TODO" interactif et savoir qui s'occupe de quoi à quel moment.
4) Tenir à jour un "changelog" ce qui permette en particulier aux
utilisateurs de savoir ce qui a changé entre une version et une autre (et ce
qu'implique ou propose un upgrade).
J'avais déjà fait cette proposition il y a quelques temps et elle n'a
visiblement :)) pas soulevé l'enthousiasme des foules : cela me semble
pourtant important en particulier parceque cela pousse l'utilisateur de SPIP
à s'interesser à ce qui se passe du côté du code et cela lui donne des
éléments en cas de pb à l'upgrade (pouquoi cela marcahait avant et plus
maintenant, grossomodo).
Maintenant qu'on a la liste spip-dev, il manque peut-être un
début de "méthodologie". Pour y aller mollo, je pense qu'on
peut commencer avec simplement un espace FTP commun. Ca
OK. Rendez-vous sur ftp://spip-dev@rezo.net/ (me demander le mot de passe)
Ce répertoire est accessible en lecture via http://rezo.net/spip-dev/
avec, cerise sur le gâteau, un joli mode php-source et une sécurité qui
interdit de télécharger inc_connect.php3 (si jamais vous oubliez de
l'enlever). J'y ai déjà mis ma version beta courante.
A part ça, les diff ne sont pas très utilisables pour Arno
(macintosh) et moi (windows). Il vaut mieux travailler par
fichiers entiers (en utilisant le FTP).
d'acc.
Enfin, sur la validation des modifs, je pense que toute
personne proposant une modif conséquente devrait la tester
d'abord sur une certaine variété de configs : notamment les
hébergeurs (Arno et moi testons pour l'instant sur : Free, rezo.net, freedom2surf, lautre.net, altern...). Egalement
sur un contenu existant et réel.
Plutôt d'accord ! Je completerais la proposition d'Antoine en faisant (ou
refaisant) aussi quelques propositions :
1) Je peux probablement nous obtenir rapidement un compte sur "Savannah"
(http://savannah.gnu.org), une sorte de "Source Forge" du GNU qui doit
s'ouvrir à tous les logiciels libres sous GPL ou licenses compatibles.
Ouip, enfin si c'est comme Sourceforge, il y a déjà un projet SPIP
sous sourceforge : le problème est l'obligation d'utiliser CVS et SSH
(pas de FTP simplement accessible en écriture), ce qui est un peu
lourdingue à mon avis - hormis le fait que je n'aie jamais utilisé
CVS, ni SSH en transfert de fichiers. D'autre part, on ne peut pas
dire que l'interface Sourceforge soit limpide....
3) Utiliser le gestionnaire de tâche de "Savannah" pour avoir une sorte de
"TODO" interactif et savoir qui s'occupe de quoi à quel moment.
4) Tenir à jour un "changelog" ce qui permette en particulier aux
utilisateurs de savoir ce qui a changé entre une version et une autre (et ce
qu'implique ou propose un upgrade).
Effectivement la gestion automatique de ces deux machins là peut
être très sympa. Pour le changelog, c'est surtout une question de
paresse, on n'a pas trop envie de consigner les modifs qu'on est
en train de faire alors qu'on est dans le feu de l'action (et le
lendemain on a tout oublié...).