summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 0b87941)
raw | patch | inline | side by side (parent: 0b87941)
author | Ævar Arnfjörð Bjarmason <avarab@gmail.com> | |
Sun, 29 Aug 2010 17:23:38 +0000 (17:23 +0000) | ||
committer | Ævar Arnfjörð Bjarmason <avarab@gmail.com> | |
Sat, 30 Oct 2010 07:10:06 +0000 (07:10 +0000) |
Change the gettext setup code to arrange for messages to be emitted in
the user's requested encoding, but avoid setting LC_CTYPE from the
environment for the whole program.
In 107880a I removed our use of setlocale(LC_CTYPE, "") because of a
bug in vsnprintf in the GNU C Library [1].
Even if it wasn't for that bug we wouldn't want to use LC_CTYPE at
this point, because it'd require auditing all the code that uses C
functions whose semantics are modified by LC_CTYPE.
But only setting LC_MESSAGES as we do creates a problem, since we
declare the encoding of our PO files[2] the gettext implementation
will try to recode it to the user's locale, but without LC_CTYPE it'll
emit something like this on 'git init'
Bj? til t?ma Git lind ? /hl/agh/.git/
Gettext knows about the encoding of our PO file, but we haven't told
it about the user's encoding, so all the non-US-ASCII characters get
encoded to question marks.
But we're in luck! We can set LC_CTYPE from the environment only while
we call nl_langinfo and bind_textdomain_codeset. That suffices to tell
gettext what encoding it should emit in, so it'll now say:
Bjó til tóma Git lind í /hl/agh/.git/
And the equivalent ISO-8859-1 string will be emitted under a
ISO-8859-1 locale.
With this change way we get the advantages of setting LC_CTYPE (talk
to the user in his language/encoding), without the major drawbacks
(changed semantics for C functions we rely on).
However foreign functions using other message catalogs that aren't
using our neat trick will still have a problem, e.g. if we have to
call perror(3):
#include <stdio.h>
#include <locale.h>
#include <errno.h>
int main(void)
{
setlocale(LC_MESSAGES, "");
setlocale(LC_CTYPE, "C");
errno = ENODEV;
perror("test");
return 0;
}
Running that will give you a message with question marks:
$ LANGUAGE= LANG=de_DE.utf8 ./test
test: Kein passendes Ger?t gefunden
In the long term we should probably see about getting that vsnprintf
bug in glibc fixed, and audit our code so it won't fall apart under a
non-C locale.
Then we could simply set LC_CTYPE from the environment, which would
make things like the external perror(3) messages work.
1. http://sourceware.org/bugzilla/show_bug.cgi?id=6530
2. E.g. "Content-Type: text/plain; charset=UTF-8\n" in po/is.po
Suggested-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
the user's requested encoding, but avoid setting LC_CTYPE from the
environment for the whole program.
In 107880a I removed our use of setlocale(LC_CTYPE, "") because of a
bug in vsnprintf in the GNU C Library [1].
Even if it wasn't for that bug we wouldn't want to use LC_CTYPE at
this point, because it'd require auditing all the code that uses C
functions whose semantics are modified by LC_CTYPE.
But only setting LC_MESSAGES as we do creates a problem, since we
declare the encoding of our PO files[2] the gettext implementation
will try to recode it to the user's locale, but without LC_CTYPE it'll
emit something like this on 'git init'
Bj? til t?ma Git lind ? /hl/agh/.git/
Gettext knows about the encoding of our PO file, but we haven't told
it about the user's encoding, so all the non-US-ASCII characters get
encoded to question marks.
But we're in luck! We can set LC_CTYPE from the environment only while
we call nl_langinfo and bind_textdomain_codeset. That suffices to tell
gettext what encoding it should emit in, so it'll now say:
Bjó til tóma Git lind í /hl/agh/.git/
And the equivalent ISO-8859-1 string will be emitted under a
ISO-8859-1 locale.
With this change way we get the advantages of setting LC_CTYPE (talk
to the user in his language/encoding), without the major drawbacks
(changed semantics for C functions we rely on).
However foreign functions using other message catalogs that aren't
using our neat trick will still have a problem, e.g. if we have to
call perror(3):
#include <stdio.h>
#include <locale.h>
#include <errno.h>
int main(void)
{
setlocale(LC_MESSAGES, "");
setlocale(LC_CTYPE, "C");
errno = ENODEV;
perror("test");
return 0;
}
Running that will give you a message with question marks:
$ LANGUAGE= LANG=de_DE.utf8 ./test
test: Kein passendes Ger?t gefunden
In the long term we should probably see about getting that vsnprintf
bug in glibc fixed, and audit our code so it won't fall apart under a
non-C locale.
Then we could simply set LC_CTYPE from the environment, which would
make things like the external perror(3) messages work.
1. http://sourceware.org/bugzilla/show_bug.cgi?id=6530
2. E.g. "Content-Type: text/plain; charset=UTF-8\n" in po/is.po
Suggested-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
gettext.c | patch | blob | history |
diff --git a/gettext.c b/gettext.c
index db99742bc4fc2fcc74d6cb012b22c1e0a8d7b394..8644098b55b89ebbf4e7d19eebde6a879acffde3 100644 (file)
--- a/gettext.c
+++ b/gettext.c
#include "exec_cmd.h"
#include <locale.h>
#include <libintl.h>
+#include <langinfo.h>
#include <stdlib.h>
extern void git_setup_gettext(void) {
char *podir;
char *envdir = getenv("GIT_TEXTDOMAINDIR");
+ char *charset;
if (envdir) {
(void)bindtextdomain("git", envdir);
}
(void)setlocale(LC_MESSAGES, "");
+ (void)setlocale(LC_CTYPE, "");
+ charset = nl_langinfo(CODESET);
+ (void)bind_textdomain_codeset("git", charset);
+ (void)setlocale(LC_CTYPE, "C");
(void)textdomain("git");
}