Hi all,

I'm using the DefaultTranslator unit to translate my application, but I would also like to switch to another language on-the-fly, thus without restarting the application.

Are there any tricks to do that?

I need that too atm :)

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120713/463766cd/attachment.html>

Try this one :

http://corpsman.de/index.php?doc=komponenten/multilanguage

Corpsman wrote

Try this one : http://corpsman.de/index.php?doc=komponenten/multilanguage

Does it uses the .po and .mo files generated by Lazarus?

Joost.

in short, no.

in a bit longer :

if you set within the application :  Language.CurrentLanguage := 'what
ever language you want';

The component tries to load that language file, if it exits your application is switched to the language, if not all translatable strings (captions, hints, .. and Ressourcestrings) will be extracted and stored to 'what ever language you want' file. With the Demo program you can edit this files ( or with any other text editor ) and translate them. On the next language changing the values will be loaded. In the demo this will be shown ( it uses nativ Lazarus methods, so it should be portable, it is successfully testet on Win32 and Linux32 ).

corpsman

13.07.2012 17:49, Joost van der Sluis ?????:

DefaultTranslator unit is quite simplistic and more meant to be an example.

In order to translate your application dynamically you should manually load .po files at runtime using functions (e. g.
TranslateUnitResourceStrings) from Translations unit. See its header for examples. Also there is a number of program sources to look at bundled with Lazarus, e. g. lazarus\tools\lazdatadesktop (see TranslateStrs procedure at the end of frmmain.pp).

Maxim Ganetsky wrote

In order to translate your application dynamically you should manually load .po files at runtime using functions (e. g. TranslateUnitResourceStrings) from Translations unit. See its header for examples.

And you'll have to update all captions of all controls on the current form (at least) in order to see the effect.

The IDE seems to do this, but I was unabble to track how. Manually updating all captions seems a horrible task to maintain.

Bart

The IDE forms set all captions when creating. See the FormCreate events. The maintenance work is near zero.
Theoretically the code could be put into methods and triggered when the language changes.

Mattias

15.07.2012 13:53, Bart ?????:

?

IDE can update .po files automagically. See Project Options -> i18n.

Bart's remark was about the IDE updating it's own forms when the user changes the language of the IDE.

Regards,
Sven

15.07.2012 15:35, Sven Barth ?????:

Then see Mattias' remark.

Mattias Gaertner wrote

The IDE forms set all captions when creating. See the FormCreate events. The maintenance work is near zero. Theoretically the code could be put into methods and triggered when the language changes.

This works well if you create all forms on the fly I guess. However the current active form (and all other forms still showing) will have to be updated I guess?

Say I have a mainform with a label with caption := SomeResourceString. Now i translate the resourcestring using Translations unit. This still leaves my label with the untranslated caption. So I have to do MyLabel.Caption := SomeResourceString again after the translation.

Bart

Yes.

Mattias

In the ideal world I would set in OI that Caption uses a resourcestring, and the component has some method to re-read it's content, so one could do stuff like:

for i := 0 to Form1.ComponentCount - 1 do
begin
  C := Form1.Compnents[i];
  if C.UsesResourceStringForCaption then C.UpdateResourceString;
end;

This would make maintanance (large menu's, active devolopment of forms in question) lots easier.

Bart

Hi,

Bart wrote

This would make maintanance (large menu's, active devolopment of forms in question) lots easier.

What I did is to encapsulate setting up captions to a single method, SetupCaptions, on each form. I use form inheritance, so each form simply needs to override that method. That method is called in FormCreate to setup all components. If the application language changes at runtime, I ask fpgApplication so broadcast a message to all loaded forms of the application. Those forms receive the message, and execute the SetupCaptions method again. Works like a charm.

Try the attached patch for DefaultTranslator. With SetDefaultLang('nl') it will switch the language on-the-fly (to Dutch in this case).

It will loop through all forms in screens and will change all properties that are present in the .po-file.

Maybe it is an idea to apply this patch so that others can also use this? Or should users write their own 'DefaultTranslator' unit? (Then this one could be added to the Wiki as an example)

Yes.
Why is FStackPath a private variable instead of a parameter?

Mattias

Yes. This catches all special cases like memos, tree nodes, list views and private variables as well.

Mattias

Mattias Gaertner wrote

Yes. This catches all special cases like memos, tree nodes, list views and private variables as well.

Correct, and I also couldn't rely on something like RTTI to iterate or query widgets on a form, because my widgets are declared private only (not published).

And yet another alternative, one could use Interfaces too. The Form implements a "translation interface", and the broadcast mechanism could simply query each loaded form for the specific interface, and if found, call the UpdateCaptions method of that interface. This way you don't need form inheritance, but the end result is similar in each case.

As always in programming, there are a 101 ways to accomplish the same task. :)

Because GetIdentifierPath (which needs FStackPath) is called from within TranslateStringProperty, from which the parameters are defined in the classes-unit?

16.07.2012 15:58, Joost van der Sluis ?????:

Applied, thanks.

The only requirement for DefaultTranslator unit IMO is that it should just work when included to program without explicit calling any procedures.