gnugettext
Michael Fritz
I've got some const array which should contain translated text:
Just a short code snippet:
TPWCFileRecordIndex =
(friAccValidTo, friAccValidToDate);
TPWCFileRecordName = record
Index : TPWCFileRecordIndex;
FindName : string;
MacroName : string;
SecureName : string;
end;
const
TPWCFileRecordNameArray : array[TPWCFileRecordIndex] of
TPWCFileRecordName =
((Index : friAccValidTo; FindName : ''; MacroName : ''; SecureName :
''),
(Index : friAccValidToDate; FindName : cSecModeRegDateValid;
MacroName : ''; SecureName : cSecModeRegDateValid)
);
cSecModeRegDateValid is a resourcestring from another unit. I'm using this
string in other units too and it's properly translated there (de <-> en).
However when looping through the TPWCFileRecordNameArray and using e.g.
TPWCFileRecordNameArray [icount].FindName, I get the German version of
cSecModeRegDateValid back.
It seems that this const array won't be translated into English during code
execution, right? How would you build such an array?
cu,
Michael Fritz
Lars B. Dybdahl
> cSecModeRegDateValid is a resourcestring from another unit.
> code execution, right? How would you build such an array?
The problem seems to be, that the resourcestrings are assigned before the
resourcestring hook is set, and therefore, you get the original version,
and not the translated version when initializing your array like that.
The solution is simple, though: Loop through the array like this:
for i:=low(array) to high(array) do
array[i].FindName:=_(array[i].FindName);
This way, you can specify exactly which parts of the records you want to
have translated, and which you don't.
There is an RFE, that specifies to get strings inside array initializations
translated, too:
http://sourceforge.net/tracker/index.php?func=detail&aid=710596&group_id=74086&atid=539911
Some of the original RFE has already been implemented in version 1.1 beta 2.
Lars Dybdahl.
>
> cu,
> Michael Fritz
--
Dybdahl Engineering
Denmark
Free GNU gettext for Delphi i18n/localization tool:
http://dybdahl.dk/dxgettext/
Michael Fritz
As usual! Works perfectly! Thanks!
> Some of the original RFE has already been implemented in version 1.1 beta
2.
Does this mean that I must not use e.g. _([i].name) for string arrays in the
near future?
cu,
Michael
Lars B. Dybdahl
> Does this mean that I must not use e.g. _([i].name) for string arrays in
> the near future?
No - but it will be possible to do things like:
{gnugettext: scan-all}
var
mylist:array[0..6] of string=('Monday', 'Tuesday', 'Wednesday',
'Thursday', 'Friday', 'Saturday', 'Sunday');
{gnugettext: reset}
for i:=low(mylist) to high(mylist) do
mylist[i].FindName:=_(mylist[i].FindName);
The two comments will make all the strings in between be extracted and
provided to the translator. This reduces the amount of typing needed. In
the Delphi ITE, you would have to define a resourcestring for each array
index - this is extremely tedious, especially if you are internationalizing
an existing application.
But - it hasn't been fully implemented, yet, but I hope it will be in
version 1.1.
Lars.
Michael Fritz
once again a problem, at least it seems to be one....
I've used gnugettext.pas dated 15.04.2003. The following
lines did not made any problems so far:
type
TfrmMain = class(TForm)
[..]
private
FRetranslator : TExecutable;
[..]
end;
In FormCreate:
[..]
{$I 'TranslationExclude.pas'}
FRetranslator :=
gnugettext.DefaultInstance.TP_CreateRetranslator;
[..]
TranslateProperties(Self);
[..]
LoadSettingsfromINI();
[..]
UseLanguage(FGlobalSettings.DialogLanguageCode);
FRetranslator.Execute;
[..]
So far no problem at all. Since using version 1.0.1 the
application crashes with an AV when executing the line
FRetranslator.Execute;
The address where the AV points to is TObject.Free. I did
not change coding at all but replace gnugettext.pas with
the new version.
Any hints?
Michael
Lars B. Dybdahl
> So far no problem at all. Since using version 1.0.1 the
> application crashes with an AV when executing the line
> FRetranslator.Execute;
TranslateProperties() and the retranslator have been deprecated. You should
use TranslateComponent() instead, and use it for both initial translation
and after changing the language at runtime. If you want a quick way to find
them all, get the version 1.1 beta 2, where the TranslateProperties()
function has been marked deprecated, which makes the use of it appear in
the compiler messages window.
But the problem might be something else - that something is translated in
your user interface that doesn't like being translated. A typical problem
can be, that you have an event handler on something, that crashes. This can
be solved by debugging - either single-stepping through the retranslation,
or by setting breakpoints on your events.
Lars Dybdahl.
Michael Fritz
should
> use TranslateComponent() instead, and use it for both initial translation
I've changed this and the AV disappeared! Thanks!
Michael