On Fri, Feb 04, 2000 at 01:11:44AM +0100, [EMAIL PROTECTED] wrote:
> > You seem to want to move the catalogs to the home directorys, which is
> > much worse (one copy for each user is insane).
> But would work....
Just as the other way woudl. But it would save 3MB of space. Given that
many people have a 10-20MB quota this is hardly acceptable, especially
since another solution is available.
> Having multiple domain makes things rather complicated.
That might be. But it's already done, and works.
> And the whole idea would only work as long as the user can write his
> own files which isn't true for multiuser systems - there you've got
> only your homedirectory...
A user can always write his own files.
> > OR can we bind a domain on more than one .mo-file (probably not).
> Hehe, the name of the domain is directly coupled to the filename,
> however it should be possible to use symlinks... :)
"Forking symlinks". IF multiple files don't work then multiple symlinks
> and one catalog... I had something in mind like: cat them together,
> remove the second header and duplicate entires (i.e. entries with the
> same wording)
> :)) using gettext? Marc, I just remembered what you said to me about
> a half year ago: gettext is broken! NOW I believe you, I fear I could
> write buglists which are longer than the source of gettext... growing
Well, it depends on what you are talking about. I talk about supporting
1.2, and there definitely will be no experiments with alternative i18n
packages in 1.2, so yes, gettext is what we will use.
> > So it does not matter wether it's slow to merge catalogs, it matters
> > wether it is possible at all to cleanly install plug-ins later.
> My idea would work, but would cost space....
My idea would work, but would cost no space....
> > Why is that necessary?
> To prevent gettext from not working.
Since gimp currently works exactly that way, I do not buy this...
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |