Hello,
au début du TODO.txt, on peut lire :
"Multi-bases : ajout d'une table spip_dbs listant les différents
préfixes (préfixe par défaut : vide) ainsi que les URLs associées à
chacun ; ajout d'une partie dépliable "options avancées" lors de
l'installation."
Il me semble que ce point a été ajouté après ma suggestion d'ajouter
un préfixe (paramétrable) aux noms de tables de SPIP, pour pouvoir
faire tourner plusieurs SPIP sur une seule base de données.
Si c'est bien le cas, on a dû mal se comprendre, car je vois une
méthode beaucoup plus simple que ce qui est proposé pour répondre à
mon besoin.
Il suffit, lors de l'installation, de demander un préfixe à l'admin,
et on aura alors création des tables prefixe_spip_* ...
Ce préfixe n'a pas à être dans la base de données, il suffit qu'il
soit dans inc_connect.php3 ...
Qu'en dites-vous ?
Nicolas.
Salut,
"Multi-bases : ajout d'une table spip_dbs listant les différents
préfixes (préfixe par défaut : vide) ainsi que les URLs associées à
chacun ; ajout d'une partie dépliable "options avancées" lors de
l'installation."
Il me semble que ce point a été ajouté après ma suggestion d'ajouter un
préfixe (paramétrable) aux noms de tables de SPIP, pour pouvoir faire
tourner plusieurs SPIP sur une seule base de données.
Ouip.
Si c'est bien le cas, on a dû mal se comprendre, car je vois une
méthode beaucoup plus simple que ce qui est proposé pour répondre à mon
besoin.
Oui mais il me semble intéressant et peu coûteux de lister les
différents préfixes déjà utilisés dans une table commune, afin
d'avoir une visibilité, lors d'une installation, sur ce qui existe
déjà. Et lors d'une réinstallation, de pouvoir sélectionner le bon
préfixe directement sans se demander comment on a bien pu appeler
ce rogntudju de préfixe trois mois avant. Ajouter l'URL du site
et/ou un commentaire dans cette table permet que ce soit encore plus
pratique au niveau de la sélection. Comme ça, la chose devient
accessible aux débutants.
Qui peut le plus peut le moins :)) C'est de toute façon la réécriture
de toutes les requêtes MySQL dans SPIP qui sera lourdingue. Il serait
bon d'ailleurs de créer une fonction dédiée (spip_query ?) qui fasse
automatiquement le renommage.
a+
Antoine.
pouvoir faire tourner plusieurs SPIP sur une seule base de données.
Ouip.
OK.
Oui mais il me semble intéressant et peu coûteux de lister les
différents préfixes déjà utilisés dans une table commune, afin
d'avoir une visibilité, lors d'une installation, sur ce qui existe
déjà.
OK, je comprend le principe. Je suis pour.
Qui peut le plus peut le moins :))
Oui, mais le "plus" prend plus de temps à être réalisé ... 
C'est de toute façon la réécriture de toutes les requêtes MySQL dans
SPIP qui sera lourdingue.
Je peux vous proposer mon humble contribution avec dbMysql :
http://www.phpheaven.net/projects/dbMysql/
Nicolas.
Autre point de la TODO.txt, à laquelle, je souhaiterai revenir est
l'internationalisation.
Quand-est ce qu'on pourra externaliser toutes les textes en français du
code de SPIP pour pouvoir préparer une traduction en anglais?
A cette effet, j'ai trouvé que la librairie "STPhp, internationalization
tool for PHP" de Jacob Moorman était intéressante
(http://stphp.sourceforge.net/). Peut-on envisager de l'intégrer dans
SPIP ?
Il y a aussi les icônes de l'interface privée à traduire.
Le besoin est que dans un site multilingue, l'équipe rédactionnelle
comporte aussi des auteurs et rédacteurs anglophones qui sont déroutés
par notre interface en français. Et là, pas moyens de les renvoyer vers
l'aide ou la doc existante tout est en français. Donc on passe des mails
interminables à expliquer comment SPIP marche, alors que c'est enfantin.
Je sais que le travail d'internationalisation est un peu rébarbatif.
Mais, je crois qu'elle est nécessaire pour le développement de SPIP,
malgré tout l'attachement que j'ai pour la langue française.
Aussi, si vous avez besoin de bras pour le faire, je suis prêt à aider.
Pierre
A cette effet, j'ai trouvé que la librairie "STPhp,
internationalization tool for PHP" de Jacob Moorman était
intéressante
Bof. C'est franchement compliqué à mettre en place. Une solution
interne à SPIP (comme dans phpMyAdmin par exemple) serait plus simple
à mon avis à créer.
Nicolas.
Bien que n'étant pas encore assez sûr de mes talents de développeur pour
vous proposer de vous aider en prog, je pense que je pourrais
certainement pouvoir vous aider en faisant des traductions. Je vais donc
commencer a traduire la documentation en anglais...
Si cela vous semble peu utile, ou bien si l'internationalisation n'est
pas près d'arriver, n'hésitez pas à me le faire savoir, pour que je ne
fasse pas ca pour rien ;o)
Bof. C'est franchement compliqué à mettre en place.
En fait STPhp ne propose qu'une seule fonction ST() à intégrer. L'appel
de la fonction est de la forme:
eval (ST ($idMessage, $varRetourTraduction, $idlanguage));
Le restant du package est juste constitué d'outils pour les développeurs
afin de construire le dictionnaire de traduction. Mais bon, sans doute,
le fait que l'auteur offre le choix de stocker les traductions dans un
fichier texte ou sur une base de donnée complique inutilement le code.
Une solution interne à SPIP (comme dans phpMyAdmin par exemple) serait
plus simple.
Je me doute bien que la difficulté n'est pas dans le développement de
cette fonction de traduction surtout pour toi l'auteur du super phpLang.
Mais plus dans le boulot qu'il faudra pour extraire tous les messages
qui sont codés en dur dans tout le code.
La décision de figer un temps le code pour effectuer cette modification
ne doit pas être amusante à prendre.
Aussi, ceci est simplement ma pierre pour sensibiliser les auteurs
Arno*, Antoine et Fil sur l'internalisation qui reste un peu vide et
orpheline dans la todo.txt
Pierre
En fait STPhp ne propose qu'une seule fonction ST() à intégrer.
L'appel de la fonction est de la forme:
eval (ST ($idMessage, $varRetourTraduction, $idlanguage));
Ce qui est loin d'être "joli" comme façon de coder. Utiliser des
constantes, qu'elles proviennent d'un fichier ou d'une interrogation
de base de données, est beaucoup plus propre, simple à utiliser, et
performant.
Je me doute bien que la difficulté n'est pas dans le développement
de cette fonction de traduction surtout pour toi l'auteur du super
phpLang.
Ouh la la, pas de fleur s'il te plait, je n'ai pas de vase ...
Mais plus dans le boulot qu'il faudra pour extraire tous les
messages qui sont codés en dur dans tout le code.
C'est clair que c'est là qu'est la principale difficulté. Mais il faut
commencer par transformer toute l'interface pour qu'elle n'utilise pas
de texte dans les images, uniquement des icones associées à du texte
simple, comme pour "référencer un site".
La décision de figer un temps le code pour effectuer cette
modification ne doit pas être amusante à prendre.
Cela peut se faire petit à petit, fichier par fichier, rien de bien
sorcier.
Nicolas.