International Samba (fwd)

[John E. Malmberg]

I have added the Samba-vms mailing list to this thread because I
must confess to being totally ignorant of internationalization issues
as it pertains to SAMBA on OpenVMS, and what current practice is.

I also have not done much with this topic in general, other than to
put some additional code in the filename translation code and command
files to not assume what the native OpenVMS directory delimiters are.

One of the methods that OpenVMS uses is for a program to have all of it's
status messages, prompts and such in a separate shared image.  This can
be bound to the active program through a logical name.  (UNIX would use a
symlink for this).

The messages are in a format that is like the string constant in a sprintf
statement, so that the program can insert variables in them.  Of course
some of those insertions may impose some grammar problems in some
languages.

In addition, the status messages have a tag, with a corresponding number.
The tag and number can be tied to a more detailed and again country
specific help message library.

For example:  A program exits with status 0000012, which has the facility
code of 0 for a SYSTEM error message, and a code of 12 which together
map to the tag ACCVIO.  This message also takes some parameters that
indicate where and why the problem occurred.

Requesting HELP/MESSAGE ACCVIO will give a short text on interpreting
the error message, and suggest corrective actions.


On the downside, this can tend to make the code less readable and
dependent on programmers comments, as there tends to be less string
constants in the code.

If SAMBA had the messages it generates structured in this way, an OpenVMS
program might be able to automatically translate them to use the native
OpenVMS facilities.

Realistically, just as SAMBA can only really support an operating system
as long as a programmer for that platform is actively testing the current
builds, a language can only be supported if it has someone that knows it
maintaining the documentation.  I am not aware of any opensource language
translators or of even commercial ones that are reliable enough for
technical documentation.

I have had some success in automatically converting the man pages in
rsync in to OpenVMS Digital Standard Runoff format, for production of
both printable manuals and Help libraries.

The same tools should not care what language the documents are that they
are converting.

-John
wb8tyw at qsl.network
Personal Opinion Only

On Fri, 10 Aug 2001, Rafal Szczesniak wrote:

> On Fri, 10 Aug 2001, Tim Potter wrote:
> 
> > Rafal Szczesniak writes:
> >
> > > It seems, nobody is interested in this issue... ;-)
> >
> > Not true, it's just a really hard task.
> >
> (...)
> >
> > Isn't there internationalisation support as part of the GNU man
> > package?  I notice the russian linux manual pages have their own
> > subdirectory under /usr/share/man rather than having a language
> > suffix.
> >
> > /usr/share/man/ru/man1
> > /usr/share/man/ru/man1/a2p.1.bz2
> > /usr/share/man/ru/man1/a2ps.1.bz2
> > /usr/share/man/ru/man1/apropos.1.bz2
> > /usr/share/man/ru/man1/ar.1.bz2
> > /usr/share/man/ru/man1/arch.1.bz2
> > /usr/share/man/ru/man1/as.1.bz2
> > /usr/share/man/ru/man1/at.1.bz2
> > /usr/share/man/ru/man1/basename.1.bz2
> > /usr/share/man/ru/man1/biff.1.bz2
> >
> > I expect some systems will not support this layout so it may be
> > necessary to use your system suggested above as well.
> 
> That's right. I've looked into "man man" and found some
> informations, but I guess not each platform Samba supports
> (it's quite a big list) has GNU man package installed.
> This makes neccessary recognizing which platform we are
> dealing with, essentially whether or not the GNU man is
> installed.
> Anybody knows how the other Samba supported platforms, like
> HPUX, OpenVMS, IRIX, etc. approach to the international
> software ?
> 
> >
> > > The second one is to symlink the default language filename
> > > to a filename without language specifier. It'd look like
> > > this:
> > >   smb.conf -> smb.conf.en
> >
> > Hmm - I first thought this was a bad idea but with the right
> > infrastructure it could be quite good.  I think param/loadparm.c
> > will need to be gettext()ified for this to work nicely.
> >
> > Or were you thinking of the default language for the man pages -
> > I was thinking of internationalising the smb.conf parameter
> > names.  Perhaps another project.
> 
> Well ... I was afraid it could be interpreted in this way.
> Internationalising the parameter names is something I'd
> rather be very careful of. I'm afraid it would introduce
> much unneccessary confusion...
> Instead, I was also thinking about international messages
> (do not confuse it with logfiles, this would be almost
> impossible) like displayed after issuing "smbclient -h"
> (or "help" on smbclient cmd prompt).
> 
> > If you use LANG=ru (or whatever) man should automatically pick up
> > internationalised verions of manual pages where available.
> >
> (...)
> >
> > I'm a bit worried about how these would be kept up to date given
> > that we only have a couple of people working on the English
> > documentation let alone other languages.
> 
> I have no illusions. It will be impossible to have each
> language version up to date all the time. My (polish)
> versions already needs work after a few changes in 2.2.1 and
> new Jerry's parameter "lanman printing only" (or sth like
> this...). Fortunately, once translated (the big job, I can
> assure you ;-) ), documentation requires much much less work
> on maintenace.
> Another problem is how to translate them to other languages
> (like french, german, perhaps spanish ...). Or rather, how
> to gain volunteers for this task ... It will be very long
> term process.
> 
> 
> cheers,
> 
> Rafal 'Mimir' Szczesniak <mimir at spin.ict.pwr.wroc.pl>   |
> *BSD, Linux and Samba                                  /
> ______________________________________________________/