Méthode de développement multilingue

Salut,

Je voudrais avoir vos avis et expériences sur le développement de logiciels ou petites applications multilingues.

En fait, je suis en train de développer un petite application graphique, un GUI quoi et actuellement, c'est en français. Donc, les menus, textes, messages d'erreurs, d'avertissements, etc, tout est en français.

Je me suis dit qu'il serait peut être intéressant que l'utilisateur puisse utiliser l'application également en anglais s'il ne comprend pas le français. Le but serait donc qu'à l'ouverture de l'application, il puisse choisir sa langue.

Ma question est la suivante : d'un point de vu conception, comment faites vous pour développer une application multilingue ? Avez vous chaque script en double (un en français et un en anglais ) ? ou bien dans chaque script le code est il séparé en 2 ? Si oui, si on doit faire une application en 10 langues, ça va devenir un sacré foutoir non ? Ou bien, tout ce qui doit afficher du texte est il dans un script donné ? Bref, comment vous y prenez vous ?

Merci pour vos futurs réponses

tu avais tout un débat déjà fait ici :

Quel concept pour créer une application multi-lingue ?

et aussi


internationaliser une application

ou

passer un logiciel en bilingue

merci

Bon je me réponds.

Chacun fait à sa sauce. Certains utilisent un fichier ini par langue afin de stocker tous les textes nécessaires à leur application. Tous les fichiers .ini ont des noms de variables en anglais et les valeurs sont en fonction de la langue, ce qui est pas mal pensé.
D'autres font des scripts tronqués en fonction du nombre de langues, ce qui est difficilement maintenable.

Dans tous les cas, il faut y penser avant le début de la conception :lol:

Citation:

---

Envoyé par djibril

Dans tous les cas, il faut y penser avant le début de la conception :lol:

---

disons qu'il faut surtout ne pas penser à la langue ;)

ou en tous cas y penser "dans l'absolu"..

Et donc penser à quelque chose "échangeable"..

Cela dépend aussi pas mal de ta plate-forme de développement (OS + langage + librairies)...

Sous Windows, par exemple, le cas classique est d'utiliser une DLL de ressources pour chaque langue. Sous Linux, tu peux avoir un équivalent (partiel) en faisant un SO exportant une seule méthode, du genre "const char* getResourceString ( int identifier )", qui te renverra les chaînes adéquates. Ces méthodes ont l'avantage de ne pas permettre l'édition aisée (voire triviale !) des chaînes de langue, et l'inconvénient de ne pas permettre l'édition aisée (voire triviale !) des chaînes de langue... ;)

Sur une cible bien plus réduite en terme de capacités, on aurait privilégié des tables "en dur" dans le code et/ou de la compilation conditionnelle.
Dans le cas des langages scriptés, c'est un peu plus complexe parfois.
C'est trivial si le script permet de faire une inclusion d'un autre script de façon dynamique, et c'est un demi-enfer dans le cas contraire (soit il faut tout charger, et c'est lourd, soit il faut modifier le script pour changer de langue et c'est lourd aussi).

Mais tu as bien analysé un des points critiques d'un tel développement : cela se prévoit dès le départ, et non pas en fin de projet... La seule exception que je connaisse à ceci, ce sont les modules d'aide à la traduction de certains RAD qui, au contraire, fonctionnent mieux sur un projet terminé. Mais si tu n'as aucun outil de ce genre, il vaut mieux prendre les devants.

Dans les langages/framework supportant l'internationalisation (genre Struts) t'as un fichier spécifique aux langues (enfin t'en crées un par langue) où tu mets que telle "variable" (jsais pas comment appeler ça) vaut tel texte.
Dans ton application/site tu n'as donc aucun texte en dur mais tu fais appel à ces "variables" et le navigateur (pour mon cas jamais fait d'appli multilangues donc je m'avance pas trop de ce côté) prend sa langue et le site te renvoie automatiquement la version correspondante si existante.

Donc oui c'est quelquechose à prévoir dès le début d'un projet, je dirais même que, même si ya une infime chance qu'il soit internationalisé, utiliser les possibilités à sa disposition pour utiliser cet aspect.

Personnellement je l'utilise même si j'en ai pas besoin, ça me permet de changer un texte présent sur plusieurs pages une seule fois et qu'il soit répercuté automatiquement sur toutes :ccool:

Citation:

---

Dans tous les cas, il faut y penser avant le début de la conception

---

C'est mieux en effet.
Mais il reste toujours la solution de créer un fichier texte de traduction avec le message en français et ses traductions dans les différentes langues.
Exemple:

Code:

---

1 2 3 4 5

F ;GB;D --;--;-- Bonjour;Hello;Guten tag Erreur fatale;Fatal error;Kolossal problem

---

Dans le code on remplace :

Code:

---

Write("Bonjour") ;

---

par :

Code:

---

1 2 3 4

// On initialise le traducteur Traducteur MonTraducteur= new Traducteur("MonFichier.txt","GB") ; // ... Write(MonTraducteur.Translate("Bonjour")) ;

---

Citation:

---

Envoyé par Graffito

C'est mieux en effet.
Mais il reste toujours la solution de créer un fichier texte de traduction avec le message en français et ses traductions dans les différentes langues.
Exemple:

Code:

---

1 2 3 4 5

F ;GB;D --;--;-- Bonjour;Hello;Guten tag Erreur fatale;Fatal error;Kolossal problem

---

Dans le code on remplace :

Code:

---

Write("Bonjour") ;

---

par :

Code:

---

1 2 3 4

// On initialise le traducteur Traducteur MonTraducteur= new Traducteur("MonFichier.txt","GB") ; // ... Write(MonTraducteur.Translate("Bonjour")) ;

---

---

c'est vrai, mais le plus souple est de mettre

Code:

---

1 2 3 4

// On initialise le traducteur Traducteur MonTraducteur= new Traducteur("MonFichier.txt","GB") ; // ... Write(MonTraducteur.Translate("Bonjour_id")) ;

---

Comme ça, on n'a pas le problème des caractères accentués, des mots composés dans une langue et non dans l'autre, des phrases sur plusieurs lignes, etc etc..

Dans pas mal de langages, on utilise la lib gettext qui est le standard en la matière. Les ressources linguistiques (chaînes de caractères traduites) sont stockées au format .po (cf logiciel poEdit). Exemple en PHP :
Au lieu de faire

Code:

---

echo "mon super texte";

---

On fait :

Code:

---

1 2	setlocale(LC_ALL, 'de_DE'); // pour mettre en allemand par exemple echo gettext("mon super texte");

---

L'extension ira chercher le texte correspondant dans les fichiers de traduction. Il y a donc une langue "maître" (par défaut) qui reste dans les fichiers source, et les autres langues que tu souhaites mettre à disposition doivent être gérées dans des fichiers séparés.

Gettext est tout de même un standard raisonnable, pas parfait (loin de là, le problème des applications multilingues n'est pas simple, après tout) mais il fournit au moins un ensemble d'outils supportant la traduction et est généralement accessible dans tous les langages de programmation répandus, par exemple en Perl Locale::TextDomain est pas trop mal.

--
Jedaï

Citation:

---

Envoyé par Jedai

Gettext est tout de même un standard raisonnable, pas parfait (loin de là, le problème des applications multilingues n'est pas simple, après tout) mais il fournit au moins un ensemble d'outils supportant la traduction et est généralement accessible dans tous les langages de programmation répandus, par exemple en Perl Locale::TextDomain est pas trop mal.

--
Jedaï

---

Hum ... un module Perl que je connaissais pas. A creuser :ccool:

Citation:

---

Envoyé par djibril

Ma question est la suivante : d'un point de vu conception, comment faites vous pour développer une application multilingue ?

---

Ma réponse va sans doute être démesurée par rapport à ton problème, mais puisqu'on est dans le forum "best of" autant en profiter pour élargir le problème...

En général, le problème n'est pas seulement de rendre l'appli "multilingue" (simple traduction de la langue de l'IHM) mais plus "international" : Utilisable/utilisée dans plusieurs pays.

La conception doit alors prendre en compte deux conceptes opposés :
1. La première étape est la globalisation : Cette étape consiste à rendre l'application totalement indépendante de toute culture, de toute langue, option régionale... Concrêtement, pour toi ça veut dire ne pas mettre tes messages en dur dans tes scripts mais appeler une fonction pour obtenir le libellé à afficher.
Ce concepte/etape te pousse donc à obtenir une appli qui contiend uniquement le tronc commun, indépendant de toute option régionale ou linguistique. L'appli n'est plus liée à la moindre langue. Tout ce qui est spécifique à une culture est paramétré/externalisé... (message, langue, ordre de tri, format d'affichage, images...).

2. La deuxième étape est la localisation : C'est l'opération exactement inverse. Durant cette étape, tu écris les fichiers de traduction pour les messages et l'IHM. Mais selon les besoins, ça peut aussi aller beaucoup plus loin.
Tu peux aller plus ou moins loin dans la localisation. Idéalement, si tu changes de langue, tu changes de culture. Donc tu peux avoir besoin d'effectuer de profonds changements dans l'IHM (par exemple écrire de droite à gauche au lieu de gauche à droite), les codes couleurs que tu avais n'auront peut-être pas la même signification pour tes utilisateurs...
Tu peux même parfois être contraint de modifier ton fonctionnel pour t'adapter à la législation locale (voir à des besoins spécifiques des utilisateurs)...

Concernant la "simple" traduction de l'IHM dans une autre langue. Il faut faire attention à quelques points :
- Un même mot dans une langue peut avoir besoin d'une traduction différente dans une autre langue si on change de contexte. C'est pourquoi, comme l'a fait remarquer souviron34 il est préférable d'avoir un identifiant par message (et deux identifiants différents si le même message est affiché à deux endroits différents) plutôt que de faire de la traduction "phrase à phrase" indépendemment du contexte.
- L'ordre des mots peut (et c'est même une quasi certitude) être différent d'une langue à l'autre. Donc il faut faire attention aux messages paramétrés. Il vaut mieux prévoir de traduire un message avec des jokers à la place des paramètres ("L'article %s n'éxistent pas !"), plutôt que de construire le message dynamiquement en concaténant des bouts de messages traduit individuellements...

:ccool:, merci pour tes explications.

dans pspad, voici un exemple du fichier french.ini

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61

; French localization for PSPad text editor 4.5.3 (2283) ; Translation: Jean-Christophe Meylan <jcmeylan@bluemail.ch> ; http://www.pspad.com, mailto:support@pspad.com [Author] Name=Jean-Christophe Meylan E-mail=jcmeylan@bluemail.ch WWW=http://www.pspad.com [Common] DefaultCharset=0 DefaultFont=MS Shell Dlg [Action List] aAbout_Caption=A propos... aAbout_Hint=Information à propos de l'éditeur PSPad aAddDiacritic_Caption=Ajouter les signes diacritiques aAddFile_Caption=Ajouter ce fichier au projet aAddFile_Hint=Ajouter ce fichier au projet aAddFilesToFolder_Caption=Ajouter des fichiers... aAddFolder_Caption=Créer dossier aAddFolder_Hint=Créer un nouveau dossier dans la structure du projet aAllToASCII_Caption=Supprimer les signes diacritiques aAllToASCII_Hint=Supprimer les accents des caractères aASCII_Caption=&Table ASCII... aASCII_Hint=Afficher la table ASCII aAutoCompl_Caption=Auto-complétion aAutoRefresh_Caption=Actualisation automatique aBaseCalc_Caption=Conversions de bases... aBlockAlign_Caption=Justifier le bloc aBlockCenter_Caption=Centré aBlockLeft_Caption=Aligné à gauche aBlockRight_Caption=Aligné à droite ... ... [General Strings] rs_AddToProject=Ajouter le fichier "%s" dans le projet ? rs_AktVersion=Vous utilisez la dernière version disponible: rs_All=&Tout rs_AllFiles=Tous les fichiers rs_Apply=Appliquer rs_ASCIITable=Table ASCII rs_ASCIITitleLine=Table ASCII page de code Windows ANSI Imprimé par l'éditeur PSPad rs_Asterisk=Statistiques rs_AttribInfo=Attributs du fichier: %s rs_BadExpression=Erreur dans l'expression recherchée rs_BlockConfirm=Etes vous certain(e) de vouloir lancer l'action "%s" pour le document entier ? rs_Bookmark=Signet rs_Cancel=&Annuler rs_CannotOpenFile=Impossible d'ouvrir le fichier %s rs_Center=Centré rs_Changed=Modifié rs_Char=Car. rs_ClipNoHTML=Le presse-papiers ne contient pas de format HTML rs_Close=Fermer rs_CloseAllFiles=Fermer tous les fichiers ouverts ? rs_CloseAllquestion=Etes-vous sûr(e) de vouloir fermer tous les fichiers ouverts ? rs_CloseProject=Fermer le fichier projet ? rs_CodePage=Code de la page: rs_CompError=Erreur rencontrée durant la compilation. Voulez-vous modifier les options du compilateur ? rs_ConfirmCloseApp=Etes-vous sûr(e) de vouloir fermer PSPad ? rs_ConfirmDelete=Etes vous certain(e) de vouloir effacer "%s" ?

---

Bonjour,

Plutot que d'avoir un fichier "French.ini", "English.ini", "XX.Ini il sera plus simple de maintenir un fichier unique du genre:

Code:

---

1 2 3 4 5 6 7 8

[Action List] FR.aAbout_Caption=A propos... GB.aAbout_Caption=About ... XX.aAbout_Caption=xxxx ... FR.aAbout_Hint=Information à propos de l'éditeur PSPad GB.aAbout_Hint=Information on PSPad editor XX.aAbout_Hint=xxxx PSPad xxxx

---

Citation:

---

Envoyé par Graffito

Bonjour,

Plutot que d'avoir un fichier "French.ini", "English.ini", "XX.Ini il sera plus simple de maintenir un fichier unique du genre:

Code:

---

1 2 3 4 5 6 7 8

[Action List] FR.aAbout_Caption=A propos... GB.aAbout_Caption=About ... XX.aAbout_Caption=xxxx ... FR.aAbout_Hint=Information à propos de l'éditeur PSPad GB.aAbout_Hint=Information on PSPad editor XX.aAbout_Hint=xxxx PSPad xxxx

---

---

ça dépend des projets, en général...

• Si l'appli n'est pas trop sensible au secret, par exemple, et qu'il n'y a pas multitudes de langues mais de 2 à 4 ou 6, effectivement, comme je l'avais mentionné dans mon exemple de code en C, tu peux faire un seul fichier, que moi personellement je construit comme
  
  
  Code:

  ---

  1 2 3 4 5 6 7 8 9 10 11 12 13

  .LANGUAGES = français, english, deutsch LABEL_OUI { "Oui", "Yes", "Ja" } LABEL_NON { "Non", "No", "Nein" }

  ---

  
  
• Par contre quand il y a beaucoup de langues prises en compte, ou que l'application est sensible (secret), ou encore qu'il y a beaucoup de texte, il peut être plus judicieux d'avoir un fichier par langue...
  
  De plus, à cause des caractères de certains types (exemple le chinois), dans ce cas en général un fichier par langue est quasiment obligatoire à cause des charsets.

Oui, il faut voir aussi que ce n'est pas toujours toi qui fait la localisation.

Tu ne maitrises pas nécessairement toutes les langues dans lesquels l'appli doit être traduite.
Donc tu là fais faire par des prestataire, des interprêtes, voir tu n'as peut-être aucune emprise dessus (ça peut être la responsabilité d'un importateur/distributeur)...
Dans ce cas, il est plus pratique d'avoir des fichiers distincts par langue, que de devoir ensuite encore intégrer toutes les traductions dans un seul fichier.

Citation:

---

Envoyé par Graffito

Plutot que d'avoir un fichier "French.ini", "English.ini", "XX.Ini il sera plus simple de maintenir un fichier unique du genre:

---

C'est souvent bien plus pratique d'avoir un fichier par langue : la maintenance d'une langue n'impacte pas les autres, et cela permet une meilleure parallélisation du travail de traduction.
Rien n'empêche, au besoin, d'inclure tous ces fichiers dans un container unique par la suite (archive, DLL de ressource, etc.) pour rendre la distribution plus pratique, mais rien que les problèmes d'encodage justifient de séparer chaque langue des autres.

De plus, côté programme, c'est plus pratique : le changement de langue est alors équivalent à un chargement d'un fichier particulier, le reste du code n'ayant absolument pas besoin de "propager" la notion de langue partout, ni même de savoir qu'il existe d'autres langues.

Citation:

---

Envoyé par Mac LAK

De plus, côté programme, c'est plus pratique : le changement de langue est alors équivalent à un chargement d'un fichier particulier, le reste du code n'ayant absolument pas besoin de "propager" la notion de langue partout, ni même de savoir qu'il existe d'autres langues.

---

Inversement, cela rend le changement dynamique plus complexe.. ;)

La structure que j'ai mentionné était par exemple pour un pays bilingue (le Canada).

Dans ce pays, toute agence fédérale doit pouvoir fonctionner dans les 2 langues officielles. Dans ce cas, l'IHM propose un changement de langue dynamique, sans re-démarrer le logiciel.

Cela peut se faire des 2 manières, bien entendu. Celle qui m'avait paru la plus évidente était celle du fichier unique.

Maintenant, comme on l'a dit, les arguments et les manières de faire dépendent des projets, des langues, des structures de marketing (si il y en a) etc etc..

Mais nous avons exposé, je pense, les 2 bonnes manières de faire..

Citation:

---

Envoyé par souviron34

Dans ce cas, l'IHM propose un changement de langue dynamique, sans re-démarrer le logiciel.

---

Et qu'est-ce qui empêche ça avec des fichiers séparés ? ;)

Quand j'utilise cette technique, pour ma part, j'effectue les opérations suivantes :

• Une langue de référence est chargée par défaut (anglais dans 99% des cas). Cette langue est incluse "en dur" dans le programme, et ne peut donc pas être supprimée.
• J'applique les réglages généraux adaptés à cette langue par défaut (encodage au minimum).
• La langue choisie est ensuite chargée en lieu et place de la langue de référence. Tout ce qui est traduit est donc remplacé, et les "oublis" de traduction restent en anglais (plutôt que d'être des chaînes vides, ou pire, des chaînes invalides).
• Les réglages propres à la langue choisie sont appliqués. Si aucun réglage n'est spécifié pour un réglage donné (ex : sens d'écriture), c'est celui de la langue par défaut qui s'applique.
• Un réaffichage est ensuite déclenché (dépend du système/langage/GUI bien sûr).

Comme tu l'auras compris, je mets en mémoire le contenu du fichier de langue à l'avance, sous forme d'un tableau quasi-statique. Chaque identifiant est un numéro unique (de type énumération), en liste brûlée (aucun identifiant ne peut être réaffecté à une ressource différente), et je tape directement dans une table de chaînes pour récupérer ce qui doit être affiché.
Donc, le changement de langue n'est qu'une fonction bête et méchante chargeant un fichier, toute la difficulté consiste à ne pas autoriser un tel changement si une opération est en cours.

Côté code, cela peut être stocké dans un tableau, une map, une liste chaînée au besoin, peu importe.


Par contre, tu as raison sur un point : certains systèmes de traduction plus ou moins automatiques requièrent un redémarrage du programme afin de "remplacer" les ressources binaires contenant les éléments localisés.

Juste pour information, dans l'éditeur de Texte PSPad, il y a 36 langues (dont chinois, grec, etc). Donc les 36 fichiers + 36 icônes du pays sont dans un répertoire lang. Je trouve cette technique plutôt propre, facile à maintenir. Avoir le tout dans un seul fichier => de charger tout le fichier en mémoire inutilement, mais bon, tout dépend de l'application.

Citation:

---

Envoyé par Mac LAK

Mais tu as bien analysé un des points critiques d'un tel développement : cela se prévoit dès le départ, et non pas en fin de projet... La seule exception que je connaisse à ceci, ce sont les modules d'aide à la traduction de certains RAD qui, au contraire, fonctionnent mieux sur un projet terminé. Mais si tu n'as aucun outil de ce genre, il vaut mieux prendre les devants.

---

+1, c'est le cas en Delphi.

Assez lourd cependant, j'utilise plutôt la technique du 1 fichier/langage (INI ou XML) qui permet aisément le changement dynamique. Inconvénient : les textes sont visibles et modifiables par tout le monde...