Hi,

I know this is not directly related to Lazarus, but I thought with all the experience collected and that Lazarus supports localization, I might get some good ideas here...

I want to localize the fpGUI toolkit. Standard dialogs, error messages, etc... What is the best way to approach this.

1) GetText: This was my first thought, but that means every fpGUI based application needs to ship with external .po files which I don't like and don't want. fpGUI based applications must preferably be a single works great for your own
applications, but not for the GUI framework I think.

2) Include files with Constants. This is what I'm starting with for now. A gfx_constants.pas unit with $Defines for each supported language. Depending on which define you have active, it will pull in the correct language .inc file with resource strings. If no define has been specified, it defaults to English. This obviously happens at compile time, but at least we have no external files to ship with a simple one file fpGUI based application. The only down side is when you add a new constant, you must remember to insert it into all the other language .inc files - though I'm sure I can create some tool to automate this.

eg:
----------------[ gfx_constants.pas ]--------------------- ....
resourcestring

{ Define Compiler language symbol (eg: gr for German) to include the correct language resource file otherwise the Default (English) resource file will be used. }

{.$DEFINE gr} // German
{.$DEFINE ru} // Russian
{.$DEFINE fr} // French
{.$DEFINE pt} // Portuguese

{$IF defined(gr)}
  {$I lang_german.inc}
{$ELSEIF defined(ru)}
  {$I lang_russian.inc}
{$ELSEIF defined(fr)}
  {$I lang_french.inc}
{$ELSEIF defined(pt)}
  {$I lang_portuguese.inc}
{$ELSE}
  {$I lang_english.inc}
{$IFEND}
....
----------------[ end ]--------------------

Example language include file:

------------[ lang_english.inc ]-------------
{%mainunit gfx_constants.pas}

rsLanguage               = 'English';
// Buttons
rsOK                     = 'OK';
rsCancel                 = 'Cancel';
rsHelp                   = 'Help';
...
--------------[ end ]--------------------

3) ???? Anybody got any other ideas? Remember, this is localization for a Toolkit, not for a application. GetText works perfectly for a application.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Hi,

Well I don't like both ideas. Because when (?) fpGUI will support Bi-Directional and other Unicode rules, you will require to have some sort of code to find out what rule to apply on non direction and/or other invisible chars (unless we add it to each text line).

However both GTK and QT are using gnu gettext, and it does work. Please remember that fpGUI is more like GTK and QT then a single executable. I also believe that if you'll make a library out of the GUI, you will give chance to other programming languages to use it as well.

So if you'll use the library way, gettext is the right solution, and you must also think also on the chars you wish your program to support.. So if you wish to use the one executable file, then you should use the resourcesting solution IMHO.

Ido

GetText is not sacred: it is just one mechanism to handle resourcestrings.

The resources branch has a complete implementation of resources for ALL platforms supported by FPC. You can store the resource strings in resources, (as delphi does) and link in the correct resources. Normally, the resource support should be merged in to trunk.

My recommendation is to go with resource strings as you would do now with constants, and when the compiler has the needed support, switch it to a single resource file.

Michael.

Sorry for offtopic, but it is good moment to ask you when it will be merged and will it be merged into fixes 2.2? Or will we wait few years before resource support release (in case of releasing it with fpc 2.4)?

Btw, I see no changes in resources branch for last week or more.

Best regards,
Paul Ishenin.

An embedded and charset-unspecified text was scrubbed... Name: not available
Url: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080219/6f4316cb/attachment.pl

I don't fully understand this.... I've never looked in any resources branch. Might explaining a bit more?

My recommendation is to go with resource strings as you would do now with constants, and when the compiler has the needed support, switch it to a single resource file.

So you are saying option (2) is okay for now. I have all text defined as resourcestring, but currently I'm ignoring the generated .rst file and simply using them (rsXXXX constants) as if they were standard constants.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I have already noticed and thought of that. Starting to changes some of the dialogs to use the resourcestring constants.

eg:
    lblFontName.Text  := rsFont + ':';

For bi-directional languanges the ':' will be on the wrong end. ;) Hell, I was hoping nobody would notice or that it would become somebody else problem. :-) Planning ahead is always the better solution. A quick solution for something like the above, is to extract that (rsFont + ':') into a function so that in the future the function can decide where the colon must be placed.

executable. I also believe that if you'll make a library out of the GUI, you will give chance to other programming languages to use it as well.

That would be nice, but I have no idea what that would involve.

So if you'll use the library way, gettext is the right solution, and you must also think also on the chars you wish your program to

But again with GetText the simplest little single executable program in a non-english language is going to require a external language file. This it what I don't like about GetText for a toolkit.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

It is stable and functioning. For my part, it can be merged today.

If you spam Florian or Peter Vreman enough, maybe they'll do it ;-)

Michael.

Umm, I'll look into the compiled in .po files. Loading at runtime always sounds good, but I don't think fpGUI can be considered as a library yet. To me a library is a .dll or .so file. fpGUI is a package of units compiled into a executable.

I don't really know what is the advantages of making fpGUI into a library (eg fpgui.dll or fpgui.so file) compared to a nice single executable.

Don't use custom abbreviations. When the library grows then 'greek' might be added and you get into naming trouble. (And germans start searching for de, not gr)

Oops, that was a oversight! Thanks for pointing it out. My intension was to use standardized 2 char language abbreviations.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Giulio Bernardi created an extension to the compiler so it can use resources (linked in data such as bitmaps, icons, strings and whatnot, just like windows) for all platforms.

Since this is an experimental feature, it was decided to put this in a separate branch in Subversion:
http://svn.freepascal.org/svn/fpc/branches/resources

Yes. I think that this is OK.

(maybe take into account what Mattias said regarding defines)

Michael.

Zitat von Graeme Geldenhuys :

I don't see how this matters here. A good lib must be able to load a translation without recompiling.

I don't really know what is the advantages of making fpGUI into a library (eg fpgui.dll or fpgui.so file) compared to a nice single executable.

I don't know neither.

[...]

Mattias

Michael Van Canneyt ?????:

It will be imposible if you will not merge it first. So if you can do that today please do.

Best regards,
Paul Ishenin.

Graeme Geldenhuys ha scritto:

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.

This makes it possible to keep large images as separate files, to add translation files without touching the source code, to provide a launch script, an icon in the taskbar or in the desktop, etc.

It also permits to change the language at run-time, which sometimes is required.

Just my 2 c

Giuliano

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/

I meant:

you should bug Florian and Peter to do the merge: it's a compiler change, and they decide whether or not it takes place.

Michael.

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

Take a look at how the magnifier handles this. It's a class which centralizes all necessary strings and can translate them on demand:

http://magnifier.svn.sourceforge.net/viewvc/magnifier/trunk/translationsvmg.pas?revision=128&view=markup

The contents of each translate function could be moved to .inc files, to make it easier for translators, I just hadn't time to do that.

The advantages are:

* Can be translated at run-time, no need to restart

* Accepts comments to help translators

* No need for IFDEFs

Felipe Monteiro de Carvalho wrote

Take a look at how the magnifier handles this. It's a class which centralizes all necessary strings and can translate them on demand:

Thanks Felipe, but the problem with that implementation is that you cannot add any new translations without recompiling the application. So your idea ends up being the same as what I initially thought of, but that's not ideal.

eg:
    TTranslations = class(TObject)
     ....
        procedure TranslateToEnglish;
        procedure TranslateToPortuguese;
        procedure TranslateToSpanish;
        procedure TranslateToFrench;
        procedure TranslateToGerman;
        procedure TranslateToItalian;
        procedure TranslateToRussian;
        procedure TranslateToPolish;
    ...
    end;

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Seems not you nor Florian want to take decision about resources branch :) Last time I asked Florian about merge he said that since you created branch you should merge it into the trunk. But maybe I misunderstanded something.

Best regards,
Paul Ishenin.

I can do the merging, but I cannot decide whether the code is good enough to be merged, only Florian or Peter can do that; Till now I didn't get any confirmation that this is so.

Well, for me it's not a problem to merge it.
I'll merge it tonight then, so be ready :)

Michael.

Just a thought: if fpc is about to support ressources on all OS in the stable branch, why using gettext instead ?

It just sounds like adding code to do something fpc already does.

(on the assumptions that ressource branch will be merged in a matter of days, considering previous posts)

Because someone may not want to use resources.
.po files have the advantage that they can be shared between applications.

Michael.

Michael Van Canneyt wrote

Because someone may not want to use resources. .po files have the advantage that they can be shared between applications.

Hi Michael,

Maybe I simply don't understand resources... even in Delphi. So how would I translate my program? Using the .rst file and having multiple copies for each language?

Would I be able to add languages without having to recompiling the application? I can see how to do this with .po files, but I'm not sure if .rst (or whatever resource files are named as) files work the same.

Also, if resource files do not exist on anything other than Windows, that means we need to start creating resource editors for all other platforms.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Felipe, see line 181:

lpSupportInfo := 'Universidade de Sao P?ulo';

The tilde is in the wrong place.

2008/2/19, Felipe Monteiro de Carvalho :