On Mon, 29 Jul 2002 23:42:16 +0200, [EMAIL PROTECTED] wrote:
>> > 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).
As I know, resourcesrting is real resource string, but placed to pascal source (like
interface of classes for COM/CORBA, interface not really needed, just for easy writing)
>> >> 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.
For MSG files - no.
> 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.
You are looking from developers point of view. But for user esely don't think about
developer's tools, like linker & rescompiler. For us resource compiler is required, of
couse. If we'll use DLL then _each_ program _must_be_ use DLLs for national language
support. Bad. Very bad.
>> 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.
BTW, in FPC tree can be found direct manipuation with po files, not via any dll. But
anyway gnu msg compiler is required. :)
>> 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.
Right. But for DLL aproach linker & rescompiler (and may be pascompiler) are required.
For MSG aproach only msg compiler is required.
BTW, we (I and Alex Smirnov) have a question. Currently system(sysos2)/syscalls units
uses EMX's syscall interface. This is for EMX target only? For upcoming native
OS/2 (without EMX) target EMXism will be removed? We prefer rewrite system/syscalls
via OS/2 API, not via EMX things.
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe sibyl
end
