Pour l'internationalisation, je crois qu'il faut pas se presser: on doit encore encaisser le choc de la release française: on est en plein mois de juillet, et pourtant de jour en jour ça continue à se développer. A ce train, la rentrée risque d'être sanglante.
Avant l'internationalisation, il me semble donc qu'il faut d'abord développer les compétences (je veux dire, à part nous), de gens près à répondre aux questions, à fabriquer des interfaces, etc. Honnêtement, je nous vois mal affronter _tous seuls_ une nouvelle série de "oui mais, et la fonction crypt dans la ligne 2, pourquoi ça marche pas sur mon pécé" et de "sa serè bien si y'avai plusieur formats de fonds de page" à l'échelle internationale :-))
Ce serait pas plus mal de profiter qu'on n'a que la version française pour laisser le temps à des équipes de se constituer. Equipes qui permettront alors d'encaisser le choc d'une version internationale.
Pour l'internationalisation, je crois qu'il faut pas se presser
Je pense au contraire que préparer rapidement l'i18n permettrait de
penser tout le code dans ce sens, ce qui évitera de refaire pas mal de
choses par la suite. Cela ne veut par contre pas forcément dire de
lancer dès maintenant SPIP à la face du monde ...
Avant l'internationalisation, il me semble donc qu'il faut d'abord
développer les compétences
Une large audiance permet de trouver plus facilement des contributeurs
efficaces et de consolider l'appli plus rapidement, mais ce n'est que
mon avis, issu de mon expérience en la matière sur phpMyChat.
Ce serait pas plus mal de profiter qu'on n'a que la version
française pour laisser le temps à des équipes de se constituer.
Je pense que j'en serais, vu que je vais utiliser SPIP pour un de mes
sites ...
Pour ce qui est de la méthode, pourquoi ne pas travailler avec des
fichiers XML ?
En effet, c'est une très bonne idée, il sera ainsi plus simple de
diffuser un fichier template en anglais pour que les traductions se
fassent ...
Il faudra cependant faire attention aux charsets et caractères
exotiques.
Finalement j'ai ajouté un eregi_replace ("<html>","<HTML>"...) avant le test
actuel. Du coup on a bien notre fonctionnalité (majuscules/minuscules dans
le tag <html>), sans perturber tout le code.
