From: "Yuri Prokushev" <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Date sent: Mon, 22 Jul 2002 22:24:50 -0400 (EDT)
Priority: Normal
Subject: Re: [Sibyl] NLS
Send reply to: [EMAIL PROTECTED]
> > 2) I propose to use resourcestrings stored in DLLs (dynamically
> >loaded, of course).
> And now required at least resource compiler and linker.
Resourcestrings don't necessarily have to be placed in real .RES, in
fact (as shown with current FPC implementation of resourcestrings -
admittedly, I don't really know if they're somehow different from
normal strings currently).
> >> Disadvantages:
> >> 1) msg compiler required to make locales
> > Not really good, IMHO.
> But for your approach required linker and resource compiler.
Linker is needed anyway. Regarding resource compiler - well, this
one is _not_ really needed, at least not in the beginning (for this,
at least). However, we'll need resource compiler later anyway as well
- how would you store e.g. icons, bitmaps, etc., otherwise? OTOH,
creating a resource compiler shouldn't be that hard hopefully.
> But really I prefer gnu gettext method, but I don't want use
> intl(libintl, gnuintl) lib.
I fully agree here - adding a dependancy on libintl, etc., wouldn't
be good.
> I prefer to have english (international)
> messages stored into executable and, as optional, external message
> files. Native msg files allows to use as external as binded message
> files (refer to os2tk).
The same is true for resourcestrings, in fact.
Tomas
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe sibyl
end
