This is a issue for all commands so maybe Extended Characters is not good.

As described at 
<http://lists.samba.org/pipermail/samba-technical/2003-September/047231.html> ,
<http://lists.samba.org/pipermail/samba-technical/2001-August/015664.html>
<http://lists.samba.org/pipermail/samba-technical/2001-August/015669.html>

Maybe we need to disscuss the messege catalog system for commands again.

=====
> >I think $prefix/swat/lang is a better place for the msg files than
> >$prefix/lib.
> 
> 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.

<http://lists.samba.org/pipermail/samba-technical/2001-August/015664.html>
<http://lists.samba.org/pipermail/samba-technical/2001-August/015669.html>
 
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
commands.