[0.9.29] Réactualiser la langue (fr/us) d'une Form

Bonjour,

J'ai besoin d'utiliser une Form bilingue. Classiquement, j'emploie les fichiers project1.fr.po et project1.en.po. Je peux donc afficher ma Form1 en anglais ou en français.

Voici un extrait du project1.fr.po généré [i18n activé]

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

msgid "" msgstr "Content-Type: text/plain; charset=UTF-8"   #: form1.rsbtvalidcaption msgctxt "form1.rsbtvalidcaption" msgid "Yes" msgstr "Oui"     #: TFORM1.BUTTON1.CAPTION msgctxt "TFORM1.BUTTON1.CAPTION" msgid "Yes" msgstr "Oui"   #: TFORM1.BUTTON2.CAPTION msgctxt "TFORM1.BUTTON2.CAPTION" msgid "Language" msgstr "Langue"

---

Dans le code d'unit1

Code:

---

1 2 3

implementation ResourceString rsBTvalidCaption = 'Yes';

---

Mon problème est le suivant : je veux changer la langue de ma Form1 sans "la fermer puis la réouvrir" afin de ne pas être obligé de sauver les données "actives".

Ce code fonctionne correctement...

Code:

---

1 2 3 4 5 6 7

procedure TForm1.Button2Click(Sender: TObject); begin gsFallbackLang :='en'; gsLang:='en_US'; Change_Language(); //Fonction Perso Button1.Caption:= rsBTvalidCaption; end;

---

... mais m'oblige à déclarer rsBTvalidCaption alors que #: TFORM1.BUTTON1.CAPTION est généré automatiquement par défaut sans déclaration de ResourceString.

Mais comment l'appelle-t-on ?
Button1.Caption:= TFORM1.BUTTON1.CAPTION ne fonctionne évidemment pas.

A moins que quelqu'un(e) ne connaisse la méthode pour réaffecter dynamiquement les "variables" du fichier .po (une fois relu) dans les Forms ouvertes... ce qui serait très pratique notamment pour les traductions des Dialogs à partir de lazarus\lcl\languages\lclstrconsts.xx.po (toujours sans fermer les Forms ouvertes).

Merci. Cordialement.
Gilles

OK C'est bon. C'est réglé en quelques lignes finalement.

Cela fonctionne dynamiquement à la demande pour les boutons des objets de Dialogs.

Cependant pour conserver un code simple (sans potranslation que l'on voit souvent cité), l'utilisation de RessourceStrings reste indispensable

• pour déclarer le Titre et le Message des MessageDlg
• et pour les captions des units par exemple

Mais l'ensemble reste "souple", dynamique et facile à maintenir.

Cordialement. Gilles

Bonjour
Voici un petit CR :

La première chose à faire est d'activer i18n dans votre projet : Projet --> option
http://www.selzig.com/1007021000/1.png
Le répertoire "languages" (ou autre) contiendra les fichiers .po de traduction.

Ceci fait :

• Pour que les captions des boutons Dialogs soient traduits

Recopiez lazarus/lcl/langages/lclstrconsts.po et les lclstrconsts.fr.po,lclstrconsts.en.po... nécessaires dans votreappli/languages

Pour rafraîchir dynamiquement, on place ce code dans un TButton par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

{uses Translations} var PODirectory, Lang, FallbackLang: String; begin PODirectory := IncludeTrailingPathDelimiter( IncludeTrailingPathDelimiter( ExtractFilePath(Application.ExeName))+'languages'); Lang:='fr_FR';FallbackLang:= 'fr'; Translations.TranslateUnitResourceStrings('LCLStrConsts', PODirectory + 'lclstrconsts.'+FallbackLang+'.po', Lang, FallbackLang); MessageDlg('Titre du message, 'Text du message', mtInformation, [mbOk, mbCancel, mbYes], 0); end;

---

Pour l'anglais (dans un autre TButton): Même code que ci-dessus mais on change la langue utilisée :

Code:

---

Lang:='en_US';FallbackLang:= 'en';

---

On peut également détecter la langue par défaut du PC ;

Code:

---

1 2	{uses gettext;} GetLanguageIDs(Lang, FallbackLang);

---

Ces codes traduiront les messages affichésdans les boutons Yes --> Oui -->Ya... des objets Dialogs seulement

• Pour que les captions des autres éléments de la Form, les Titres et les Textes des Dialogs soient traduits

J'ai créé une unit1_rs (ressource de unit1)

Code:

---

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

unit Unit1_rs; {$mode objfpc}{$H+} Interface Uses Classes, SysUtils; Resourcestring FormCaption = 'English Title'; Button1Caption = 'Button 1'; Button2Caption = 'Button 2'; MessageTitle = 'Message Title'; MessageText = 'Message Text'; // etc.... Implementation End.

---

...appelée ainsi classiquement dans unit1

Code:

---

1 2 3

uses Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls, Translations, unit1_rs;

---

et toujours dans unit1 le code complet d'un bouton de MAJ français serait

Code:

---

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

var PODirectory, Lang, FallbackLang: String; begin PODirectory := IncludeTrailingPathDelimiter( IncludeTrailingPathDelimiter( ExtractFilePath(Application.ExeName))+'languages'); Lang:='fr_FR';FallbackLang:= 'fr'; Translations.TranslateUnitResourceStrings('unit1_rs', PODirectory + ExtractFileNameOnly(Application.ExeName)+'.%s.po',Lang, FallbackLang); Form1.Caption:= FormCaption; Form1.Button1.Caption:= Button1Caption; Form1.Button2.Caption:= Button2Caption; Translations.TranslateUnitResourceStrings('LCLStrConsts', PODirectory + 'lclstrconsts.'+FallbackLang+'.po', Lang, FallbackLang); //ou Translations.TranslateUnitResourceStrings('LCLStrConsts', PODirectory + // 'lclstrconsts.'+'.%s.po',Lang, FallbackLang); //cela semble équivalent MessageDlg(MessageTitle, MessageText, mtInformation, [mbOk, mbCancel, mbYes], 0);

---

Reste qu'il faut bien entrer la traduction quelque part :
Lors du Run de votre appli, un fichier project1.po a été construit dans votreappli/languages

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

msgid "" msgstr "Content-Type: text/plain; charset=UTF-8"   #: TFORM1.BUTTON1.CAPTION msgid "Button1" msgstr ""   #: TFORM1.BUTTON2.CAPTION msgid "Button2" msgstr ""   #: TFORM1.BUTTON3.CAPTION msgid "Button3" msgstr ""   #: TFORM1.FORM1.CAPTION msgid "Form1" msgstr ""   #: unit1_rs.button1caption msgid "Button 1" msgstr ""   #: unit1_rs.button2caption msgid "Button 2" msgstr ""   #: unit1_rs.formcaption msgid "English Title" msgstr ""   #: unit1_rs.messagetext msgid "Message Text" msgstr ""   #: unit1_rs.messagetitle msgid "Message Title" msgstr ""

---

Vous le copiez en project1.en.po et en project1.fr.po. Vous ne touchez pas au project1.en.po qui est la langue par défaut et vous mettez la traduction dans le project1.fr.po ainsi

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

msgid "" msgstr "Content-Type: text/plain; charset=UTF-8" #: TFORM1.BUTTON1.CAPTION msgid "Button1" msgstr "" #: TFORM1.BUTTON2.CAPTION msgid "Button2" msgstr "" #: TFORM1.BUTTON3.CAPTION msgid "Button3" msgstr "" #: TFORM1.FORM1.CAPTION msgid "Form1" msgstr "" #: unit1_rs.button1caption msgid "Button 1" msgstr "Bouton 1" #: unit1_rs.button2caption msgid "Button 2" msgstr "Bouton 2" #: unit1_rs.formcaption msgid "English Title" msgstr "Titre français" #: unit1_rs.messagetext msgid "Message Text" msgstr "Texte du message" #: unit1_rs.messagetitle msgid "Message Title" msgstr "Titre du message"

---

Vous remarquerez que je n'ai pas utilisé les TFORM1.BUTTON1.CAPTION et autres (donc pas traduits). Je n'ai pas réussi à les appeler dynamiquement dans le programme même à l'aide de l'unit poTranslation que l'on trouve sur le Web. D'autre part, j'ai lu que cette unit posait problème sur certains éléments de la Form [par exemple les Gtids.Columns(x].Title]. Bref, il faudrait, trier les composants... Faisable mais compliqué et lourd.

Une dernière chose, encodez les fichiers en UTF8 sinon les ç, é et autres... poseront problèmes [Notepad++ --> Encodage]

Cordialement. Gilles

Bonjour,

Un des problèmes du système I18n est qu'il ne semble pas fonctionner sous Lazarus+Windows (au moins en 0.28.2). La fonction GetText se compile mais arrête l'exécution. Peut-être que cela peut se solutionner, mais je ne sais pas comment.

Mais surtout, je trouve très lourd de mettre en œuvre les fichiers de ressources, et il faut des compétences de programmeur pour traduire ou corriger les traductions.

J'ai mis au point il y a près de 10 ans, avec Delphi, un autre moyen qui a donné entière satisfaction sur un projet comportant plus d'un millier de contrôles visuels.

En résumé, on parcourt tous les contrôles d'une Form à sa création et leur donne les bons textes à partir d'un fichier .ini par langue. C'est extrêmement rapide avec les machines actuelles.

J'emploie ce système avec gestinux que je suis en train de développer et je vais (bientôt) le documenter. Les sources sont d'ores et déjà disponibles sur SourceForge.

A terme, j'envisage de rendre possible une traduction directement sur l'application. Il faudra faire des composants dérivés, mais c'est assez facile à concevoir.

Tintinux

Bonjour,

Je viens de (re)vérifier avec Lazarus-0.9.29-26377-fpc-2.4.1-20100701-win32.exe : GetLanguageIDs(Lang, FallbackLang); // uses gettext; fonctionne normalement.

La 0.9.29 est très prometteuse par rapport à la 0.9.28. Certaines units ont été réécrites et le code me semble stabilisé (ou en voie de l'être). Il sera donc probablement plus facilement maintenable et aura de ce fait une meilleure capacité d'évolution que ne permettent certaines units "rustinées" au fil du temps. La 0.9.30 devrait être quelque chose de "vraiment mieux" pas nécessairement par ses nouveautés mais surtout par la qualité du socle (notamment la LCL) sur laquelle elle repose.

Je dois également reconnaître que je ne suis pas un grand adepte du traitement automatisé systématique. Les traductions dans chacune de mes Forms restent quantitativement limitées. J'ai vu par exemple qu'il existait une solution pour "translater" automatiquement les captions et autres titles d'une Form (la fameuse -et trop astucieuse pour moi- potransposition.pas)... sauf qu'elle est intimement liée au codage de la LCL. Et donc en cas de prob. comme par exemple un bug sur la Grid.Column[x].title, le travail de déverminage et de correction est impressionnant... et malvenu : quand je travaille sur la LCL, je ne travaille pas sur mon appli... faute de capacité à pouvoir mener les 2 de front : ce n'est pas le même métier.

Et comme vous le faisiez remarquer Lazarus n'est pas "encore" stable dans tous les domaines et il ne le sera jamais car les OS évoluent eux aussi en permanence. Ne serait-ce que de s'adapter aux évolutions de Gtk2 représente un vrai challenge pour un langage compilé qui génère également du code Windows et Mac à partir d'une xCL commune. Bref dans ce cas (la traduction de quelques contenus statiques), je préfère la simplicité à l'automatisation. J'ai préféré abandonner le traitement des TFORM1.xxxx.xxx n'ont pas que cela ne soit pas faisable (à priori... je n'ai pas trouvé de solution effective dans le temps que je m'étais imparti) mais parce que dans mon cas ce n'était pas "rentable" si je peux m'exprimer ainsi. Ce qui ne dénigre absolument pas votre travail. Au contraire ! Plus les solutions sont nombreuses, plus les garanties au niveau des possibilités (ie de la faisabilité à un moment t avec une version x) de développement des applications sont importantes. Après, en fonction de ses besoins, chacun choisit la solution qui lui semble le plus adaptée.

Par contre, l'utilisation de i18n me semble cohérente. Imbécilement, j'allais écrire "évidente". C'est un standard éprouvé, utilisé dans de nombreux langages compilés ou non... Mais réflexion faite, les standards évoluent... et/ou sont faits pour être remis en cause.

Citation:

---

En résumé, on parcourt tous les contrôles d'une Form à sa création et leur donne les bons textes à partir d'un fichier .ini par langue. C'est extrêmement rapide avec les machines actuelles.

---

J'ai vu en effet un système du même genre. C'est le "à sa création" qui me pose problème : je voulais un changement dynamique sans réaffichage de la Form afin de préserver ses contenus "actifs" (comme les Tedit.text modifiés par l'utilisateur). J'ai vu que certains les enregistraient, fermaient la page, puis la réouvraient et rechargeaient les données sauvegardées au moment de la fermeture. C'est également une solution mais ce n'est pas ce que je cherchais.


Cordialement. Gilles

Citation:

---

Envoyé par selzig

La 0.9.29 est très prometteuse...

---

Je ne parviens pas à l'installer et je n'ai pas envie d'y passer des journées et de devoir maintenir une version non stable. Je m'en tiens donc à la 0.28.2 qui ne me pose pas de problème insurmontable. Comme tu dis, ça doit être un autre métier.

Mais j'attends avec impatience...

Citation:

---

Envoyé par selzig

Bonjour,
Je viens de (re)vérifier avec Lazarus-0.9.29-26377-fpc-2.4.1-20100701-win32.exe : GetLanguageIDs(Lang, FallbackLang); // uses gettext; fonctionne normalement.

---

Bonne nouvelle !

Pourrais-tu me transmettre le code de cette fonction en 0.29 car je ne vois pas comment on trouve le code langage sous la forme XX_xx (FR_fr pour français) dans Windows.

Ce système donne le code ISO (ONU) à 3 lettres (FRA pour Français) qu'on trouve dans la base de registre de l'utilisateur. Une fois n'est pas coutume, ils me semblent plus près des standards internationaux que Linux... L'idéal serait à mon avis de trouver le code ISO dans Linux.

Citation:

---

Envoyé par selzig

C'est le "à sa création" qui me pose problème : je voulais un changement dynamique sans réaffichage de la Form afin de préserver ses contenus "actifs" (comme les Tedit.text modifiés par l'utilisateur).

---

Pour info, mon système n'oblige pas à traduire à la création de la Form, et permet de traduire n'importe quand, notamment après un changement du langage. Il est donc tout à fait dynamique.

D'autre part les TEdit.Text ne sont pas traduits, et je ne vois pas pourquoi ni comment il pourraient l'être. Seuls les Hint sont traduits dans les TEdit.

Cordialement.

Tintinux

Bonjour,

Pour utiliser la procédure, vous l'écrivez telle quelle:

Code:

---

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

{uses Translations} var PODirectory, Lang, FallbackLang: String; begin PODirectory := IncludeTrailingPathDelimiter( IncludeTrailingPathDelimiter( ExtractFilePath(Application.ExeName))+'languages'); //Lang:='fr_FR';FallbackLang:= 'fr'; GetLanguageIDs(Lang, FallbackLang); //Cette procedure charge les valeurs de l'OS dans Lang et FallbackLang; //Pour vérifier Showmessage(Lang+' : '+FallbackLang); //Suite du code Translations.TranslateUnitResourceStrings('LCLStrConsts', PODirectory + 'lclstrconsts.'+FallbackLang+'.po', Lang, FallbackLang); MessageDlg('Titre du message, 'Text du message', mtInformation, [mbOk, mbCancel, mbYes], 0); end;

---

Résultat sous Windows:

http://www.selzig.com/1007021000/2.png

Pour ce qui est de traduire les edit.text, je crois que vous avez mal lu ce que j'ai écrit.

Pour le reste, je ne compare pas les 2 méthodes et ne mésestime ni ne critique la vôtre que je ne connais pas. J'ai simplement lu attentivement ce que vous avez écrit.

Citation:

---

Envoyé par tintinux

[...]
J'ai mis au point il y a près de 10 ans, avec Delphi, un autre moyen qui a donné entière satisfaction sur un projet comportant plus d'un millier de contrôles visuels.

En résumé, on parcourt tous les contrôles d'une Form à sa création et leur donne les bons textes à partir d'un fichier .ini par langue. C'est extrêmement rapide avec les machines actuelles.

---

Et j'en ai déduit ce que j'ai écrit. Vous admettrez que c'est difficilement interprétable autrement. Le système i18n fait en gros la même chose sauf qu'il regroupe toutes les Forms en un seul fichier. Dommage que je n'arrive pas à utiliser le format natif genre TFORM1.BUTTON1.CAPTION mais je ne désespère pas... Pour l'instant, j'ai d'autres priorités... mais les vacances scolaires sont là...

Enfin, je ne porte pas de jugement sur les normes de Windows, Linux ou tout autre OS. (Toute convention vaut pour peu qu'elle réponde au cahier des charges.) J'apprécie autant l'un que l'autre des 2 premiers OS cités... Et c'est pourquoi j'apprécie tant Lazarus et FP.

Pour installer lazarus 0.9.29 FPC 2.4.1 par reconstruction des paquets deb à partir des SVN, je n'ai pas eu le temps encore de faire le CR. http://www.developpez.net/forums/d93...-svn-versions/ Par contre, je peux vous envoyer les 2 paquets que j'ai généré, il y a 2 semaines pour une Ubuntu 10.04 sans certitude si c'est une autre distribution ou une autre version.

A bientôt.
Cordialement. Gilles

Gilles,

Dans la version 0.28.2 que je possède sous Windows XP, la procédure GetLanguageIDs ne retourne qu'une chaîne vide, car elle cherche la valeur de 3 chaînes d'environnement qui n'existent pas sur ce système.

Si cela été changé dans la 0.29, comme vous semblez le prouver par l'essai effectué, pouvez-vous m'envoyer le code de cette procédure dans cette version ?

Pour le reste, je crois que c'est un autre débat...

Merci

Tintinux

Bonjour,

La procédure n'appartient pas à une unit Lazarus mais à FP... aussi je doute que cela fonctionne en remplaçant les fichiers

• fpc\2.4.1\source\packages\fcl-base\src\gettext.pp
• fpc\2.4.1\units\i386-win32\fcl-base\gettext.ppu (et .o)

que j'ai placé sur mon ftp. J'envoie l'adresse en message privé.

A mon avis, pour que la modification soit prise en compte il faut recompiler FP.

Si vous travaillez sous Windows, il est plus simple de télécharger la dernière version 0.9.29/2.4.1 et de l'installer http://www.hu.freepascal.org/lazarus/

Si vous êtes sur Linux, et si le FPC 2.4.1 est obligatoire, cela signifie qu'il faut recompiler FP. A moins que le FPC 2.4.0 convienne. Dans ce dernier cas, les paquets d'installation sont téléchargeables... Mais si tel n'est pas le cas, la seule solution est donc de charger les SVN et de créer les paquets .deb si vous utilisez une version avec un système de gestion de paquets créé par la communauté Debian. Je ne sais pas faire si vous utilisez du .rpm.


Cordialement. Gilles

Merci.

Je n'avais besoin que du source pour voir comment on fait sous Windows, et pas l'intention de le remplacer dans la 0.28, ni de passer en version SVN.

Tintinux