Forum > Translations

[SOLVED] LCLTranslator: update of current form possible?

<< < (3/3)

wp:
I wrote the translation example in response to some forum discussions some years ago (cannot find them ATM) in order to show to basic steps required for translating an application. The code, in no way, was meant to be general enough to be included in the IDE's template list.

The problem is that LCLTranslator itself, written by Maxim Ganetsky, is only a simplification. Why does it translate only Captions, not items in TStrings descendants such as TCombobox.Items, TRadiogroup.Item? Because, quite often, there may be cases when the items should not be translated; suppose a list of file names or printer names in the combobox where translation certainly will not be appropriate. 

The essential idea behind TLocalizedForms is to equip translateable forms with a way to translate all the controls not covered by LCLTranslator.

And a good translation should also cover the issue with the format settings (month and day names, currency symbols, separators etc). This is not even handled by FPC in a cross-platform way. Localization of format settings is handled in the example code by an ugly windows-only IFDEF which, in my opinion, is not acceptable as a feature tied closely to the IDE.

So, after all, my hope was, that a user who wants to translate an application studies the code (along with the tutorial, https://wiki.lazarus.freepascal.org/Step-by-step_instructions_for_creating_multi-language_applications) and understands the concept of the po files. And when he does understand it he will be able to adapt it to his own requirements by a few lines of code, or by copy&pasting from the examples project.

howardpc:

--- Quote from: wp on April 10, 2022, 11:29:22 am ---So, after all, my hope was, that a user who wants to translate an application studies the code (along with the tutorial, https://wiki.lazarus.freepascal.org/Step-by-step_instructions_for_creating_multi-language_applications) and understands the concept of the po files. And when he does understand it he will be able to adapt it to his own requirements by a few lines of code, or by copy&pasting from the examples project.

--- End quote ---
Well, at least in my case your hope has been fulfilled.
Thanks for the explanation.

Sieben:

--- Quote from: AL ---form.repaint or form.update  after SetDefaultLang(lang)  has done the trick for me
--- End quote ---

I just set up a small sample project here, and yes, SetDefaultLang() (or TranslateFromResources() resp.) followed by Invalidate works for me as well - with the limitations wp mentioned, of course. However, the currently active form is translated in just the same way as any form not yet created.

Main difference with OP's setup I guess is that I was using *.po-files instead of *.mo, which reminds me of this here thread. There seem to be some weird limitations when using *.mo-files...

Navigation

[0] Message Index

[*] Previous page

Go to full version