Je viens de vérifier que ça fonctionne, aussi bien à l'intérieur
qu'à l'extérieur de la boucle principale (ARTICLES){id_article}.
Je confirme, chez moi ça marche nickel:
- j'ai dans mes_options.php3 $forcer_lang=true
- je fais des <INCLURE(...){lang}>
avec la dernière version CVS (ce matin)
Je ne sais pas trop comment ça pourrait se faire : j'imagine un site
sous CVS, avec, pour chaque problème, difficulté, discussion,
fonctionnalité... un couple php3/squelette utilisant cette
fonctionnalité, et précisant le résultat prévu par la doc. Comme ça
on pourra dire précisément ce qui marche ou pas.
Dans le même sens, est ce que quelqu'un utilise Mantis et le système
de gestion de bug de spip? j'ai l'impression que les gens qui postent
des bugs ne le fond que sur le ng?
ce qu'il faudrait, c'est que chaque bug soit posté sur mantis, avec
une pair de fichiers tout simple, qui illustrerait le
bug. Malheureusement, certain bug pourait être lié à des options
globale.
Ensuite, quelques personnes prendraient ces fichiers pour les mettre
sur un serveur de test spip. La question est la suivante: faut il
faire une version de test pour toutes les versions "release" de spip?
je veux dire que si quelqu'un passe sur la 1.7.2, et veux illustrer un
test sur cette version, il s'en fou de passer à la 1.8 alpha cvs en
développement (qui corrige peut être ce bug, mais en introduit
d'autres..).
Il faudrait donc un serveur de test pour la release officielle et un
pour la release de dev.
La plupart des logiciels disposent d'une batterie de tests qui
permettent de valider les fonctionnalités. Pour un ensemble comme
SPIP, la manière de concevoir ces tests m'échappe un peu ;
Ce qui se fait d'habitude dans un développement est la chose suivante:
- on définie le cahier des charges (les fonctionnalités générale),
- on ecrit la doc du système,
- on étudie les fonctionnalités bas niveau pour arriver à un tel
système,
- on remanie la doc,
- on écrit une batterie de tests qui vérifie tous les points définis
par la doc.
- on implémente.
- on test.
et on recommence le cycle pour les nouvelles fonctionnalités.
Le problème avec le cycle de base:
- j'imagine des fonctions,
- j'implémente (ha, tiens, la fonction là elle serait bien, bon,
je l'ajoute au passage)
- je fait un test comme je le sens,
- je gère les bugs et j'ecrit la doc.
qui est souvent celui adopté dans les milieux de dev non
professionnels (parce que c'est chiant et pas amusant de faire le
cycle complet, et que ça prend du temps), est que:
- quand on fait les tests, on les fait alors qu'on sait comment
c'est implémenté ("inconsciemment" on évite les bugs)
- quand on ecrit la doc:
* on a pas trop envie de le faire,
* les choses nous paraissent évidentes (on vient de l'implémenter)
* on oublie la moitié des fonctions que l'on a ajoutées (à 1h du
mat sur la demande pressé d'un utilisateur).
Je ne sais pas si c'est le cas de spip. Mais c'est peut être pour ça
que c'est difficile d'écrire des tests. Heureusement, il y a une
grande communauté qui génère elle même ces tests. Il faut juste un bon
moyen de les centraliser.
en tous cas si l'un de vous souhaite se lancer dans cette voie,
il/elle est bienvenu(e) !
c'est fou tout ce que j'aimerais faire, mais pour lequel je n'ai pas
le temps. Je n'ose pas prendre de tel engagements. Désolé. (si ça se
fait, je veux bien participer, mais je peux pas garantir un suivit à
100%, c'est le pbl de tous je pense)
Pierre
