Hi!

At r50753 "wp" created the support for localization of TAChart, but it is in 6 separate files.
Most of these files contains only 1 (one) sentence (four is the most).

I think there is no reason for this fragmentation, especially because these strings are used only in the GUI designer of Lazarus IDE.

Please pack them into one PO file.

Thanks!

This is work in progress and will probably change. I just wanted to store a working stage before I'd dive into a more difficult part - maybe somebody can help me with that: TAChart registers the names of series types in an internal stringlist. These texts are used in the dropdown for series selection in the GUI designer. But this registration is called by the initialization section of the corresponding unit, i.e. before translation is performed.

Does anybody know of similar situations in the IDE or other packages from which I could learn how to handle this case correctly?

12.12.2015 19:44, Werner Pamler ?????:

The basic method to solve this is to move these assignments (or assign these values for a second time) to a later stage, e.g. OnCreate event of the GUI designer form.

Maxim Ganetsky wrote

The basic method to solve this is to move these assignments (or assign these values for a second time) to a later stage, e.g. OnCreate event of the GUI designer form.

I could solve it in the meantime by modifying the RegisterXXXX procedures used throughout TAChart to store the pointer to the resource string instead of the string directly. Hmmh, it does break backward-compatibility, but I bet nobody has ever written his own chart series so far... Let me see who complains in the forum

--- code begin ---
type
   PStr = ^String;
procedure RegisterSeriesClass(
   ASeriesClass: TSeriesClass; const ACaption: PStr);  // ACaption was a
string before...
begin
   if SeriesClassRegistry.IndexOfClass(ASeriesClass) < 0 then
     SeriesClassRegistry.Add(TClassRegistryItem.Create(ASeriesClass,
ACaption));
end;
...
resourcestring
   rsLineSeries = 'Line series';

initalization

   RegisterSeriesClass(TLineSeries, @rsLineSeries);

---- code end ---

Well, I actually did (i.e. I have some project-specific custom series which I did not commit to TAChat).
However, they are in an old defunct project, and I can upgrade easily enough should it became relevant.
So, just a data point.

As for the translation problem, is it not possible to query translation engine at run-time?
Something similar to _('Line series') from gettext?

13.12.2015 0:54, Werner Pamler ?????:

It does not look nice. You are hacking around const specifier.

Maxim Ganetsky wrote

It does not look nice. You are hacking around const specifier.

Isn't this what the translation system is doing, replace a "constant" string by a translated one?

13.12.2015 18:49, Werner Pamler ?????:

Am 13.12.2015 um 13:26 schrieb Maxim Ganetsky: > It does not look nice. You are hacking around const specifier. Isn't this what the translation system is doing, replace a "constant" string by a translated one?

As I wrote earlier, we translate captions by assigning resourcestring values to them after the translation system was initialized, e.g in OnCreate caption of the form.

Maxim Ganetsky wrote

It does not look nice. You are hacking around const specifier.

Hacking? At least in good company:

excerpt from SysUtils:
     constructor Exception.CreateRes(ResString: PString);
     begin
       inherited create;
       fmessage:=ResString^;
     end;

Isn't this the same? If the address of the resource string is fed into the CreateRes constructor then the exception will be raised with the translated string.

16.12.2015 16:30, Werner Pamler ?????:

There is no const modifier in this excerpt.

Maxim Ganetsky wrote

There is no const modifier in this excerpt.

Oh, I see your point now. Fortunately, the "const" is really not necessary here. Without the "const", would this idea of accessing the translated string be ok?

I do not want to translate the string again because this would bring the hassle of finding the po file into TAChart.

Another question related: Is it possible to find the address of a resource string in the internal resource string table by using its hash value? This would allow me to go back to the old calling convention which had a "string" in the RegisterXXXX procedure (instead of a pointer to a string): In this procedure I could calculate the hash value of the passed untranslated resource string, store it and use it later to retrieve the translated string from the tables.

16.12.2015 17:34, Werner Pamler ?????:

Yes.

I don't know, TBH.

16.12.2015 17:34, Werner Pamler ?????:

See here for the list of available resource string functions:

http://www.freepascal.org/docs-html/3.0.0/prog/progse40.html#x229-2420009.3

Thanks. I know this page, but my fpc-trunk does not find these functions, even if I "search in files" of the entire fpc folder, they do not show up. They do exist in the objpas of fpc3.0.0, but only enclosed by a define "RESSTRSECTIONS" which is not active, and I can't make TAChart depend on a non-standard define of fpc...

17.12.2015 04:19, Werner Pamler ?????:

FPC changed its format of resource strings from RST to RSJ. So documentation seems to be outdated in this regard. Maybe resource string functions were changed too.

In any case I think that it is not worth all the hassle. The current implementation is basically OK IMO.

I added an overloaded version of each registration procedure which accepts a string as parameter like in the old version (of course, this one will not be translated). Therefore, TAChart is backward-compatible again. All related changes were added to the list for merging to RC2.

Thank you for the Russian translation.