Good location for *.msg files for swat i18n?
tpot at samba.org
Tue Sep 23 05:55:31 GMT 2003
On Tue, Sep 23, 2003 at 12:18:58PM +0900, TAKAHASHI Motonobu wrote:
> >I've updated bug #456 with a few ideas:
> >Step #1 is to move the msg files from source/po to swat/lang. I don't
> >think it's appropriate for them to be in the source directory.
> >Step #2 (patch in bugzilla) is to modify the installswat script to
> >install the msg files from swat/lang to $prefix/swat/lang/$ln/$ln.msg
> >where $ln is the browser's preferred language. A small modification to
> >lang_tdb.c is required here.
> >I think $prefix/swat/lang is a better place for the msg files than
> For SWAT, I think it's OK and go ahead.
> But remember that d_printf() is used by commands, though I think
> commands should use local message catalogue system:
Doh. I forgot about this bit. I think the swat i18n files could
be kept separately for the moment maybe.
> I will post this issue (how to fix message catalogue for commands) to
> bugzilla as another problem than SWAT.
> This issue is minor and is not needed to be fixed until Samba 3.0.0.
> |I recommend that
> | 1. Samba internal message catalogue system for SWAT
> | Indeed GNU gettext() is used in Samba Japanese Edition, but is
> | not the essential matter. We can use another product regardless
> | of what message catalugue system is used in a platform.
> | 2. a message catalogue system used on the platform for commands
> | Unlike SWAT, the language of Samba command output should be
> | essentially same as that of platform command output.
> | For example we should be able to change the output language of
> | "ls" command, "smbclient" and other commands of manually
> | installed products at a time.
> Currently message catalogue system for SWAT is implemented with
> d_printf(). d_printf() is also used in commands, but there are no
> message catalogue for them and no call for init_lang_tdb() so the
> d_printf()s are indeed equal to printf().
Also the lang_tdb code creates a file in the Samba locks directory which
is not necessarily going to be writable by whoever runs the client
More information about the samba-technical