[Lazarus] Localization in toolkit like fpGUI

[Hess, Philip J]

Hi Graeme,

For ideas you might take a look at how OS X does it. The further along
you get in your thinking, the more it sounds like you risk the
possibility of reinventing the wheel:

http://developer.apple.com/documentation/MacOSX/Conceptual/BPInternation
al/BPInternational.html

Thanks.

-Phil


-----Original Message-----
From: lazarus-bounces at lazarus.freepascal.org
[mailto:lazarus-bounces at lazarus.freepascal.org] On Behalf Of Graeme
Geldenhuys
Sent: Tuesday, February 19, 2008 7:10 AM
To: General mailing list
Subject: Re: [Lazarus] Localization in toolkit like fpGUI

On 19/02/2008, Giuliano Colla <giuliano.colla at fastwebnet.it> wrote:
>
> Are you really sure that a single executable is a must?
>
> I found out, at least in my experience, that by an end user point of
> view, a self extracting zip (Windows), a tar.bz2 (*nix), or a .dmg
(Mac)
> is pretty much the same, and allows to distribute a folder instead of
a
> file.

OK, I have been convinced that recompiling the executable just to get
a different language is NOT the way to go.  Runtime loading is far
better and more flexible.

So if we use GetText and external .po files for example. If somebody
wanted to translate you cool fpGUI based utility application
(myapp.exe) in a new language, they can start off by using the .po
file generated by fpGUI (if one wasn't already created) and then the
.po file generate by the application.

eg:
  myapp.exe  (English is default language)  The developer can toggle
the default fpGUI language at compile time using the $Defines as
described before. This for example allows Russian only apps to have no
external .po files.

The fpgui.po file is create from the .rst file when fpGUI is compiled.
It contains the resource strings used by fpGUI (eg: dialogs, messages,
buttons etc).

TfpgApplication must automatically looks for two *.po files.
fpgui_XXX.po which will contain the translations for fpGUI (hard coded
to fpgui_XXX.po in the same directory as the executable). The second
file is say myapp_XXX.po which will contain the myapp.exe specific
translations. The second file is based on the application name
(ParamStr(0) or ApplicationName() result) with a language code at the
end.

eg:
For a English version you need:
  myapp.exe      (English as default compiled in language)

For a German version you need:
  myapp.exe      (English as default compiled in language)
  fpgui_de.po    (German translation of fpGUI)
  myapp_de.po    (German translation of myapp)

For a Russian version you need:
  myapp.exe      (English as default compiled in language)
  fpgui_ru.po    (Russian translation of fpGUI)
  myapp_ru.po    (Russian translation of myapp)

myapp.exe can obviously reuse the resourcestring constants already
defined in fpGUI. Things like rsOK, rsCancel etc.. So those will not
be in the myapp_XXX.po files

You are allowed to have some files missing to. If for example you only
had myapp.exe and myapp_de.po then any fpGUI messages etc will be in
English, but the rest of the application specific text will be in
German. This is just an example of what is allow.

Could this work?  This means two .po files for a new language, but we
can start building up a collection of fpGUI translations (available
for download) so after a while only the myapp_XXX.po files would need
to be translated. The fpGUI part can simply be downloaded.


Does this make any sense?  I can't see how you can get away with only
a single .po file for a Application and fpGUI translation.  So I guess
two .po files will have to do.


Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
_______________________________________________
Lazarus mailing list
Lazarus at lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus