Zitat von Marc Weustink <[EMAIL PROTECTED]>: > Graeme Geldenhuys wrote: > > On 17/03/2008, ik <[EMAIL PROTECTED]> wrote: > >> I find it weird a bit, but I also see the power in it. > > > > I think it will be very handy! Currently you assign a hard-coded > > string like 'Hello' to a button's caption and then later in your code > > you need to write something like > > > > MyButton.Caption := rsHello; > > > > just to replace what the Object Inspector did the first time round. > > This seems like a waist. Why couldn't the Object Inspector use the > > resource string in the first place.
I guess, you mean the form loader and not the OI. The OI just shows the current state and does not translate. About form loader see Marc's remark: it can already load resourcestrings on the fly, avoiding double assignments. > > One issue that might come up in Lazarus (not fpGUI) is a question of > > timing. What if rsHello is assigned before correct localization was > > loaded. fpGUI does localization handling in Application.Initialize > > We have thought about this OI localization long ago. I'll try to recall > what we have thought of. > > Every localizable property will be declared as a TTranslateString (and > not as String). To avoid misunderstanding and make things clear: This means, that every normal 'string' property will not be auto translated by the LCL and the IDE won't auto create a po entry. > When such a property is written, the IDE also generates a constant for > it. Then on loading, the lcl catches those properties and will replace > them with the proper translation. This is done by the setting the LRSTranslator. An example for a default translator is installed by using the unit DefaultTranslator. Hmm, this unit should be renamed to LDefaultTranslator or LCLDefaultTranslator to avoid name clashing with other libs. The unit must improved, because it supports only a single .mo file. It should support at least multiple .po files. > However, one problem we had (and there the idea stopped) is how to > unique identify those constants in such way that it is clear on what > instance the constant is used (so that you can translate them). The idea is this: It is assumed that every unit name is unique over all used packages and the project. The unit name of form class is fetched via RTTI. The translator searches the right .po file depending on unit name and search path (it's not yet clear how), loads it and translates the string. We need some thinking about where to store the .po files of 'installed' packages and projects under the various platforms and how to store/retrieve this information. Mattias _______________________________________________ Lazarus mailing list [email protected] http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
