ddtddt a écrit:
VDigital a écrit:
L'avantage de l'édition en ligne des fichiers de localisation est l'assurance d'avoir une saisie en utf-8.
Exemple: http://pootle.wordforge.org/projects/pootle/Cela semble bien.
Inconvenant en regardant rapidement tous les projets et en lisant l'aide l'origine est toujours l'anglais !
Pootle est traduit en français bien entendu.
(Mais pas encore en 1.2 semble-t-il)
http://pootle.wordforge.org/fr/usersguide/
http://www.wordforge.org/drupal/project … ols/pootle
All programming is done in Python and is therefore cross-platform. Pootle is Free Software and is released under the GPL licence.
Mathias ou z0rglub ou torode peuvent nous dire si le serveur phpwebgallery.net pourrait l'accepter...
8-)
Hors ligne
VDigital a écrit:
Pootle est traduit en français bien entendu.
(Mais pas encore en 1.2 semble-t-il)
oui cela j'ai vu
Il me semble que dans tout ce que j'ai regarder quand les traducteurs potentiels ouvre un fichier à traduire, on leur propose comme modèle l'anglais (la colonne "original") et la cela peut peut être limité l'apport de chacun.
[edit] je n'ai pas vu que la colonne "original" était paramétrable mais cela est peut être posible [/edit]
Dernière modification par ddtddt (2007-10-11 21:59:03)
Hors ligne
J'ai un souci avec les .po .
1. Il faut les compiler en .mo, pour en faire l'usage
2. les modifs par surcharge, comment on les gère (genre $lang['Home']='Index';)
3. tous les fichiers de langue sont actuellement au même format (il me parait difficile aux plugins de produire leurs .po)
4. Est-ce rentable pour 1000 traductions ?
L'avantage du format, c'est qu'il existe une interface pour accéder aux traductions, mais qui ne donne pas non plus le contexte pour la traduction.
Mais bon.
Hors ligne
je ne suis pas sur que ca vaut le coup de "pootle" tout de suite. mais si les ficihers de langue continuent a augmenter beaucoup, ca va mettre de plus en plus de temps a charger donc a un instant donne on peut imaginer de livrer un .mo qui contient common et admin ensemble...
Hors ligne
rvelices a écrit:
si les ficihers de langue continuent a augmenter beaucoup, ca va mettre de plus en plus de temps a charger
que veux-tu dire par là exactement ?
je ne suis pas certain qu'il y ait une corrélation entre le temps de chargement d'une page et la taille d'un fichier PHP : c'est le poids du fichier HTML généré qui augmente le temps de chargement, et que tu ais 100 ou 1000 éléments dans ton tableau $lang, çà ne changera rien au fichier HTML final.
par contre, il est clair que plus le tableau $lang sera gros, plus celà consomme des ressources sur le serveur au moment de l'exécution du fichier PHP (pas forcément en conso cpu, mais en conso mémoire je pense).
après, faudrait faire des bench pour connaitre exactement la consommation de ressources...
Hors ligne