Comment internationaliser une application avec Free Pascal/Lazarus

[Exemple TR_01]

Pour vous persuader que ce tutoriel peut vous éviter des désagréments y compris si vous n'envisagez pas de traduire vos applications, examinez le comportement d'un programme aussi élémentaire que celui-ci :

• créez un nouveau projet de type application ;
• modifiez la légende de la fiche (Caption) en la faisant passer de « Form1 » à « En français 1… » ;
• déposez un bouton TButton sur la fiche proposée ;
• modifiez la légende de ce bouton (Caption) en la faisant passer de « Button1 » à « Bouton » ;
• déposez un bouton avec glyphe TBitBtn sur la même fiche ;
• modifiez sa propriété de type (Kind) en la faisant passer de « bkCustom » à « bkYes ».

Voici l'aspect, à la conception, de votre préparation :

Compilez à présent votre application et lancez son exécution. Voici ce que vous obtiendrez :

Vous serez sans doute tenté de croire que la transformation du « Oui » en « Yes » pour le composant TbitBtn est un bogue de Lazarus puisque le composant TButton ne semble pas souffrir de la même tare. Cependant, avant de vous ruer sur la rubrique Bugtracker du site de Lazarus, il est de nouveau conseillé de lire la suite. Ce comportement apparemment aberrant s'explique si l'on comprend comment fonctionne le système de traduction.

[Exemple TR_02]

Une première manière de contourner le problème rencontré serait de modifier manuellement la valeur de la propriété en cause, ici Caption. En effet, si vous changez cette valeur depuis l'inspecteur d'objet, le comportement correspondra à celui qui était attendu :

• modifiez la valeur de la légende (Caption) en la passant de « &Oui » à « &Oui-oui » ;
• compilez le programme ;
• lancez son exécution.

Vous obtiendrez cet écran :

Tout semble être rentré dans l'ordre, mais que s'est-il passé ? Pour le comprendre, il faut examiner les fichiers LFM qui contiennent la description des fiches. Comme ce sont de simples fichiers textes, des outils tels que Notepad++ pour Windows ou gEdit pour Linux feront l'affaire.

Dans la première version du programme, on lit ceci :

On voit que le BitBtn affiche la légende par défaut : c'est ce qu'indique la ligne « DefaultCaption = True ».

L'affichage de la version modifiée donne ceci :

Cette fois-ci, la ligne relevée a disparu, mais une autre ligne a fait son apparition : « Caption = ‘&Oui-oui' ». C'est elle qui assure que le message sera bien traduit à l'exécution.

Mais revenons à notre question initiale : que s'est-il passé ? Afin d'éviter d'encombrer le fichier LFM de données inutiles, l'EDI n'enregistre que les valeurs des propriétés qui diffèrent de leur valeur par défaut.

En modifiant le libellé manuellement, vous avez forcé Lazarus à stocker la nouvelle valeur dans le fichier LFM qui accompagne la fiche en cause. De même, en inversant la valeur de la propriété DefaultCaption, vous avez forcé l'affichage de la propriété Caption telle qu'elle apparaît dans l'inspecteur d'objet et non telle qu'elle est enregistrée par défaut dans la LCL. Autrement dit, si vous souhaitez qu'une propriété ait une valeur différente de celle par défaut, assurez-vous que le fichier LFM l'ait correctement enregistrée.

En fait, avec le composant TBitBtn, vous auriez obtenu le même affichage en changeant la valeur de DefaultCaption de True à False. Cette seconde solution serait idéale si elle était indépendante du composant utilisé, mais cette propriété n'est présente que pour les descendants de TCustomBitBtn !

II-C-1. Mise en œuvre▲

Vous pourriez vous satisfaire des deux premières solutions pour les propriétés accessibles en écriture. Malheureusement, de nombreux messages ne sont pas de ce type : certaines propriétés (comme le nom des couleurs) et la plupart des messages d'erreur sont hors de portée des unités créées.

Lazarus vient alors à votre rescousse en intégrant un système de traduction complet et automatique.

[Exemple TR_03]

Pour illustrer la mise en œuvre de ce mécanisme, procédez comme suit :

• créez un nouveau projet ;
• dans « Projet » → « Options du projet » → « i18n », cochez « i18n » et « Créer/mettre à jour le fichier « .po » en enregistrant le fichier « .lfm » » ;

• modifiez la légende de la fiche (Caption) en la faisant passer de « Form1 » à « En français 3… » ;
• déposez un bouton avec glyphe (TBitBtn) sur la même fiche ;
• modifiez sa propriété de type (Kind) en la faisant passer de « bkCustom » à « bkYes » ;
• enregistrez ce projet dans le répertoire de votre choix sous le nom TestTranlate03.lpi ;
• ouvrez depuis le navigateur le répertoire utilisé ;
• créez un sous-répertoire que vous baptiserez languages (ce nom a son importance !) ;
• déplacez le fichier TestTranslate03.po apparu dans le dossier du projet dans le répertoire languages (si ce fichier est introuvable, déplacez légèrement la fiche principale et enregistrez de nouveau le projet) ;
• renommez le fichier TestTranslate03.po en TestTranslate03.fr.po ;
• copiez le fichier lclstrconsts.fr.po depuis son répertoire d'origine (sous-répertoire lcl/languages du répertoire d'installation de Lazarus) jusqu'au répertoire languages que vous venez de créer ;
• éditez le fichier du projet TestTranslate03.lpr grâce à l'inspecteur de projet (il apparaît lorsqu'on choisit « Projet » → « Inspecteur de projet » dans le menu principal de l'EDI) ;

• ajoutez l'unité DefaultTranslator à la clause uses du programme :

   

  Sélectionnez

  program project3;
  {$mode objfpc}{$H+}
  uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
   cthreads,
  {$ENDIF}{$ENDIF}
   Interfaces, // this includes the LCL widgetset
   Forms, main,
   { you can add units after this }
   DefaultTranslator; //  unité ajoutée

• Compilez et exécutez le programme.

Cette fois-ci, sans avoir rien modifié des propriétés à la conception, le programme traduit correctement la légende du bouton. Vous êtes toutefois en droit de vous dire que les moyens mis en œuvre sont disproportionnés par rapport aux résultats ! Pour vous rassurer, nous allons ci-après expliquer l'intérêt de l'ensemble puis son fonctionnement.

II-C-2. Pourquoi il faut éviter de bricoler la traduction▲

Vous avez à présent trois solutions à votre disposition :

• la modification manuelle de certains messages ;
• la modification de certaines propriétés elles-mêmes susceptibles de modifier l'affichage ;
• l'utilisation du système automatique intégré de Lazarus via l'unité DefaultTranslator.

Si les deux premières sont légères, la dernière est de loin celle recommandée, car elle fonctionne automatiquement pour tous les messages des unités du projet. Elle évite par conséquent de parcourir les unités et les fichiers LFM à la recherche de chaînes à traduire, avec le risque d'en oublier ! Enfin, elle est la seule à pouvoir traiter les messages inaccessibles depuis l'EDI.

[Exemple TR_04]

En guise de démonstration, voici un nouveau programme très simple :

• créez un nouveau projet ;
• dans « Projet » → « Options du projet » → « i18n », cochez « i18n » et « Créer/mettre à jour le fichier « .po » en enregistrant le fichier « .lfm » » ;
• modifiez la légende de la fiche (Caption) en la faisant passer de « Form1 » à « En français 4… » ;
• déposez un composant TColorListBox sur la fiche principale ;
• déposez un composant TButton sur la même fiche ;
• modifiez la légende du bouton (Caption) en la faisant passer de « Button1 » à « Joli ! » ;
• créez un événement OnClick pour le bouton et entrez le code suivant dans la partie implementation de la fiche :

 

Sélectionnez

resourcestring
// chaînes de ressources pour leur future traduction
 RS_Pretty = 'Joli !';
 RS_NotPretty = 'Pas joli !';

{$R *.lfm}

{ TForm1 }

procedure TForm1.Button1Click(Sender: TObject);
begin
  if cbPrettyNames in ColorListBox1.Style then
  begin
 // propriété exclue
    ColorListBox1.Style := ColorListBox1.Style - [cbPrettyNames];
    Button1.Caption := RS_Pretty;
  end
  else
  begin
 // propriété incluse
    ColorListBox1.Style := ColorListBox1.Style + [cbPrettyNames];
    Button1.Caption := RS_NotPretty;
  end;
end;

La procédure introduite permet de modifier l'affichage du bouton en fonction de la propriété Style de la TColorListBox. L'option qui alterne est cbPrettyNames : si elle est incluse dans le style, le composant fait appel à la LCL pour afficher le nom en clair des couleurs et non leur codage interne.

À cette étape, en lançant l'exécution du programme puis en cliquant sur le bouton, vous obtiendrez des noms en anglais :

En ajoutant la même unité DefaultTranslator à la clause uses du programme principal et les fichiers PO dans un sous-répertoire languages du répertoire de l'application, les noms de couleurs seront traduits :

N'oubliez pas de renommer TestTranslate04.po en TestTranslate04.fr.po et de copier le fichier lclstrconsts.fr.po dans ce répertoire si vous voulez que la LCL soit traduite !

En revanche, le codage des couleurs n'est pas affecté par la traduction : par exemple, clBlue affiche « Blue » en anglais et « Bleu » en français. Si vous cliquez de nouveau sur le bouton, les codes seront affichés tout simplement. Ce fonctionnement est bien celui désiré : pour l'utilisateur final, seul le nom des couleurs importe ; pour le programmeur, c'est celui des codes associés à ces couleurs.

Ce qu'il faut retenir de cet exemple très simple, c'est que des propriétés inaccessibles directement depuis l'EDI, comme ici le nom des couleurs, peuvent être traduites grâce à un mécanisme automatique.

[Exemple TR_05]

Par la même occasion, les messages d'exception le sont aussi. Pour vous en assurer, dans le même projet, complétez le code de la procédure Button1Click ainsi :

 

Sélectionnez

procedure TForm1.Button1Click(Sender: TObject);
var
  I, J: Integer;
begin
  I := 2;
  J := I - I;
  Button1.Caption:= IntToStr(I div J); // oups…
  // le reste ne change pas…
  if cbPrettyNames in ColorListBox1.Style then
{…}

Lors du clic sur le bouton, une exception va être levée, car vous tenterez de diviser un nombre par 0. Avec l'unité DefaultTranslator, le message sera affiché en français. Si vous retirez l'unité de la clause uses du programme principal, le message sera en anglais. La solution adoptée pour la traduction est par conséquent très puissante : tout ce qui est du ressort de la LCL est traduit !

II-C-3. Fonctionnement▲

SetDefaultLang('', '', false)

[Exemple TR_06]

Il ressort de cette analyse qu'il existe une quatrième façon de traiter notre problème : en forçant la traduction de la LCL grâce à une portion de code, nous n'aurons plus besoin de créer un fichier PO supplémentaire.

En revanche, le code en sera un peu alourdi : il faudra modifier le corps du programme en contraignant ce dernier à une traduction explicite à partir du fichier lclstrconsts.fr.po, le tout en exploitant deux nouvelles unités (gettext et translations).

program TestTranslate06;

{$mode objfpc}{$H+}

uses
 {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
 {$ENDIF}{$ENDIF}
  Interfaces, // this includes the LCL widgetset
  Forms, main,
 { you can add units after this }
  sysutils, // une unité ajoutée pour PathDelim
  gettext, translations; // deux unités ajoutées

{$R *.res}

procedure LCLTranslate;
var
  PODirectory, Lang, FallbackLang: String;
begin
  Lang := ''; // langue d'origine
  FallbackLang := ''; // langue d'origine étendue
  PODirectory := '.' + PathDelim + 'languages' + PathDelim; // répertoire de travail
  GetLanguageIDs(Lang, FallbackLang); // récupération des descriptifs de la langue 
  TranslateUnitResourceStrings('LCLStrConsts',
  PODirectory + 'lclstrconsts.fr.po', Lang, FallbackLang); // traduction
end;

begin
  RequireDerivedFormResource := True;
  LCLTranslate; // on ordonne la traduction
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

Avec cette méthode, il est inutile d'activer l'option « i18n ». Le répertoire du fichier PO est fourni par la procédure LCLTranslate à partir de la variable PODirectory. Cependant, seule la LCL est traduite par ce biais : la traduction d'autres unités exige de compléter le code ou de revenir à la traduction via « i18n » qui est au bout du compte bien plus simple à mettre en œuvre.

[Exemple TR_07]

L'étape suivante va un peu compliquer le programme à traduire. Vous allez en effet construire un projet plus ambitieux avec deux fiches et plusieurs textes.

• créez un nouveau projet ;
• dans « Projet » → « Options du projet » → « i18n », « cochez i18n et Créer/mettre à jour le fichier « .po » en enregistrant le fichier « .lfm » » ;
• modifiez la légende de la fiche (Caption) en la faisant passer de « Form1 » à « In English 7… » ;
• ajoutez un bouton TButton à la fiche ;
• passez sa propriété AutoSize de False à True afin que la taille du bouton s'adapte automatiquement à celle de sa légende ;
• créez un gestionnaire d'événement OnClick pour ce bouton ;
• tapez le code suivant pour ce gestionnaire :

implementation

{$R *.lfm}

{ TForm1 }

resourcestring
  RS_Hello = 'Hello world!';
  RS_Bye = 'Goodbye cruel world!';

procedure TForm1.Button1Click(Sender: TObject);
// *** inversion de la légende du bouton 1 ***
begin
 if Button1.Caption = RS_Hello then
  Button1.Caption := RS_Bye
 else
  Button1.Caption := RS_Hello;
end;

• Créez aussi un gestionnaire d'événement OnCreate pour la fiche afin qu'une légende s'affiche correctement dès le lancement de l'application :

procedure TForm1.FormCreate(Sender: TObject);
// *** création de l'application ***
begin
  Button1.Caption := RS_Hello;
end;

• Ajoutez un second bouton TButton à cette fiche ;

• modifiez sa légende (Caption) de « Button2 » à « New… » ;
• créez un gestionnaire d'événement OnClick pour ce bouton, mais laissez-le vide pour le moment ;
• cliquez sur « Nouvelle fiche » du menu « Fichier » ;
• modifiez la légende (Caption) de cette nouvelle fiche de « Form2 » à « New form » ;
• ajoutez un composant TBitBtn à cette fiche ;
• modifiez sa propriété Kind de « bkCustom » à « bkClose » ;
• ajoutez du texte à la propriété Hint de ce bouton : « Close the form » ;
• passez sa propriété ShowHint de False à True afin de permettre l'affichage à l'exécution d'une bulle d'aide associée à ce bouton ;
• dans « Projet » → « Options du projet » →  « Fiches », passez la fiche « Form2 » de la colonne « créer les fiches automatiquement » à la colonne « fiches disponibles » avant de valider ce choix en cliquant sur « OK » ;

• dans la partie implementation de la première fiche Form1, ajoutez une clause uses afin que la seconde fiche soit connue de la première :

   

  Sélectionnez

  uses
    unit2;

• Retournez au gestionnaire OnClick du second bouton de la première fiche (Form1) et entrez le code suivant :

   

  Sélectionnez

  procedure TForm1.Button2Click(Sender: TObject);
  // *** ouverture d'une nouvelle fiche ***
  var
    MyForm: TForm2;
  begin
    MyForm := TForm2.Create(Self); // on crée la fiche
    try
      MyForm.ShowModal; // on la montre (seule active)
    finally
      MyForm.Close; // on libère la fiche
    end;
  end;

• Enregistrez le projet sous le nom TestTranslate07.lpi ;

• compilez et lancez l'application.

Vous disposez à présent d'une application un peu plus complexe que les précédentes, avec deux fiches dont une qui permet de faire surgir la seconde sous forme modale.

En dehors de sa relative complexité, cette application présente aussi la particularité d'être en anglais. L'objectif va évidemment consister à la traduire le plus simplement possible en français.

Une première méthode consisterait à reprendre toutes les chaînes entrées et de les traduire. Si vous la choisissez, c'est que vous n'avez pas lu ce qui précédait !

La méthode la plus efficace va passer par la création d'un dossier languages dans lequel vous allez copier l'habituel fichier lclstrconsts.fr.po pour la traduction de la LCL, mais aussi le fraîchement créé project5.po.

Comme vous avez activé l'option « i18n » et l'enregistrement avec les fichiers LFM, Lazarus a créé automatiquement autant de fichiers LRT que d'unités et un unique fichier PO qui regroupe l'ensemble des chaînes à traduire.

En utilisant votre éditeur préféré, vous vous apercevrez que le fichier unit1.lrt, contient des paires de valeurs :

TFORM1.CAPTION=In English 7...
TFORM1.BUTTON1.CAPTION=Button1
TFORM1.BUTTON2.CAPTION=New...

Le fichier unit2.lrt est construit selon le même modèle :

TFORM2.CAPTION=New form
TFORM2.BITBTN1.HINT=Close the form

De son côté, le contenu de TestTranslate05.po, un peu plus complexe, reprend les mêmes informations réparties sur trois lignes, accompagnées d'un en-tête et des chaînes de ressources incluses dans le code source :

msgid ""
msgstr "Content-Type: text/plain; charset=UTF-8"

#: tform1.button1.caption
msgid "Button1"
msgstr ""

#: tform1.button2.caption
msgid "New..."
msgstr ""

#: tform1.caption
msgid "In English 7..."
msgstr ""

#: tform2.bitbtn1.hint
msgid "Close the form"
msgstr ""

#: tform2.caption
msgid "New form"
msgstr ""

#: unit1.rs_bye
msgid "Goodbye cruel world !"
msgstr ""

#: unit1.rs_hello
msgid "Hello world !"
msgstr ""

L'en-tête précise que le type de caractères utilisé est « UTF-8 » pour la prise en compte des jeux de caractères différents suivant les langues. Cet en-tête contiendra plus tard un identificateur de la langue de traduction. Quant aux triplets de valeurs, ils comportent tous une troisième ligne réduite au code « msgstr » (pour message string) suivi d'une chaîne vide "". C'est cette chaîne vide qui contiendra la traduction désirée. Enfin, la première ligne de ces triplets correspond à un repère dans le code source ou dans le fichier LFM.

Même si la traduction peut se faire manuellement, l'utilisation d'outils spécialisés dans le traitement des fichiers PO est vivement recommandée : non seulement ils évitent bien des erreurs, mais ils fournissent aussi des outils d'édition et souvent des propositions de traduction qui s'appuient sur vos traductions et celles présentes sur Internet.

Pour Windows et Linux, un éditeur comme poEdit (gratuit dans sa version standard) est bien adapté. Il en existe d'autres parmi lesquels vous trouverez certainement celui qui vous convient le mieux.

Avant de traduire, le fichier souche doit être préservé : faites-en une copie dans le répertoire languages et rebaptisez-le TestTranslate.fr.po. L'infixe « fr » est celui qui indique qu'il s'agit de la traduction française : sans lui, il faudra préciser la langue de traduction.

poEdit reconnaît immédiatement cet infixe et présente le fichier sous cette forme :

Proposez alors les traductions suivantes :

Après avoir enregistré votre travail de traduction, vous pouvez éditer le fichier modifié :

msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Project-Id-Version: \n"
"POT-Creation-Date: \n"
"PO-Revision-Date: \n"
"Last-Translator: \n"
"Language-Team: \n"
"MIME-Version: 1.0\n"
"Content-Transfer-Encoding: 8bit\n"
"Language: fr\n"
"X-Generator: Poedit 1.7.5\n"
 
#: tform1.button1.caption
msgid "Button1"
msgstr "Bouton1"
 
#: tform1.button2.caption
msgid "New..."
msgstr "Nouveau..."

#: tform1.caption
msgid "In English 7..."
msgstr "En français..."
 
#: tform2.bitbtn1.hint
msgid "Close the form"
msgstr "Fermer la fiche"
 
#: tform2.caption
msgid "New form"
msgstr "Nouvelle fiche"
 
#: unit1.rs_bye
msgid "Goodbye cruel world !"
msgstr "Adieu, monde cruel !"
 
#: unit1.rs_hello
msgid "Hello world !"
msgstr "Bonjour le monde !"

En dehors de l'en-tête qui a pris de l'ampleur afin de préciser si nécessaire la langue de traduction, l'identité du traducteur et/ou de son équipe, les dates de création et de modification et l'outil de traduction utilisé, vous remarquerez surtout que les troisièmes lignes déjà mentionnées de chaque triplet contiennent à présent la traduction proposée pour la chaîne originale correspondante.

L'unité DefaultTranslator dispose de tout ce qui lui est nécessaire pour travailler :

• un répertoire languages pour y chercher les fichiers de traduction ;
• des fichiers PO qui contiennent les repères des chaînes à modifier ainsi que les couples de chaînes langue d'origine/langue de traduction.

En ajoutant tout simplement le nom de cette unité dans la clause uses du programme principal, vous obtenez… un programme en français !

program TestTranslate07;

{$mode objfpc}{$H+}

uses
 {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
 {$ENDIF}{$ENDIF}
  Interfaces, // this includes the LCL widgetset
  Forms, Unit1, Unit2,
  DefaultTranslator; // en français !
 
{$R *.res}

begin
  RequireDerivedFormResource := True;
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

Pour simplifier, certains aspects du problème seront traités sous leur forme la plus naïve : le programme saura d'emblée quels fichiers de traduction seront présents dans un répertoire donné et l'utilisateur en choisira un grâce à un contrôle de type TListBox.

[Exemple TR_08]

Sans surprise, l'unité principale du programme ressemblera à ceci :

unit main;

interface

uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls,
  ExtCtrls,
  GVTranslate; // unité de la gestion des traductions

type

  { TMainForm }

  TMainForm = class(TForm)
    btnRestart: TButton;
    lblLanguage: TLabel;
    lblDirectory: TLabel;
    lblFile: TLabel;
    lblAccess: TLabel;
    lbLanguages: TListBox;
    pnlData: TPanel;
    procedure btnRestartClick(Sender: TObject);
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
    procedure lbLanguagesClick(Sender: TObject);
  private
    Process: TGVTranslate; // traducteur
  end;

var
  MainForm: TMainForm;

implementation

{$R *.lfm}

resourcestring
  R_Language = 'Language: ';
  R_Directory = 'Directory: ';
  R_File = 'File: ';
  R_Access = 'Access: ';

{ TMainForm }

procedure TMainForm.btnRestartClick(Sender: TObject);
// *** bouton pour redémarrer le programme ***
begin
  // choix enregistré
  Process.Language := lbLanguages.Items[lbLanguages.ItemIndex];
  // on redémarre
  Process.Restart;
end;

procedure TMainForm.FormCreate(Sender: TObject);
// *** création de la fiche ***
begin
  Process := TGVTranslate.Create; // nouveau traducteur créé
  // mise à jour des légendes des étiquettes
  lblLanguage.Caption := R_Language + Process.Language;
  lblDirectory.Caption := R_Directory + Process.FileDir;
  lblFile.Caption := R_File + Process.FileName;
  lblAccess.Caption := R_Access + Process.LanguageFile;
end;

procedure TMainForm.FormDestroy(Sender: TObject);
// *** destruction de la fiche ***
begin
  Process.Free; // traducteur libéré
end;

procedure TMainForm.lbLanguagesClick(Sender: TObject);
// *** clic sur la liste de choix ***
begin
  // on active le bouton si un choix a été fait
  btnRestart.Enabled := (lbLanguages.ItemIndex <> - 1);
end;

end.

Vous aurez compris que la partie la plus intéressante est comprise dans une nouvelle unité : GVTranslate. C'est elle qui a en charge l'accès aux fichiers de langue, mais aussi le redémarrage de l'application après l'enregistrement des changements.

Une première difficulté réside dans le fait qu'une application en cours d'exécution ne peut pas se modifier elle-même : il faut lancer un nouveau processus depuis celui en cours d'exécution avant de mettre fin à ce dernier. Deux autres difficultés tiennent à ce que les fichiers de traduction sont à identifier par leur extension et qu'ils ne sont pas forcément dans le répertoire de l'application.

La classe TGVTranslate a pour mission de résoudre ces problèmes :

{ TGVTranslate }

  TGVTranslate = class
  strict private
    fFileName: string;
    fFileDir: string;
    fLanguage: string;
    function GetLanguageFile: string;
    procedure SetFileName(const AValue: string);
    procedure SetFileDir(const AValue: string);
    procedure SetLanguage(const AValue: string);
    procedure Translate;
  public
    constructor Create;
    procedure Restart;
    property Language: string read fLanguage write SetLanguage;
    property FileName: string read fFileName write SetFileName;
    property FileDir: string read fFileDir write SetFileDir;
    property LanguageFile: string read GetLanguageFile;
  end;

Si l'essentiel des fonctionnalités de cette classe renvoie au problème d'identification des fichiers, la méthode Restart s'occupe de faire redémarrer l'application. Pour cela, elle fait appel à une unité fournie par Lazarus : UTF8Process.

Voici le listing commenté de cette méthode :

procedure TGVTranslate.Restart;
// *** redémarrage de l'application ***
var
  Exe: TProcessUTF8;
begin
  Exe := TProcessUTF8.Create(nil); // processus créé
  try
    Exe.Executable := Application.ExeName; // il porte le nom de l'application
    // ajout des paramètres
    Exe.Parameters.Add(Language); // langue en paramètre
    Exe.Parameters.Add(FileDir);  // répertoire
    Exe.Parameters.Add(FileName); // nom de fichier
    Exe.Execute; // on démarre la nouvelle application
  finally
    Exe.Free; // processus libéré
    Application.Terminate; // l'application en cours est terminée
  end;
end;

L'application est par conséquent relancée avec trois paramètres sur la ligne de commande : la langue désirée, le chemin à suivre relatif au répertoire de l'application et le nom du fichier sans son extension.

Les méthodes en charge des propriétés sont assez simples si ce n'est qu'elles prévoient de leur donner des valeurs par défaut si elles étaient indéterminées :

const
  C_DefaultDir = 'languages';
  C_PoExtension = 'po';
  C_DefaultLanguage = 'en';

resourcestring
  RS_FallBackLanguage = 'auto';

{ TGVTranslate }

procedure TGVTranslate.SetLanguage(const AValue: string);
// *** détermine la langue pour la traduction ***
var
  LDummyLang: string;
begin
  if AValue = RS_FallBackLanguage then // langue de la machine ?
  begin
    LDummyLang := '';
    GetLanguageIDs(LDummyLang,fLanguage); // on retrouve son identifiant
  end
  else
    fLanguage := AValue; // nouvelle valeur
end;

constructor TGVTranslate.Create;
// *** création ***
begin
  inherited Create;
  if Application.ParamCount > 0 then // au moins un paramètre ?
    Language := Application.Params[1] // c'est l'identifiant de la langue
  else
    Language := C_DefaultLanguage; // langue par défaut
  if Application.ParamCount > 1 then // au moins deux paramètres ?
    FileDir := Application.Params[2] // c'est le répertoire des fichiers
  else
    FileDir := ''; // répertoire par défaut
  if Application.ParamCount > 2 then // au moins trois paramètres ?
    FileName := Application.Params[3] // c'est le nom du fichier
  else
    FileName := ''; // fichier par défaut
  Translate;
end;

procedure TGVTranslate.SetFileName(const AValue: string);
// *** détermine le nom du fichier ***
begin
  if AValue <> '' then // pas valeur par défaut ?
    // à partir de l'extraction du nom du fichier
    fFileName := ExtractFileName(AValue)
  else
    // à partir du nom du programme
    fFileName := ExtractFileNameOnly(Application.ExeName);
end;

function TGVTranslate.GetLanguageFile: string;
// *** construit et renvoie le chemin complet du fichier de traduction ***
begin
  Result := '.' + PathDelim + FileDir + PathDelim + FileName + '.' +
    Language + '.' + C_POExtension;
end;

procedure TGVTranslate.SetFileDir(const AValue: string);
// *** détermine le répertoire où sont les fichiers de traduction ***
begin
  fFileDir := AValue; // valeur affectée
  if fFileDir <> '' then // pas la valeur par défaut ?
    fFileDir := ExtractFilePath(fFileDir); // on récupère le chemin
  if fFileDir = '' then // chemin vide ?
    fFileDir := C_DefaultDir; // répertoire par défaut
end;

Enfin, une ultime méthode procède à la traduction elle-même :

procedure TGVTranslate.Translate;
// *** traduction ***
var
  LF: string;
begin
  if Language = C_DefaultLanguage then // l'anglais n'a pas besoin d'être traité
    Exit;
  LF := LanguageFile; // fichier de traduction
  if FileExistsUTF8(LF) then // existe-t-il ?
    SetDefaultLang(Language, FileDir) // on traduit
  else
    Language := C_DefaultLanguage; // langue par défaut si erreur
  // accès au fichier de traduction de la LCL
  LF := '.' + PathDelim + FileDir + PathDelim + 'lclstrconsts' + '.' +
    Language + '.' + C_PoExtension;
  if FileExistsUTF8(LF) then // existe-t-il ?
    Translations.TranslateUnitResourceStrings('LCLStrConsts', LF); // on traduit
end;