[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simple gettext-using program fails
|
From: |
Bruno Haible |
|
Subject: |
Re: Simple gettext-using program fails |
|
Date: |
Thu, 6 Apr 2006 13:48:30 +0200 |
|
User-agent: |
KMail/1.5 |
cj p. wrote:
> <html><head><style type="text/css">body{font:12px
Hello,
Please when writing to a public mailing list, set your mailer to send plain
text mails, not HTML mails.
The attached, very simple, gettext-using program fails to
> translate a message on my system. Details about my system are included. The
> program compiles without warnings or errors, but it does not translate the
> message.
> I have the following questions:<br><br>* Can you provide a
> list of "what could be wrong if gettext doesn't translate"?
You find this checklist in the FAQ at
http://www.haible.de/bruno/gettext-FAQ.html
in particular the question
"My program compiles and links fine, but doesn't output translated strings."
> Can you find out what is wrong?
See the section "Triggering `gettext' Operations" in the GNU gettext
manual:
The initialization of locale data should be done with more or less the
same code in every program, as demonstrated below:
int
main (int argc, char *argv[])
{
...
setlocale (LC_ALL, "");
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
...
}
PACKAGE and LOCALEDIR should be provided either by `config.h' or by
the Makefile. For now consult the `gettext' or `hello' sources for
more information.
The use of `LC_ALL' might not be appropriate for you. `LC_ALL'
includes all locale categories and especially `LC_CTYPE'. This later
category is responsible for determining character classes with the
`isalnum' etc. functions from `ctype.h' which could especially for
programs, which process some kind of input language, be wrong. For
example this would mean that a source code using the c, (c-cedilla
character) is runnable in France but not in the U.S.
Some systems also have problems with parsing numbers using the
`scanf' functions if an other but the `LC_ALL' locale is used. The
standards say that additional formats but the one known in the `"C"'
locale might be recognized. But some systems seem to reject numbers in
the `"C"' locale format. In some situation, it might also be a problem
with the notation itself which makes it impossible to recognize whether
the number is in the `"C"' locale or the local format. This can happen
if thousands separator characters are used. Some locales define this
character according to the national conventions to `'.'' which is the
same character used in the `"C"' locale to denote the decimal point.
So it is sometimes necessary to replace the `LC_ALL' line in the
code above by a sequence of `setlocale' lines
{
...
setlocale (LC_CTYPE, "");
setlocale (LC_MESSAGES, "");
...
}
On all POSIX conformant systems the locale categories `LC_CTYPE',
`LC_MESSAGES', `LC_COLLATE', `LC_MONETARY', `LC_NUMERIC', and `LC_TIME'
are available. On some systems which are only ISO C compliant,
`LC_MESSAGES' is missing, but a substitute for it is defined in GNU
gettext's `<libintl.h>'.
In other words, setlocale(LC_MESSAGES, ...) is not enough, because it will
leave the LC_CTYPE locale facet set to "C".
Bruno