Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2008-03

Resource string constants support in the Object Inspector

16 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Graeme Geldenhuys

Hi,

In fpGUI's UI Designer I'm trying to come up with an idea to add support for resource strings in the Object Inspector. If I can come up with a good enough idea, I will to try and implement it in Lazarus as well (if my knowledge of Lazarus IDE is good enough), otherwise I add it as a feature request.

Here is an example under fpGUI, but the same issue applies to Lazarus's LCL based applications.

Take a TfpgButton.Text property as an example. If you type 'rsToday' without the quotes in the text property, the UI Designer will generate the code

  with SomeButton do
  begin
    ...
    Text := 'rsToday';
    ...
  end;

Which means it's going to display 'rsToday' on the button and not the resource string value of rsToday.

How can we let UI Designer distinguish between a string literal and a resource string constant?

My first thought was to do something like the named font or named color support in fpGUI. Add a '#' character in the front. The UI Designer would check the first character and if it's a #, write it as a resource string instead of plain text. Instantly that idea failed because I have a StringGrid in my application with columns titles like '#1', '#2' etc...

Any other thoughts? Is something like this even possible in Lazarus, or will the usage of TReader/TWriter fail with resource string constants. fpGUI's UI Designer generates actual Object Pascal code, so might be easier to implement than Lazarus *.lfm files.

Regards,
- Graeme -

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

Reply by email

ik
to Graeme Geldenhuys

I find it weird a bit, but I also see the power in it.

Object Inspector assign values like property_name := value;

If you want to add some sort of language inside the Object inspector (like %${const}$%, it will be easier to distingwish things... and if you want litural the write the constant as follows: '%${const}$%' inside the object inspector. (You can come out with any idea of combination you wish).

But It scares me a bit.

Ido

Graeme Geldenhuys wrote 53 lines
Hi, In fpGUI's UI Designer I'm trying to come up with an idea to add support for resource strings in the Object Inspector. If I can come up with a good enough idea, I will to try and implement it in Lazarus as well (if my knowledge of Lazarus IDE is good enough), otherwise I add it as a feature request. Here is an example under fpGUI, but the same issue applies to Lazarus's LCL based applications. Take a TfpgButton.Text property as an example. If you type 'rsToday' without the quotes in the text property, the UI Designer will generate the code with SomeButton do begin ... Text := 'rsToday'; ... end; Which means it's going to display 'rsToday' on the button and not the resource string value of rsToday. How can we let UI Designer distinguish between a string literal and a resource string constant? My first thought was to do something like the named font or named color support in fpGUI. Add a '#' character in the front. The UI Designer would check the first character and if it's a #, write it as a resource string instead of plain text. Instantly that idea failed because I have a StringGrid in my application with columns titles like '#1', '#2' etc... Any other thoughts? Is something like this even possible in Lazarus, or will the usage of TReader/TWriter fail with resource string constants. fpGUI's UI Designer generates actual Object Pascal code, so might be easier to implement than Lazarus *.lfm files. Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _______________________________________________ Lazarus mailing list http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
http://ik.homelinux.org/

Reply by email

Graeme Geldenhuys
to ik
ik wrote
I find it weird a bit, but I also see the power in it.

I think it will be very handy! Currently you assign a hard-coded string like 'Hello' to a button's caption and then later in your code you need to write something like

   MyButton.Caption := rsHello;

just to replace what the Object Inspector did the first time round. This seems like a waist. Why couldn't the Object Inspector use the resource string in the first place.

One issue that might come up in Lazarus (not fpGUI) is a question of timing. What if rsHello is assigned before correct localization was loaded. fpGUI does localization handling in Application.Initialize

Regards,
- Graeme -

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

Reply by email

Marc Weustink
to Graeme Geldenhuys
Graeme Geldenhuys wrote 16 lines
On 17/03/2008, ik wrote: > I find it weird a bit, but I also see the power in it. I think it will be very handy! Currently you assign a hard-coded string like 'Hello' to a button's caption and then later in your code you need to write something like MyButton.Caption := rsHello; just to replace what the Object Inspector did the first time round. This seems like a waist. Why couldn't the Object Inspector use the resource string in the first place. One issue that might come up in Lazarus (not fpGUI) is a question of timing. What if rsHello is assigned before correct localization was loaded. fpGUI does localization handling in Application.Initialize

We have thought about this OI localization long ago. I'll try to recall what we have thought of.

Every localizable property will be declared as a TTranslateString (and not as String).
When such a property is written, the IDE also generates a constant for it. Then on loading, the lcl catches those properties and will replace them with the proper translation.
However, one problem we had (and there the idea stopped) is how to unique identify those constants in such way that it is clear on what instance the constant is used (so that you can translate them).

Marc

Reply by email

Graeme Geldenhuys
to Marc Weustink
Marc Weustink wrote
Every localizable property will be declared as a TTranslateString (and not as String).

Ah, I've seen the TTranslateString type around. :)

When such a property is written, the IDE also generates a constant for it. Then on loading, the lcl catches those properties and will replace them with the proper translation.

Maybe the IDE is trying to hard. Why not create a Property Editor for TTranslateString types. In the Editor the user can specify the resource string identifier and default value.

The IDE can then take it from there...

If the user simply typed Text in the OI, no resource string identifier is created and it's simply handled as a standard string value. That way, no existing code will be broken (kind-of).

Regards,
- Graeme -

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

Reply by email

Graeme Geldenhuys
to Mattias Gärtner: An embedded and charset-unspecified text was scrubbed... Name: not available Url:…
Mattias G?rtner wrote 5 lines
For LCL applications the translator unit inits the default language from the environment vars. The timing depends on the position in the uses clause of the project. The language can be later set by the app. The question is, when should the .po files (or whatever) read to setup the resourcestrings. Application.Initialize is probably a good place for most apps.

How does LCL applications handle translation of the LCL itself and the translation files of the application?

eg: LCL is translated to English and German. These translations can be reused in the LCL application, but the application will have specific translations as well (also English and German)? Does LCL based applications load both (LCL and Application) translation files, or does it merge them somewhere into a single translation file etc...?

In fpGUI I handle this by searching for the toolkit's translation file first (fpgui_XXX.po) and load it into the resourcestrings (this file can be shared between fpGUI based applications). Then I look for a translation file that has the same name as the application's executabe (eg; myapp_XXX.po) and in the same location as the executable and inserts that into GetText's translation array. Be careful here, because by default the second .po file will clear the original translation array. All this occurs in Application.Initialize and seems to work quite well so far.

Regards,
- Graeme -

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

Reply by email

Graeme Geldenhuys
to Mattias Gärtner: An embedded and charset-unspecified text was scrubbed... Name: not available Url:…
Mattias G?rtner wrote 5 lines
We talked about that. AFAIR it came down to this: For the biggest part of the TTranslateStrings it is sufficient to use the package name plus original value as identifier for the lookup. For example all OkButton captions can use one translation.

And for identifier lookup to work with Lazarus's translation (gettext) unit, the patch submitted in Mantis bug #10938
[http://bugs.freepascal.org/view.php?id=10938] needs to be applied.

BTW: Locale information/standards suck under *unix environments, unless you lock yourself into 'libc' which limits you to Linux/x86. :-( Because of that the LongMonthNames, LongDayNames etc arrays in RTL never gets translated, no matter to what value you set LANG etc. For that reason fpGUI's toolkit translation files contain translated text for those arrays and date/time formats etc...

Does that have an affect on LCL based applications as well? Or is it only because fpGUI talks directly to Xlib and not via GTK, GTK2 or Qt toolkits which probably implement there own locale settings.

Regards,
- Graeme -

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

Reply by email

Mattias Gärtner
to Graeme Geldenhuys

Zitat von Graeme Geldenhuys :

Show quoted text 12 lines
On 17/03/2008, Mattias G?rtner wrote: > > We talked about that. AFAIR it came down to this: > For the biggest part of the TTranslateStrings it is sufficient to use the > package name plus original value as identifier for the lookup. For example all > OkButton captions can use one translation. And for identifier lookup to work with Lazarus's translation (gettext) unit, the patch submitted in Mantis bug #10938 [http://bugs.freepascal.org/view.php?id=10938] needs to be applied.

Fixed.

Show quoted text 6 lines
BTW: Locale information/standards suck under *unix environments, unless you lock yourself into 'libc' which limits you to Linux/x86. :-( Because of that the LongMonthNames, LongDayNames etc arrays in RTL never gets translated, no matter to what value you set LANG etc. For that reason fpGUI's toolkit translation files contain translated text for those arrays and date/time formats etc...

I only found code to translate them under windows and wince. Maybe this is just not implemented under unix?

Does that have an affect on LCL based applications as well? Or is it only because fpGUI talks directly to Xlib and not via GTK, GTK2 or Qt toolkits which probably implement there own locale settings.

I guess this is independent.
But maybe a solution can be easier for the LCL, because it can use full blown widgetsets, while the RTL has only the kernel functions.

Mattias

Reply by email

Mattias Gärtner
to Graeme Geldenhuys: How does LCL applications handle translation of the LCL itself and the translation files…

Zitat von Graeme Geldenhuys :

Show quoted text 19 lines
On 17/03/2008, Mattias G?rtner wrote: > For LCL applications the translator unit inits the default language from the > environment vars. The timing depends on the position in the uses clause of the > project. The language can be later set by the app. > The question is, when should the .po files (or whatever) read to setup the > resourcestrings. Application.Initialize is probably a good place for most apps. How does LCL applications handle translation of the LCL itself and the translation files of the application? eg: LCL is translated to English and German. These translations can be reused in the LCL application, but the application will have specific translations as well (also English and German)? Does LCL based applications load both (LCL and Application) translation files, or does it merge them somewhere into a single translation file etc...?

There is no standard yet.
For single binary apps both is possible, but single files may be nicer. For apps using packages in dynamic libraries the translations should be at least one file per library/package.
The naming and path conventions depend on the platform/installer-system. A wiki page should be started and the various conventions should be collected. Then we can decide a standard and implement some tools.

Show quoted text 9 lines
In fpGUI I handle this by searching for the toolkit's translation file first (fpgui_XXX.po) and load it into the resourcestrings (this file can be shared between fpGUI based applications). Then I look for a translation file that has the same name as the application's executabe (eg; myapp_XXX.po) and in the same location as the executable and inserts that into GetText's translation array. Be careful here, because by default the second .po file will clear the original translation array. All this occurs in Application.Initialize and seems to work quite well so far.

This is one solution. But some installer/package systems expect that translation files should be in specific separate directories (e.g. sub directories).

Mattias

Reply by email

Graeme Geldenhuys
to Mattias Gärtner: Zitat von Graeme Geldenhuys : Fixed. I only found code to translate them under windows…
Mattias G?rtner wrote 5 lines
> And for identifier lookup to work with Lazarus's translation (gettext) > unit, the patch submitted in Mantis bug #10938 > [http://bugs.freepascal.org/view.php?id=10938] needs to be applied. Fixed.

Thanks. :-)

I only found code to translate them under windows and wince. Maybe this is just not implemented under unix?

For one, the RTL under Linux sets no localization. Even the date format is hard-coded. :-(

Show quoted text 7 lines
> Does that have an affect on LCL based applications as well? Or is it > only because fpGUI talks directly to Xlib and not via GTK, GTK2 or Qt > toolkits which probably implement there own locale settings. I guess this is independent. But maybe a solution can be easier for the LCL, because it can use full blown widgetsets, while the RTL has only the kernel functions.

I wouldn't put much faith in the widgetsets either. I use Ubuntu with the standard Gnome desktop. At installation I chose English-South Africa, which the LANG shows (en_ZA.UTF-8). Yet in various Gnome applications like File Dialogs, Thunderbird Email Client etc the date formats all vary. Go figure! :-) *unix based OS's still seem to have a loooooong way to go in getting some consistency between applications.

Regards,
- Graeme -

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

Reply by email

Graeme Geldenhuys
to Mattias Gärtner: Zitat von Graeme Geldenhuys : There is no standard yet. For single binary apps both is…
Mattias G?rtner wrote
There is no standard yet.

Can LCL be compiled to a different default language (other than English)? Or do you always need the external .po files around? eg: Say I want to ship a German application (and German LCL messages) with no external files (.po or otherwise).

For single binary apps both is possible, but single files may be nicer.

Single files sound nice, but I can't see them working in practice. The application and LCL are two separate projects. Different people will probably translate each part. LCL has been around for some time and could have many translations already while the application could be new. Then again, if one could somehow merge the two translation files before the applications is distributed, it could work. Seeing that .po files are plain text, that should be a fairly trivial task. And now I've just contradicted my own statement in the beginning of this paragraph :)

A wiki page should be started and the various conventions should be collected. Then we can decide a standard and implement some tools.

That sounds like a good idea.

This is one solution. But some installer/package systems expect that translation files should be in specific separate directories (e.g. sub directories).

fpGUI has support for alternative directories (fpgui_XXX.po is one such example), I simply don't use them at the moment for the application translation files.

Regards,
- Graeme -

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

Reply by email

Mattias Gaertner
to Graeme Geldenhuys
Show quoted text 8 lines
On 17/03/2008, Mattias G?rtner wrote: > > There is no standard yet. Can LCL be compiled to a different default language (other than English)? Or do you always need the external .po files around? eg: Say I want to ship a German application (and German LCL messages) with no external files (.po or otherwise).

Add the .po file as resource.

Show quoted text 12 lines
> For single binary apps both is possible, but single files may be > nicer. Single files sound nice, but I can't see them working in practice. The application and LCL are two separate projects. Different people will probably translate each part. LCL has been around for some time and could have many translations already while the application could be new. Then again, if one could somehow merge the two translation files before the applications is distributed, it could work. Seeing that .po files are plain text, that should be a fairly trivial task. And now I've just contradicted my own statement in the beginning of this paragraph :)

:)

Show quoted text 5 lines
> A wiki page should be started and the various conventions should > be collected. Then we can decide a standard and implement some > tools. That sounds like a good idea.

Please start it.

Show quoted text 7 lines
> This is one solution. But some installer/package systems expect > that translation files should be in specific separate directories > (e.g. sub directories). fpGUI has support for alternative directories (fpgui_XXX.po is one such example), I simply don't use them at the moment for the application translation files.

Mattias

Reply by email