[fpc-pascal] resourcestring and const arrays

[Craig Peterson]

On 6/25/2011 7:55 AM, Marco van de Voort wrote:
> Well, then explain why Delphi + XE has exactly the same problem.

Delphi + gettext does, yes, but Delphi + resourcestring + resource dll 
does not.  Resourcestring is a language feature;  gettext is a 
third-party library.  I'd expect them to have different semantics.  As a 
language feature, the compiler/rtl should provide a way to translate 
resourcestrings and have it work correctly.  The fact that FPC uses 
gettext and Delphi uses stringtables on the backend are irrelevant 
implementation details.

> What you are trying to do is implementation defined.

Obviously, but it shouldn't be.  "resourcestring" means "I want to 
translate this string, but the code should work like a regular string".  
IMO, FPC's behavior breaks that contract.

> More or less. When localizing, the default windows resources model simply
> loads a resource dll (containing the localized data including copies of all
> forms, so an user can adjust e.g. the width of a text field) over the
> addresses where in the main .exe the original resources are.

That's incorrect.  Resource DLLs are loaded using LoadLibrary, just like 
regular ones, and then you pass that handle to FindResource/LoadResource 
to load the localized version.  If you pass a nil handle in it will 
still return the original untranslated version.  Delphi's DFM loading 
and resourcestring implementations hide those details, but they are 
explicit actions on the RTL's part.

> Hence their (gettext) behaviour in Delphi is exactly the same as in FPC.

Don't confuse using gettext explicitly through _() and implicitly 
through resourcestring.  In Delphi, accessing a resourcestring 
translates into a call to LoadResString(), which uses 
FindResourceHInstance to load from the translated DLL.  On FPC, it just 
reads directly from a variable you can update with SetResourceStrings.  
The difference is that if you have a const reference to one Delphi does 
a separate pass that fixes those references as well with a explicit 
LoadResString calls during program initialization.  It could just as 
easily use gettext() to retrieve the translated strings, and that's what 
dxgettext's AddDomainForResourceString does.  If it 
AddDomainForResourceString doesn't update the const references properly, 
it's just because it isn't calling the routine that does those const 
fixups (System._InitResStrings).

Basically, to get the correct resourcestring behavior, FPC would have to 
maintain a similar table of resourcestring const references, and when 
you call SetResourceStrings it would have to update those references 
too.  It would require changes to RTL and the compiler (to build the 
table), but the gettext functions wouldn't be affected at all.

This is getting pretty technical though.  Would I have better luck on 
fpc-devel?

-- 
Craig Peterson
Scooter Software