Bonjour
 
Je développe un site qui sera multi langue. Je mets toutes les traductions de mes champs dans des fichiers à parts qui sont ensuite lus par des inludes.  
 
Quelle est la meilleure technique sur ces fichiers texte : 1 seul avec tous les libelles de toutes les pages ? OU X fichiers correspondants aux X pages à traduire ?  
 
Dans le premier cas je trouve que ça ferai un trop gros fichier. Mais c'est beaucoup plus simple à intégrer dans mon controller : 1 seul include à faire .
Dans le second cas, c'est plus performant car l'appli ne charge que les libellés de la page à afficher et pas les autres. Mais ça fait X includes à faire pour les X pages , et sans doute moins pratique pour communiquer le tout à un traducteur.  
 
Bref, entre les 2 techniques mon coeur balance. Que faites vous  de votre côté ?  
Merci d'avance pour vos retours d'expérience sur ce sujet.  
 
Dominique

hello
pour ma part, je préfère un seul fichier, au pire que je divise en 2 voire 3 (front office, back office, textes communs). Mais je trouve plus difficile de faire "1 fichier par page", pour la maintenance, et puis ça fait plus d'appels de fichiers ...

Surtout que souvent, les pages ont certains msg en commun
 
Perso, je fais un fichier par langue.

Perso je fais un fichier que j'appelle location.
Je met toutes mes traductions dedans et je sépare les différentes langues par des commentaires visibles

Si le soft est "gros", tu risques d'avoir au final un fichier location vachement gros ! En plus, tu vas consommer de la mémoire pour rien puisque tu charges toutes les langues alors que t'en utilises qu'une.

Des mon côté, j'utilise des fichiers et la bdd, mais je préfère la bdd, c'est plus simple, plus propre et moins problématique pour les MAJ.

Ben avec la BD, pour les traductions, ça te fait plus d'accès en BD, même quand, à part les traduction, t'as rien à aller chercher en base Si ton site est à fort trafic, c'est pas optimisé...

C'est un petit peu hors sujet mais vous semblez vous y connaitre.
 
Pourquoi quand y a une alfa de Firefox ou Ubuntu par exemple qui sort, ils n'utilisent pas les traductions d'avant ? Seul l'anglais est dispo
 
Ils refont tout a chaque fois ?

Non, je pense pas qu'ils refassent tout de zéro mais quand tu développes un soft multi-langue, tu le fais que pour une langue (dans le cas de FF, l'anglais). Quand t'as tout fini et que le soft marche, ben tu mets à jour les fichiers de traduction des autres langues (c'est pas ce genre de fichier qui induit des bug généralement). FF étant traduit dans pleins de langues, l'équipe de dév principale n'est pas capable de faire toutes les traducs. En plus, ça serait contre-productif car en cours de dév, on rajoute/supprime/modifie les messages affichés dans l'IHM. Or à chaque message = une entrée dans le fichier de traduction.
 
Et ils peuvent pas diffuser une version d'un soft dont tous les msgs seraient pas traduits ou manqueraient (dans ce dernier cas, là, ça pourrait générer des bugs).
 
Edit ; je suis développeur, donc oui, j'ai qq connaissance en info

Il y a trois points à gérer :
 
1] Le premier truc à gérer sera l'inversion des mots selon la langue, il te faudra un système de variable
 
Ex : $this->translate('Fille de %ans ans', array('%ans'=>18)); // 18 years girl ou 18 year old girl
 
--
 
2] Il faut faire gaffe à la clé de traduction que tu vas utiliser.
 
Par exemple, si la clé de traduction est ton texte  
 
Ex : $this->translate('Ceci est un texte en français');
 
Tu peux avoir des soucis lors de la traduction de certains mots au pluriel :
 
Ex : $this->translate('%mois mois', array('%mois'=>1)) // 1 month
 
Ex : $this->translate('%mois mois', array('%mois'=>3)) // 3 months
 
Problème, la clé étant 'mois', on ne sait pas si on doit utiliser le pluriel ou le singulier.
Il te faudra une technique pour désambiguiser la clé de traduction.
 
--
 
3] Le dernier facteur à prendre en compte est que certaines langues possèdent des pluriels multiples, comme le russe (trois pluriels) ou le polonais (7 pluriels). Ce point peut être particulièrement compliqué à gérer.
 
--
 
D'une manière générale, les domaines couverts par la langue source et la langue de destination ne connaissent pas de bijection, il y aura toujours des approximations. L'idéal serait d'avoir comme langue source la langue la plus compliquée, mais je doute que ça soit une solution facile à gérer au quotidien ^.^

 
Le spécialiste des sites porn

pour ça aussi, ya des langues

Quel est l'intérêt de faire ça en base ? (sans parler du nombre de requêtes, qu'on peut optimiser un minimum).
Tenchniquement, en quoi ce serait plus facile à maintenir ?

L'intérêt de faire ça en base, c'est de proposer une IHM pour les country managers, et donc de faire des selects un peu touchy.
 
Dans cette optique, le fichier sert plus de cache qu'autre chose (Array Cache, le plus rapide qui soit en PHP).  
On le génère à chaque modification dans une langue donnée, puis on le load en début d'appli pour éviter de faire des requêtes.
 
Après si t'es tout seul à développer, rien ne t'empêche d'écrire les traductions directement dans ton fichier de trad...

PHP intègre nativement une API destinée à la gestion des langues : http://php.net/manual/fr/book.gettext.php
 
Les traductions peuvent être éditées manuellement dans des fichiers texte .PO, puis compilé en .MO pour utilisation optimisée sur serveur de production.