Hi,

I'm reading article about localizations in lazarus: http://wiki.freepascal.org/Translations_/_i18n_/_localizations_for_programs . Exists any way to assign translate const to the caption in design time or must I assign translated consts to all controls manually (on form create)? I'm asking, because I wrote recently some small application for android (java + eclipse) and I drew attention to locations mechanism. So in eclipse, caption editor suggest ID from localization file (strings.xml) and in form resource (equivalent of LFM) it looks like: Caption = "@strings/some_id".
This works very fine and could be useful not only for translations but for connecting captions to standard string consts.

Regards

Krzysztof wrote

. Exists any way to assign translate const to the caption in design time or must I assign translated consts to all controls manually (on form create)?

I have not done very much localization but I am always wondering how all these nifty things added for this purpose realy help much. I have done it in the following way:

1.) At each code place where text is going to be displayed I added a case statement that selects a language:
------------------------------------------------------------------------
case Language of
    German:  s := 'Dieser Text ist in deutsch';
    Dutch:      s := '...';
    .....
else             s := 'This text is in english';
    end; // of case
------------------------------------------------------------------------

2.) I have one routine that sets all captions according to the current language:

------------------------------------------------------------------------
begin
case Language of
    German:
       begin
       Button1.Caption  := 'Deutscher Text 1';
       Button2.Caption  := 'Deutscher Text 2';
       ....
       end;
    Dutch:
       begin
       Button1.Caption  := 'Deutscher Text 1';
       Button2.Caption  := 'Deutscher Text 2';
       ....
       end;
    ....
else
       begin
       Button1.Caption  := 'Deutscher Text 1';
       Button2.Caption  := 'Deutscher Text 2';
       ....
       end;
    end; // of case
------------------------------------------------------------------------

IMO This WOW has some advantages:

1.) A person that translate the text not only sees a naked text from another language but also a bit of the (code) context it is displayed in. Sometimes translations are very crude because someone simply translates the text one by one like a google translator without knowing what it means and the outcome is often misleading.

2.) When you change something within the text it reminds you to change it for the other language(s) too.

3.) It is very easy to let the user switch the .) You don't have to bother with these more or less helpful localization constructs that were added to "help" you with localizations

Of course, there are also some (IMO small) drawbacks:

1.) You need access to the code to translate the text

2.) It becomes tricky if you realy want to use an automatic translator

Hi,

J?rgen Hestermann wrote

I have not done very much localization but I am always wondering how all these nifty things added for this purpose realy help much. I have done it in the following way:

In my opinion, your way is a terrible way to do localization! For reasons as follows:

* No auto-detect of language when the application starts up.

* When new languages are added, you must rebuild the whole application (executable).

* You can't use any of the existing PO translating tools which have some brilliant
features like built-in dictionaries, suggested translations, spell checking etc.

* Quickly see a percentage of translation per language.

Sometimes translations are very crude because someone simply translates the text one by one like a google translator without knowing what it means and the outcome is often misleading.

That is why it is important to use good & clear resource string constant names. The constant name alone (and maybe with the help of existing translations) should make it clear in what context it is used, thus helping the translator.

eg:

   rsDate = 'Some Date';
   rsTitle = 'Some dialog title';

vs

   rsAccountingTransactionDate = 'Some Date';
   rsCentreMaintenanceDialogTitle = 'Some dialog title';

I know there is many ways to do this in runtime (in my case, in my framework I have TBaseForm which has virtual method TranslateControls, descendant forms override it and do translation on local controls) but referring to the idea of RAD, in future it could be works in few simple "click" steps:
1. Drop TLabel on form
2. Go to object inspector, execute Caption editor
3. If you don't want translation then write raw text otherwise choise ID (some listbox) from associated translation file
4. Click OK

That exactly Eclipse works. It would be nice to see it future in Lazarus

Graeme Geldenhuys wrote

In my opinion, your way is a terrible way to do localization! For reasons as follows: * No auto-detect of language when the application starts up.

Why is that not possible? If you can detect the language then you can also simply set the language variable to whatevery is needed and call the caption-routine that switches all captions to the selected language.

* When new languages are added, you must rebuild the whole application (executable).

Yes. But why is this a drawback? It speeds up application start because all is in one exe file without having the need to load a separate language file on startup.

* You can't use any of the existing PO translating tools which have some brilliant features like built-in dictionaries, suggested translations, spell checking etc.

Well, I mostly find all these "brilliant" features more disturbing than helpful. And you also have a learning curve to investigate in these tools that eats up time.

* Quickly see a percentage of translation per language.

What do you mean? The number of languages that have been translated? Ok, this might be an issue in a very huge project with hundreds of developers.

Well, this reduces the probability of miss-translation but if you have the code nearby and maybe even comments then you have much more information of what is meant in this case.

Also, sometimes the length of the text is important too (so that a button caption can still be displayed and does not exceed the borders). If you only see a variable name then you don't know about these constraints.

Nevertheless, if lots of people are working on a large project an external file may be of use because the translator may neither be a programmer nor a program user (although in such cases translations are not very good IMO). But for smaller projects this is very convenient and saves cluttering information in too many files and has the mentioned advantages.

AutoTranslate based on user Loacle is a disastrous idea, especially if the program is multi-lingual. Eventually what should be LangA - LangB will end up on a system where it is LangA - LangA and make no also fails badly on such things as LongMonthNames[N] if the Locale is RightToLeft. It returns '???'. The workaround is easy, but I spend too much time writing workarounds. And unless you test with both LeftToRight Locale and a RightToLeft Locale, you are likely to assume that AutoTranslate will take care of you. You will likely be wrong.

On Tue, Jul 31, 2012 at 7:39 PM, J?rgen Hestermann <

Normally, IIRC .po files will be included as resource strings. No speed issues.

Could be, but .po files are still the standard. There are web sites/programs that suggest translations based on the source language string and a database of already translated open source strings. I've used them and they work fine.

I think you could even translate .po files with notepad or vi if you wanted to (and want to avoid that learning curve). Otherwise, have a for translating po files.

Furthermore, using po files is documented quite well on the wiki... at least it got me up and running quickly.
See also Lazarus the complete guide, p. 125.

Also: have pity with your translators - unless you intend to do all translations yourself ;)

That is true, if the translator is tech-savvy.

Also, sometimes the length of the text is important too (so that a button caption can still be displayed and does not exceed the borders). If you only see a variable name then you don't know about these constraints.

Neither can somebody who just looks at the code unless he fires up the form.

We can agree to disagree ;)
I have translated LazPaint to Dutch without having run the program but with the help of suggested translations (especially for graphical programs) and, yes, I must admit, the source code (in extreme cases - when it was unclear when a string was used exactly)... no complaints yet ;)

Hi,

Indeed, being able to select a resource string constant instead of typing raw text would be very handy. I have toyed with the idea in fpGUI's UI Designer too, but haven't found a good "pascal" solution yet.

Hi,

J?rgen Hestermann wrote

> * No auto-detect of language when the application starts up. Why is that not possible? If you can detect the language then you can also simply set the language variable to whatevery is needed and call the

OK, true.

> * When new languages are added, you must rebuild the whole application > (executable). Yes. But why is this a drawback?

Huge. Every time you update a translation, you have to go through the whole Build & Test & Release process - because you are bound to have added new features to your application - so testing is required and time consuming. In my case, I can simply email my clients an update *.po file.

Well, I mostly find all these "brilliant" features more disturbing than helpful. And you also have a learning curve to investigate in these tools that eats up time.

I also remember you saying.... "I have not done very much localization"

> * Quickly see a percentage of translation per language. What do you mean? The number of languages that have been translated?

No, how far each translation is to being 100% complete. In large projects this is very handy, when you have to report back to the boss. Most of those PO editors include such a feature.

Well, this reduces the probability of miss-translation but if you have the code nearby and maybe even comments then you have much more information of what is meant in this case.

In medium to large scale projects, the translator is just that - they are not programmers. So showing them any code will just confuse the hell out of them.

Also, sometimes the length of the text is important too (so that a button caption can still be displayed and does not exceed the borders).

Then design your applications to scale the UI correctly. Content and DPI aware applications should be the norm these days! If not, then you are doing something wrong.

Avishai wrote

AutoTranslate also fails badly on such things as LongMonthNames[N] if the Locale is RightToLeft. It returns '???'.

That's a limitation of the GUI toolkit you are using, NOT a general localization issue.

Reinier Olislagers wrote

Normally, IIRC .po files will be included as resource strings. No speed issues.

Correct. And normally .po files are rather small, so trying to measure the loading time is a waste of time - because we are talking milliseconds here.

Also, in the case of fpGUI based apps, the developer can decide what default language to compile into the project as resource strings, then ship the remaining alternate language .po files and optional extras. This will then save that few milliseconds loading time. :) eg: When we release our product to Germany, German is set as the default language. When we release to England/US/Australia, then English could be set as the default language. But if the German user would rather want to use our product in English, they can do so, because we included the English .po file too (as the alternate language .po files).

BTW: Someone of Lazarus Team reading sometimes this news group? I mean should I post this proposition in bug tracker (mantis?). Exactly this solution:

I really like this solution of Eclipse. I don't know how Delphi > 2010 localization working (I had no chance to test it), but what I read, it has some built in localization manager.

31.07.2012 22:23, Krzysztof ?????:

I don't really understand what you want to achieve with this.

Lazarus already has automatic form translation facilities. See Project Options -> i18n. Your .po files will be updated automatically when you will change your forms.

Does this mean you first design and debug the form, then translate it and then edit the whole form again to connect the translations?

That's true.
You don't even have to create and set translation IDs.

I see one advantage of the IDs in captions: Translating parts of TStrings would be easier.

What is missing are some IDE plugins to make translations easier. For example a tool that shows the translator where a resourcestring is used in the application.
And a page with some hints how to deploy the .po
files on the various platforms.

Mattias

Maxim Ganetsky wrote

Lazarus already has automatic form translation facilities. See Project Options -> i18n. Your .po files will be updated automatically when you will change your forms.

Creating the resource string constants is not the problem. Lazarus does what is already very easy to do manually.
Plus, Lazarus gives automated resource string constant names (eg: TForm1.Button1.Caption) - those tend to be pretty horrible, compared to what I use (eg: rsAccountingTransactionDate), and with my naming it will have some meaning to the translator in their PO Editor tool.

Also, using that Lazarus automated i18n feature, how do you reuse common resource string constants. Lazarus probably isn't going to reuse any - thus creating lots and lots of duplicate translations for the translator. That sucks for the poor translator. Just look at the Lazarus IDE to see how much duplication exists for translators.

What the original poster is proposing seems more sensible, and allows to reuse common resource string constants. Pick a resource string from an already defined list.

As far as I know there is no way to automatically generate "some meaning" like "rsAccountingTransactionDate".
Maybe you can some links to such an algorithm/library?

Yes, please do so. How much duplication do you see for translators in the Lazarus IDE?

What the original poster is proposing seems more sensible, and allows to reuse common resource string constants. Pick a resource string from an already defined list.

Almost all resourcestrings of the IDE were created by picking from a list. Can you be more specific?

Mattias

01.08.2012 2:40, Graeme Geldenhuys ?????:

Reusing string constants is manual process. In my experience in most cases constants reusing is not desirable.

Besides, I fail to see how can original poster's proposal significantly save your time in comparison with manual resourcestring assignments (note that IDE will maintain them automatically too).

Maybe some designer and/or CodeTools helpers can be created to save some typing when assigning resourcestrings to captions.

What the original poster is proposing seems more sensible, and allows to reuse common resource string constants. Pick a resource string from an already defined list.

[...] Maybe some designer and/or CodeTools helpers can be created to save some typing when assigning resourcestrings to captions.

Feel free to improve the "Make resourcestring" dialog. If wanted I can move it to a package, so it is easier to extend/rewrite it.

Mattias

01.08.2012 3:02, Mattias Gaertner ?????:

This duplication is only superficial in almost all cases. Most attempts to eliminate it so far resulted in hard to spot translation bugs (e.g. case related) in Russian translation for example.

01.08.2012 3:10, Mattias Gaertner ?????:

The only improvement I can think of is for the case when we have a form with component captions defined in LFM and then want to make use of resourcestrings. Then we will have to make the following steps.

1. Create the following assignment in e.g. FormCreate event:

    SomeComponent.Caption:='';

2. Copy component's caption to clipboard from OI.

3. Insert this caption to line from point 1.

Maybe this can be automated.

Hi,
Why not expand
GNU Gettext for Delphi, C++ and Kylix
?? be used
with Lazarus:
http://sourceforge.net/projects/dxgettext/
Some advantages:
open source;
Automatic extract of name of components from form; Manually include text to translate (addition to the above)

using .po files
Automatic add translation in .exe (with right-click);
Automatic choose of language depending on Local Settings;
Manual setting of language (if someone don't want previous option);
Very easy to use (even I can use it ;) )

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120801/e5d7d230/attachment.html>

Their website says:
Supports for Kylix 3, Delphi 5, 6, 7, 2005, 2006, 2007, 2009, FreePascal, Lazarus and C++ Builder.

so perhaps that already has been done?

The descriptions seem to indicate it uses Windows explorer integration which I personnally hate, but... it's open source ;)

Hi,

Mattias Gaertner wrote

As far as I know there is no way to automatically generate "some meaning" like "rsAccountingTransactionDate".

Exactly my point, and why the "automation" isn't a good idea.

Yes, please do so. How much duplication do you see for translators in the Lazarus IDE?

I already have done so in the past, and even contributed patches to reduce some duplication in resource strings.

Almost all resourcestrings of the IDE were created by picking from a list. Can you be more specific?

Yes, but as the original poster said, you can't pick from that list using the Object Inspector. That's the point he was trying to make.

Maxim Ganetsky wrote

Reusing string constants is manual process. In my experience in most cases constants reusing is not desirable.

Just to give you a very simple example: So you think it is OK for each form to have there own versions of rsCancel and rsOK for buttons? So for an application with 200+ forms, that is already a lot of duplication.

Besides, I fail to see how can original poster's proposal significantly save your time in comparison with manual resourcestring assignments

A custom String property editor could maintain the list of resource strings - thus adding a new resource on the spot should be possible and fast. Everywhere else you can simply select an existing resource string constant to be used in the Caption & Hint properties. There would be no need for the developer to implement a SetupTranslations() or SetupCaptions() method in each form. If you make it easy enough, developer would stop hard-coding English text in the Caption property of widgets, and opt to rather use resource strings - thus their programs will be immediately possible for translation. It's much harder to add translation afterwards, and prone to errors (missing a translation in some widgets).

Anyway, this is how I envisioned it to work when I researched the idea for fpGUI's UI Designer. And I will still find a suitable solution.

Hi,

J?rgen Hestermann wrote

> And how do you handle nesting of code and text as in:

I really don't see the problem. I have resource strings like that all over the place. Even heard of the Format() function? Here are some resource strings from my applications:

resourcestring

	uiLoggedInAs                = 'Logged in as: %s to %s';
	uiViewsFor                  = 'Views For "%s"';
	uiErrTheItemAlreadExists    = 'The item <%s> already exists.';
	uiErrBulkInvRatesEmpty      = 'It seems some of the Bulk Invoice

Rates items have zero amounts. This is not allowed. Please correct this problem and try again.';

	uiErrXXXIsMissing           = '%s is missing';
	uiErrNoDefaultTaxRate       = 'No default Tax Rate has been set for

this centre. Please contact Head Office.';
uiErrDBVersionMismatch = 'This version of %s, v%d.%2.2d (%s %s), ' + 'is not valid for the current database
version v%s. ' +
'Please make sure you are running the
latest version of %s.';
uiErrMissingDefaultPaths = 'The Default Paths have not been set. Do you want to set them now? $\n' +
'Click Yes to set them now. If you
select No, you can set them $\n' +

	                              'later using the %s menu.';

I normally don't force line breaks in my resource strings. That's up to the widget to word wrap them, and scale the UI. But I do have one such case - see the last example. PO files/editors use the C-style newline character to indicate a line break: $\n

Graeme Geldenhuys wrote

> And how do you handle nesting of code and text as in: I really don't see the problem. I have resource strings like that all over the place. Even heard of the Format() function?

Ah, yes. Well, I have heard of it but I have never used the Format() function. There is a reason I want to program in Pascal and not in C. ;-)

But ok, now I know how this case is handled.

I use this at work for Delphi (2009..XE), and how it works depends strongly on Delphi versions. Unicode versions don't need changes to auto translate resource strings, older versions do.

But since FPC's resource system is different anyway, it is hard to predict how that would work out.

Basically to internationalize an app in D2009 I had to do the following things:

- do something at program startup to select the correct language (like lazarus my apps allow to change language, but require restarts)
- extract all strings using dxgettext tools to form .po files.
- I (visually) inherit most of my forms from a base form that has a method that initializes the gettext translation routines on form creation
- resourcestrings work out the box.
- except when used in structured constants. So _() calls must be inserted for those cases
- Changed all places where I runtime change text to use resourcestrings and format() variable parts into them

The descriptions seem to indicate it uses Windows explorer integration which I personnally hate, but... it's open source ;)

I like the editor (GORM) too (at least over poedit). ... and it is available in source.