Zitat von Graeme Geldenhuys <graemeg.lists@gmail.com>:

> On 17/03/2008, Marc Weustink <marc.weustink@cuperus.nl> wrote:
> >
> >  Every localizable property will be declared as a TTranslateString (and
> >  not as String).
>
> Ah, I've seen the TTranslateString type around. :)
>
> >  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.
>
> Maybe the IDE is trying to hard. Why not create a Property Editor for
> TTranslateString types. In the Editor the user can specify the
> resource string identifier and default value.
>
> The IDE can then take it from there...
>
> If the user simply typed Text in the OI, no resource string identifier
> is created and it's simply handled as a standard string value.  That
> way, no existing code will be broken (kind-of).

We talked about that. AFAIR it came down to this:
For the biggest part of the TTranslateStrings it is sufficient to use the
package name plus original value as identifier for the lookup. For example all
OkButton captions can use one translation.
But in some cases the 'original' language uses the same value for different
meanings. In these rare cases you need a more specific ID like
packagename.unitname.classname.propertypath.
So, the translate-routine should first lookup the full path and then as fallback
the packagename.originalvalue.
This is not yet implemented nor fully thought through how to achieve this with
.po files. The IDE already collects all translations into one .po file per
package/project.
IMO a property editor is a good idea for an IDE plugin for a translation tool.
Comments are welcome.

Mattias


