Salut la compagnie
J'aurai voulue savoir quelles méthodes étaient utiliser dans un projet professionnel pour gerer le plus simplement de traduction.

J'ai deja vue pas mal de cas diferent ma je voulai savoir ce qui était le mieux... (tableau dans fichier php, js, ... ; fichier yalm ; fichier xml ; divers fichiers vue dans le MVC):-k


1°) En gros ma première question est avant tous sur quelle support travaille les traducteurs (soft)?
2°) comment faire pour traduire des pages en gardant la mise en forme HTML (gras, italic, acconym,...) ?

En gros se que je souhaite faire c'est avoir en vue une methode de travail qui respect les methode de travail des traducteurs. De plus, je suppose que le traducteur ne travaille pas forcement sur du html et qu'il n'a bien sur pas forcement de bonne notions en informatique...

Merci d'avance pour vos retour d'experience

[EDIT] Je tenai quand même à préciser que je travail sur une approche MVC et que la solution que je recherche va de mise avec cette approche.

Y a deux méthodes :

Un système de template
ou un tableau géant du style :

echo $langue['fr']['page']['titre_menu-options];

Voilà je penses que c'est les seuls techniques "viables" mais y a que moi que ça engage

Perso, en général je fais des fichiers différents :
fr.lang.php
en.lang.php

et j'appel le bon fichier ...
Ca evite de charger des tableaux trop lourds

Une chose intéressante serait de gérer l'état des traductions.
Pour chaque terme : "non traduit", "traduit non vérifié", "vérifié". Ce qui te permettra de voir l'avancement des traductions.
Niveau interface, c'est "bateau" : deux colonnes, avec le terme à traduire à gauche et la traduction à droite... Il faut pouvoir les compiler (générer) d'un clic sur un bouton et les tester en ligne directement avec la bonne option...
Du moins c'est comme ça que je le vois.

si je te suis, en gros c'est soit au template. Donc un layout et des vue définit pour un template par traduction et ce traduit en dur
1°) c'est bien cela ?

Pour ce qu'il en ai du tableau géant, je dirait libre à toi de le mettre en 1 ou plusieurs fichiers pour optimisation Sinon dans cette voie, il est vrai que cela reste simple.

M'ai quand est il du traducteur (qui n'est pas forcement le développeur ) ??? Sur quoi travaillera il ?
De plus, je souhaite garder en vue que les mise en intonation du texte dans les page doit être impérativement conservé (gras, italic, abbreviation...)

Dans ma reflexion sur le sujet, j'estime que le developpeur travail depuis un cahier des charges, donc avec des textes imposés et établies avec le client. Donc 2 possibilité:
- le client fournis les textes et ce charge des traductions
- le client fournis les textes et demande d'assurer la traduction.

Dans ce second cas, si la traduction des texte doit être sous-traitée, il faut donc que le developpeur pose ces textes et leur mise en intonation (gras, italic, accronym) et le traducteur devra respecté ces directive afin de fournir des traductions conforme au intonation établie.

2°) donc sur quel support va travailler le traducteur (traitement de texte style office, open office, pdf je suppose) ?
3°) Enfin, sur ce qu'il en ai de la methode utiliser en fin de suivit pour mettre à plat les traductions dans le projet, le developpeur devra assurer le solution technologique pour proposer telle ou telle traduction. Si dans ce cas vous voyez d'autres methode simple et compatible à une approche MVC (autre que template ou array) ?

Merci d'avance pour vos retour d'experience

[EDIT] En gros je me demande si dans ce que je souhaite faire, il ne serait pas mieux de voir au module ou encore à la réécritute d'url. en gros avec une value par defaut de langue sans spécification à l'url et pour ce qu'il en est des autres langue, une spécification à l'url, de la sorte: http://www.mondomaine.tld/fr/controleur/action.php. Ceci permettrai au visiteur d'arriver directement sur sa langue en vue de sa recherche dans sa langue sur google par exemple

4°) si vous avez deja eut l'opportuniter de mettre en place un MVC via ce type d'url, comment fonctionne votre methode ? (chargement d'un module par langue pour definit un suffixe pour inclusion du bon fichier de trade pour les vues, ... ???)

Pour moi il n'y a qu'un système de traduction qui vaille le coup, gettext parceque c'est rapide, uniformisé et intelligent, l'appli en anglais par défaut les textes enrobé de jolis "_(" et ")" et le reste peut être interfaçé en php (création des bases de traductions comme leur remplissage) de plus c'est totalement indépendant des notions de templating et autres mvc donc pas de soucis d'implémentation ici.

my 2c

+1 pour Nagol, et si on ne comprend pas comment marche gettext de toute façon la base d'un bon système de traduction c'est :
- Partir de la chaine à traduire, et ne pas utiliser des espèces de "clés", cela permet d'avoir un fallback en cas d'absence de traduction.
- Utiliser une fonction dont on pourra étendre le comportement (pour remplir automatiquement les fichiers avec les traductions manquantes par exemple).

+1 à Nagol et Naholyr.
Gettext sera ton ami. Il gère les pluriels, les traductions partielles, etc. Tu as un éditeur libre et gratuit multi plates-forme qui est POEdit.
Gettext va te fournir des binaires que tu peux analyser. Il te fournira un tableau chaîne de référence -> chaîne traduite. L'énorme avantage est qu'il gère les pluriels, c'est terrible. Toutes les formes de pluriels. En français, on a juste 2 formes : si une personne, si plus de une personne. Mais en croate ou en polonais, tu arrives à 5 ou 7 pluriels il me semble (pour dire que c'est plus de 1) : si une personne, si deux, si entre 5 et 8, si plus de 13, etc. Ce sont des exemples, mais c'est pour te faire comprendre que c'est pas si simple, mais Gettext le gère merveilleusement bien.

On trouve aussi XLIFF, TMX, etc., mais j'ai jamais été convaincu. Vraiment, Gettext est de loin (de très loin) le meilleur.

Pour l'appeler, les méthodes sont toujours très simples : _('chaine à traduire').

Pas besoin de créer plusieurs vues dans ton MVC. Tu as la même vue, mais les données (les textes) sont attribuées depuis le contrôleur. Le modèle est le fichier Gettext (comparable à une base de données hein), le contrôleur pioche dedans et attribut le tout à la vue.

Gettext est basé sur la localisation. Il faut donc utiliser la localisation pour permettre de bien fonctionner. Juste fr, ne suffira pas. Il faut avoir la localisation sous le format iso-3166-1_alpha_2, soit fr_FR, ou fr_BE, en_US, en_GB, etc.

Enfin bon, cherche sur Internet, il y a beaucoup de chose sur Gettext. Ce format est en plus libre et documenté par GNU (logique).

Idem que mere-teresa, gettext est vraiment génial SI tu as la main sur le serveur
Sinon, tu risques d'avoir des problèmes.
Petite liste non exhaustive :
- il faut recompiler le fichier a chaque mise a jour
- il faut redémarrer apache à chaque mise à jour pour se débarasser du cache gettext
- il y a un problème qui se pose quand apache gère plusieurs appels par thread : en effet, la définition de locale dans gettext se fait au niveau du thread apache et pas au niveau de l'appel de page. Donc si deux personnes demandent une page dans une langue différente et que ces deux appels sont gérés par le même thread, la seconde verra sa page dans la langue de la première

A part ça, gettext c'est le pied

Pour ma part, je me suis programmé un paquetage (voir Hoa_Translate_Gettext) pour Gettext. C'est donc gérer par PHP, et pas par Apache. Le multi-thread fonctionne sans problème.

Pour la recompilation des .mo, de toute façon, tu le feras en locale. Tu vas écrire tes fichiers via POEdit par exemple, c'est beaucoup plus simple (et les traducteurs préfèrent). Tu compiles, et tu balances via FTP, j'ai du mal à voir où est le soucis .

Si certains disent que de parser les binaires avec PHP est long et coûteux, pensez aux caches . Une fois le binaire analysé, on obtient un tableau. On le sérialise, et on l'envoie dans un fichier, fin de l'histoire.

J'utilise Gettext sur des serveurs mutualisés où je n'ai qu'un accès par FTP et je n'ai pas rencontré de problème … Ah si, un seul, mais ça ne concerne pas vraiment Gettext. Lors de la localisation, il est très utile d'avoir des fichiers pour les taux monétaires et autre chose du genre. Ça, ça ne concerne pas Gettext, et il faut effectivement avoir la main sur le serveur. Ça concerne indirectement Gettext, car il utilise la localisation, mais bon, c'était une petite parenthèse .

Pour la recompilation des .mo, de toute façon, tu le feras en locale. Tu vas écrire tes fichiers via POEdit par exemple, c'est beaucoup plus simple (et les traducteurs préfèrent). Tu compiles, et tu balances via FTP, j'ai du mal à voir où est le soucis .

Certes, sauf si tu es sur windows et que ton serveur tourne sur linux, auquel cas le résultat de compilation de l'un n'est pas compatible avec l'autre

Ah mais oui, je suis con … J'y avais pas pensé ^^.
Bon, bah, mets toi aux machines virtuelles .

oki, merci à tous
Je regarderai donc du coté de HOA et du packetage gettext.
J'espère ne pas avoir trop de difficulté à prendre tout cela en main, mais l'idée semble bonne...
Bien mieux qu'un durpal pour les connaisseurs (uploder X fichier de trade dans X dossier les 1 apres les autres afin que ce dernier applique les trades, une catastrophe).

Merci à tous

PS. une dernière question: Est ce que gettext respecte la mise en forme du text (gras, italic, ...) ou doit on faire en sorte d'éclater en plusieurs variables un contenu avec des <b>, <i>, etc ?

Les balises qui apparaissent dans le message de référence apparaissent aussi dans le message traduit, je ne vois pas où serait le problème.

Ne va pas voir que Hoa hein, Zend Framework support aussi Gettext, mais aussi XLIFF, TMX, et encore d'autres.