Tiny Core Linux
General TC => Programming & Scripting - Unofficial => Topic started by: christianix on August 18, 2016, 09:38:51 AM
-
Hi,
I'm building a small program with internationalization support under Ubuntu 14.04 and there it's behaving as expected. I can also build the same tool on TC 7.x without problems. But on TC it's just not looking up the translations.
The source file is attached and can be build with the following Makefile:
CFLAGS=-W -Wall -O0 -g -std=c99
PROGS=\
test-gettext
all: ${PROGS}
%: %.c
$(CC) $(CFLAGS) -o $@ $<
clean:
$(RM) ${PROGS}
The first two steps for translation I did on Ubuntu:
- xgettext -kN_ -d test-gettext -o test-gettext.pot test-gettext.c
- msginit --no-translator -l de -o test-gettext-de.po -i test-gettext.pot
The binary translation file was created on TC (again):
- mkdir -p share/locale/de/LC_MESSAGES
- msgfmt -c -v -o share/locale/de/LC_MESSAGES/test-gettext.mo test-gettext-de.po
I'm using the latest TC 7.x with the following TCEs in onboot.lst:
gcc.tcz
gettext.tcz
mc.tcz
mc-locale.tcz
compiletc.tcz
strace.tcz
gettext-dev.tcz
When I compare the strace (-f -e trace=file) on Ubuntu and TC I see that on Ubuntu it opens the test-gettext.mo file. In TC I don't even see a try to open it.
Any ideas what I am missing?
-
Did you install a German locale first? (via getlocale.tcz)
Just setting LANG=de_DE without installing such wouldn't work. As TC is bare-bones, only the C locale is included by default.
-
I'm not using translated system messages. I also called my locale de. I call my program like this:
> LANGUAGE="de" ./test-gettext
And on Ubuntu I see it opening share/locale/de/LC_MESSAGES/test-gettext.mo with strace. On TC I don't see even a try to open it. So I thing something is going wrong during the build process.
-
You must install a German locale for any app to use it, including yours. Installing one does not change the system's language, merely makes that locale available.
-
I gave it a try. However, when running sudo getlocale.sh (with de_DE/UTF-8 selected) I get:
cannot open locale archive "/usr/lib/locale/locale-archive": Read-only file system
The script creates the archive mylocale.tcz and a corresponding entry in onboot.lst. However the archive contains only:
squashfs-root
squashfs-root/usr
squashfs-root/usr/lib
squashfs-root/usr/lib/locale
squashfs-root/usr/lib/locale/locale-archive
My test program now also tries to open some locale dependent files:
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/de/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
But it's still not looking up the message archive (.mo) required. :-(
-
If things work properly, /usr/lib/locale/locale-archive is a file of +/- 1.5mb.
Maybe you could delete /usr/lib/locale/locale-archive and try "sudo getlocale.sh" again?
-
I removed the mylocale.tcz as suggested (from onboot.lst and in optional), then recreated the locale package again - with only de_DE/UTF-8 locale. Now /usr/lib/locale/locale-archive is indeed something around 1.5 MB. I also recompiled my test program but behaviour is still the same.
Is there some global locale package I'm missing? Or an extra package for libc or gcc?
-
I presume you rebooted with mylocale "onboot" and the boot code analgous to "lang=en_US.UTF-8"?
If so, you could try the intltool, gcc_libs, glibc_add_lib, glibc_apps, glibc_gconv and glibc_i18n_locale extensions.
-
When using de_DE.utf8, you must use that string in LANG. Just trying to use "de" or "de_DE" does not match that one.
To check if your locale env vars are correct, run "locale".
-
Ok, it's working now. Thanks to everybody!
The crucial point is described in this sentence of the man page:
In the "C" locale, ... , the gettext, dgettext and dcgettext functions return msgid.
Which means that the locale must be set to any locale supported by the system but must not be "C". Only then my translations are looked up - even tough I'm defining my own message catalogue and binding. This seems quite weird to me - as many things with the gettext functionality.