[Lazarus] TAChart Localization
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! -- Péter Gábor p...@freemail.hu -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart Localization
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? Am 12.12.2015 um 15:30 schrieb Péter Gábor: 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! -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart Localization
12.12.2015 19:44, Werner Pamler пишет: 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? 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. Am 12.12.2015 um 15:30 schrieb Péter Gábor: 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! -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart Localization
Am 12.12.2015 um 22:23 schrieb Maxim Ganetsky: 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 Register 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 --- -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart Localization
On Sun, Dec 13, 2015 at 7:54 AM, Werner Pamler wrote:
> Am 12.12.2015 um 22:23 schrieb Maxim Ganetsky:
>>
>> 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 Register 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
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?
--
Alexander S. Klenin
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart Localization
13.12.2015 0:54, Werner Pamler пишет: Am 12.12.2015 um 22:23 schrieb Maxim Ganetsky: 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 Register 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 --- It does not look nice. You are hacking around const specifier. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart Localization
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? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart Localization
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. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart Localization
Am 13.12.2015 um 13:26 schrieb Maxim Ganetsky: 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart Localization
16.12.2015 16:30, Werner Pamler пишет: > Am 13.12.2015 um 13:26 schrieb Maxim Ganetsky: >> 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. There is no const modifier in this excerpt. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart Localization
Am 16.12.2015 um 15:16 schrieb Maxim Ganetsky: 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 Register 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart Localization
16.12.2015 17:34, Werner Pamler пишет: > Am 16.12.2015 um 15:16 schrieb Maxim Ganetsky: >> 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? Yes. > 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 Register 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. I don't know, TBH. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart Localization
16.12.2015 17:34, Werner Pamler пишет: 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 Register 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. 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 -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart Localization
Am 17.12.2015 um 01:01 schrieb Maxim Ganetsky: 16.12.2015 17:34, Werner Pamler пишет: 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 Register 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. 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... -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart Localization
17.12.2015 04:19, Werner Pamler пишет: > Am 17.12.2015 um 01:01 schrieb Maxim Ganetsky: >> 16.12.2015 17:34, Werner Pamler пишет: >>> 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 Register 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. >> >> 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... 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. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart Localization
Am 17.12.2015 um 12:09 schrieb Maxim Ganetsky: 17.12.2015 04:19, Werner Pamler пишет: Am 17.12.2015 um 01:01 schrieb Maxim Ganetsky: 16.12.2015 17:34, Werner Pamler пишет: 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 Register 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. 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... 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. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
