[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Iterating over variable using AC_DEFINE to get HAVE_FOO_varitem (sim
Re: Iterating over variable using AC_DEFINE to get HAVE_FOO_varitem (similar to AC_CHECK_HEADERS)
Tue, 18 May 2010 12:58:43 +0100
On Monday 17 May 2010 20:44:31 Daniel Leidert wrote:
> > What you are attempting doesn't make much sense to me yet. The
> > whole point of i18n is that the translation files can be
> > maintained independently of the executable, and that a person
> > can install a subset of the compiled .mo files according to
> > their needs.
> The rationale behind is, that the user should be able to choose
> the language from the preferences. Of course it should only
> contain languages shipped with the source/binary. Therefor I would
> like to have something like this
Like Eric, I don't understand your requirement, but with respect, it
does rather seem like you are trying to reinvent the (square) wheel.
Why not just let the user choose his language using the standard
capabilities of the operating system, (i.e. using the LC_* family of
environment variables on POSIX-like systems), and then use catgets
or gettext to handle translations? That way, you don't hard code the
knowledge of which languages are supported into your application; you
get automatic support for whichever language catalogues your end user
chooses to install, without any additional effort on your part.
Of course, if your target is MS-Windows, it doesn't support catgets
or gettext OOTB, and even if you adopt one of the available ports, it
is likely that the user will neither know nor think to set appropriate
LC_* environment variables to control language choice; he/she will more
likely just expect the language choice to come from the settings in the
Windows Control Panel. Once again, I draw from my experience of porting
man for use with MinGW: see http://preview.tinyurl.com/22jtd7x for a
Win32 function, which may be called *before* either catopen() or
bindtextdomain(), to propagate the ISO-639 language code which
corresponds to the CP language setting, via any appropriate
environment variable you specify, to the message catalogue
[*] This is definitely needed with MinGW's implementation of catgets.
I have no experience of using gettext; on MS-Windows, bindtextdomain()
may do a similar look-up internally, if no appropriate environment
variable has been set beforehand.