[srvx-devel] Re: [srvx-commits] CVS: services ABOUT-NLS,NONE,1.1 Makefile.am,1.12,1.13 aclocal.m4,1.12,1.13 autogen.sh,1.4,1.5 configure.ac,1.7,1.8

[Entrope <en...@us...>]

Hm, I hadn't really thought about localizing them on a per-user basis.
But that would be easy enough to do -- gettext(), which is the
(standard) interface I plan to use, has a function that lets you
specify a particular language to use.  The I18N library backend will
then figure out the closest available match and use it:

  char *xlated;
  xlated = dgettext(handle->pref_lang, orig_text);

This could be dropped in somewhere at the equivalent of helpfile.c.

The reason I used CSMSG_FOO_BAR in the first place was to try to make
it easier to do I18N.  It turns out that the GNU way of doing it, by
putting _() or N_() around translatable strings, is easier and more
flexible -- at least if the string is only used once.

-- Entrope

Adrian Dewhurst <dew...@ed...> writes:

> You know, I was thinking about I18N a week ago... thanks for the commits
> to remind me
> 
> With all the CSMSG_*, etc defines, think it would be feasible to make the
> language choosable by an authserv handle setting? Just a thought. Here's
> one method I thought might do it:
> 
> The defines convert to numeric values. There are arrays of messages for
> each language, and it uses lang_english[CSMSG_FOO_BAR]... the command that
> does the sending of messages takes the authserv info struct from the user
> it's to be sent to and decides the language to use from there... if there
> is no handle, it uses the default (via srvx.conf, naturally).
> 
> I actually can see large problems in using an array, but it'd be the
> fastest, and easiest to explain... in practice, another method would
> probably be required, though it gets the idea across. I do think I18N
> support in srvx would require it to be per-user and not
> per-network/process in order to be very useful. Myself, I could assist
> with French translations, though they would be far from perfect. We'd also
> need separate help files.
> 
> I was too lazy to look up the srvx devel list address before I go to sleep
> tonight, so if you don't mind forwarding it to the list address, then feel
> free to do so ;-)