Discussion :

[ChPr]

Bonjour à toutes et à tous,

Comme le dit le titre, mes boîtes de message (MessageDlg) sous en anglais sous Windows alors qu'elles sont en français sous Ubuntu ???

Un idée du problème ?

Merci de votre aide.

Pierre.

[DOLPat®]

Bonjour

Je vais encore être un annonciateur de mauvaise nouvelle.
Je viens d'essayer sous la version 0.9.31 et effectivement le texte des boutons est dans la langue de Shakespeare. Donc, c'est un bug. Je ne t'explique plus la procédure à suivre si tu veux que cela soit corrigé. Bug tracker etc etc etc. Tu commences à être routinier du fait. Apparemment, tu est en train de piocher tous les bogues de Lazarus.

[ChPr]

Merci DOLPat, je vais encore aller dans le BugTracker.

Le problème c'est que j'en ai encore d'autres sous le pied .

Cordialement.

Pierre

[DOLPat®]

Le problème c'est que j'en ai encore d'autres sous le pied .

Ben c'est bien ce que je disais tout à l'heure:

... Apparemment, tu est en train de piocher tous les bogues de Lazarus.

Je sais que c'est galère, mais dis-toi que c'est pour la bonne cause. Le chemin est encore grand pour rendre Lazarus exempt de tout bug, hélas. Mais si chacun met une pierre à l'édifice, on arrivera bien à le terminer un jour.

[Conseil] Allumer un cierge afin d'arrêter la série.

[DOLPat®]

Bonjour

J'ai trouvé ceci qui devrait t'être utile.

[ChPr]

Merci DolPat pour ce lien, je vais regarder ça.

Cordialement.

Pierre

[CapJack]

J'avais étudié le code source de la VCL à l'époque où je voulais me faire une unité dialog box personnalisée, et je m'étais aperçu que pour les boutons standards, Delphi utilisait la langue du système en cours.

Donc, imaginons une application traduite en français, en anglais et en serbo-croate occidental, si un utilisateur allemand utilise l'application Delphi, il aura toute la boîte de dialogue en anglais par exemple, sauf deux boutons qui diront "Ja" et "Nein". C'est moche.

Donc, en ce qui me concerne, j'ai toujours trouvé que c'était une mauvaise idée d'utiliser les boîtes de dialogue par défaut, et pour une application destinée à être distribuée, j'essaie de créer une fiche personnalisée que je localise par mes propres moyens (enfin, pas toujours).

Maintenant, d'après ce que je comprends, Lazarus utilise son propre système ? Serait-il donc possible d'avoir des boutons système dans une langue au choix du développeur ? Ce serait intéressant...

[Conseil] Allumer un cierge afin d'arrêter la série.

Je préfère les bougies parfumées.

[alanglet]

Bonjour,

Dans les commentaires en tête de l'unité Translations on trouve tout ce qu'il faut pour utiliser les fichiers de traduction .po
Pour une application uniquement en français, et pour éviter d'avoir à joindre le fichier de traduction de la LCL lclstrconsts.fr.po, je le transforme en fichier ressources que je charge au démarrage de l'application. Pour cela j'ai fait la petite unité u_Traduction suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
unit u_Traduction;
 
{$mode objfpc}{$H+}
 
interface
 
function TraduitUnitDepuisLrs(NomUnit,Langue:string):boolean;
 
implementation
uses
  Classes,LResources,Translations;
 
function TraduitUnitDepuisLrs(NomUnit,Langue:string):boolean;
(*Intégration du fichier de traduction dans le fichier ressources par la commande
"c:\lazarus\tools\lazres.exe traductfr.lrs c:\lazarus\lcl\languages\lclstrconsts.fr.po"
c:\lazarus\tools\lazres.exe doit avoir été construit depuis le projet lazres.lpi,
traductfr.lrs nom du fichier ressources à inclure dans la partie "initialization {$I traductfr.lrs}",
c:\lazarus\lcl\languages\lclstrconsts.fr.po fichier po de traduction.
Les unités LResources et Translations doivent être dans Uses
Autres infos, voir l'unité Translations.
*)
var
  pofile:TPOFile;
  LeStream:TMemoryStream;
  NomFichier,ChaineRes:string;
begin
  Result:=false;
  if (NomUnit='')or(Langue='') then
    exit;
  NomFichier:=NomUnit+'.'+Langue;
  ChaineRes:=lazarusresources.Find(NomFichier,'PO').Value;
  LeStream:=TMemoryStream.Create;
  try
    LeStream.WriteAnsiString(ChaineRes);
    LeStream.Position:=0;
    pofile:=TPOFile.Create(LeStream);
    try
      Result:=TranslateUnitResourceStrings(NomUnit,pofile);
    finally
      pofile.free;
    end;
  finally
    LeStream.Free;
  end;
end;
 
initialization
{$I traductfr.lrs}
 
end.

Cette unité figure dans les Uses du .lpr et TraduitUnitDepuisLrs('lclstrconsts','fr'); est exécuté juste après l'initialisation de l'application.
Pour éviter de joindre les fichiers .po séparés, il doit être possible d'étendre la méthode en incluant uniquement les fichiers utiles dans le .lrs et avec la méthode expliquée dans Translations pour identifier la langue, charger la traduction correspondante.

André

[ChPr]

Je vous remercie pour les solutions que vous me proposez. Je pense que je serai obligé d'en passer par là.

Voir les réponses qui m'ont été faites sur le bug Tracker.

Néanmoins, je persiste à dire que ce n'est pas normal, la traduction devrait se faire automatiquement (comme cela est fait dans l'environnement Linux).

Cordialement.

Pierre

[alanglet]

re..,

Bizarre, le lien que vous donnez ci-dessus conduit à http://wiki.lazarus.freepascal.org/T...art_of_program et juste en dessous se trouve dans "Compiling po files into the executable" une méthode semblable à l'unité de mon message précédent.
Trouvant "plus malin" leur méthode de chargement du POFile sans passer par le TMemoryStream, j'ai voulu faire pareil, mais j'obtiens systématiquement une erreur lors de l'exécution de TranslateUnitResourceStrings.
Pas vous?

André

[ChPr]

Ayant d'autres problèmes de traitement d'images, j'avoue ne pas avoir eu le temps d'essayer ces méthodes. J'espère m'y remettre bientôt.

Cordialement.

Pierre

[Invité]

Bonjour Pierre,

Je suis peut-être complètement à côté de la plaque : j'ai peut-être mal compris le problème... et c'est peut-être une redite des divers liens précisés ci-dessus que j'avoue n'avoir pas lus. Par contre, je constate en effet sur un projet vierge que le Caption des boutons est en anglais sous Win. Je me rappelle avoir eu sur ce forum une discussion assez animée sur la question de l'utilisation de i18n.

Depuis la 0.9.28, systématiquement, sous Win comme sous Nux, j'utilise les fichiers lclstrconsts.po, lclstrconsts.en.po et lclstrconsts.fr.po en activant le i18n du projet.

Je viens de vérifier sur un petit projet. Sous Win comme sous Nux, mes boîtes de dialogue (ie les boutons) "fonctionnent". Et cela ne nécessite pas beaucoup d'investissement... et donc ne ralentira pas beaucoup votre projet.

1. Vous récupérez les fichiers nécessaires lclstrconsts.po, lclstrconsts.fr.po (et éventuellement lclstrconsts.en.po). Dans mon cas, ils sont dans ..\lazarus\0.9.31-31628-fpc-2.4.4-20110710\lcl\languages\ lclstrconsts.xx.po. Vous les placez dans un rép. de votre projet (par exemple \langs).

2. Vous activez l'i18n dans les options de votre projet (et sélectionnez à cette occasion le répertoire \langs que vous venez de créer dans votre projet).

3. Dans le onCreate de votre Form, le code se réduit à ce qui suit. Tel quel, il devrait suffire à régler votre problème.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
//uses Translations, gettext, StrUtils;     
 
var
   gsFallbackLang, gsLang : string;
   gsPODirectory : string;  // Rép. des "translation files"  
 
begin
//Gestion des langues
  gsPODirectory := IncludeTrailingPathDelimiter(
                      IncludeTrailingPathDelimiter(
                       ExtractFilePath(Application.ExeName))+'langs');
 GetLanguageIDs(gsLang ,gsFallbackLang);
// Choix de la langue par défaut si pas dans celles utilisées par le logiciel
 if (gsFallbackLang <> 'fr') then begin   // and (gsFallbackLang <> 'us') and ...  
    gsFallbackLang := 'fr';
    gsLang         := 'fr_FR';
 end;
 //Traduction des messages (tous) contenus dans l'unité uglobales [Inutile dans votre cas]
 // Translations.TranslateUnitResourceStrings('uglobales', gsPODirectory +
 //    ExtractFileNameOnly(Application.ExeName)+'.%s.po', gsLang, gsFallbackLang);
 //Traduction des caption des buttons des MessageDialogs & co
  Translations.TranslateUnitResourceStrings('LCLStrConsts', gsPODirectory +
                  'lclstrconsts.'+gsFallbackLang+'.po', gsLang, gsFallbackLang);  
end;

Je ne sais pas si automatiquement avec l'activation du i18n dans le projet (ie sans le code ci-dessus) Lazarus fait le travail... mais j'en doute même si le répertoire des traductions associé au projet est déclaré au moment de la validation de l'i18n dans les options du projet. J'utilise un code de ce type un peu amélioré pour changer de langue à tout moment dans mes applications.

Avant

Après

RQ : je n'ai pas pris le tps de traduire le texte du message . Il serait déclaré comme resourcestring (ex. rsMessSupportTech = 'Please, contact technical support'; ), dans mon cas, dans l'unité uGlobales. Il est par défaut en anglais car les default.po à partir desquels sont générés les default.fr.po, sont eux-mêmes en anglais. Lazarus génère alors la structure des fichiers de traduction dans /langs : project1.po, project1.fr.po et project1.en.po
Un tel fichier (project1.fr.po) ressemble alors à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
#: uglobales.rsmesserror
msgid "Error"
msgstr "Erreur"
 
#: uglobales.rsmesssupporttech
msgid "Please, contact technical support"
msgstr "Veuillez contacter le support technique" --> Là, vous placez votre traduction

Code testé ce jour sous Lazarus 0.9.31-31628-fpc-2.4.4-20110710 - Windows 7 [32]

En conclusion, la gestion de i18n est extrêmement efficace avec Lazarus (encore un excellent point) et totalement contrôlable. On l'implante une fois sur un projet, et on le duplique... Evidemment, c'est plus compliqué au départ que le "paramétrage automatique"... mais après, d'une part, en contre-partie on échappe à ce type de bug, et d'autre part on dispose d'une réelle facilité pour réaliser des applications multi-OS et multilingues.

Bonne fin de WE.
Cordialement. Gilles