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 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
