On 08/19/07 14:57, Klaus Schmidinger wrote:
> On 08/19/07 12:43, Anssi Hannula wrote:
>> Anssi Hannula wrote:
>>> Luca Olivetti wrote:
>>>> En/na Anssi Hannula ha escrit:
>>>>
>>>>> Note that KDE does provide the user a list of languages, but it does not
>>>>> use gettext, but instead uses its own glibc-derived implementation for
>>>>> translation, with file format being the same.
>>>> [...]
>>>>>> Isn't there perhaps a way to tell gettext *explicitly* which files
>>>>>> to use, completely bypassing this whole broken setlocale stuff?
>>>>>> In that case VDR could collect it's list of *.mo files and decide
>>>>>> by itself which one to use.
>>>>> I'm not aware of such a way.
>>>> I think that in your message there's the solution: do *not* use gettext
>>>> but use an own implementation. Maybe borrowing kde implementation (which
>>>> is already C++) it's easier than translating the pascal class I proposed
>>>> before (or maybe not ;-).
>>> Actually, it seems KDE 4 uses real gettext to do it, and uses the
>>> following code:
>>>
>>> // Point Gettext to new language.
>>> setenv("LANGUAGE", language, 1);
>>>
>>> // Locale directories may differ for different languages of same
>>> catalog.
>>> bindtextdomain(name, localeDir);
>>>
>>>
>>> Maybe just using 'setenv("LANGUAGE", "de", 1);' will do what we want,
>>> without need for setlocale()? :)
>>>
>>> I have to go now so I can't check that yet.
>> I tested anyway ;)
>>
>> It seems that it *does* work, i.e. LANGUAGE=de, LANGUAGE=fr, LANGUAGE=fi
>> will work even if there is no such locale at all.
>>
>> I copied a .mo file into /usr/share/locale/testtest/LC_MESSAGES/, which
>> certainly is not a valid locale, and using LANGUAGE=testtest it was
>> correctly used! :)
>
> Looks good. However, after some tests it would appear as if only the
> very first setenv() call actually changes anything. Subsequent calls
> have no further effect, and gettext() always returns the language
> that was selected in the very first call to setenv().
Apparently it is necessary to do a textdomain("vdr") call after the
setenv(). The bindtextdomain() call doesn't have any noticeable effect
here.
Please test the attached patch. It scans the LOCDIR directory as before,
but checks for the existence of a vdr.mo file and then uses setenv()
instead of setlocale().
This should work for VDR itself. For plugins I need to do more work.
But first let's see whether others can confirm that this works for VDR.
Klaus
--- i18n.c 2007/08/12 12:15:29 1.308
+++ i18n.c 2007/08/19 13:20:52
@@ -23,6 +23,7 @@
#include <ctype.h>
#include <libintl.h>
#include <locale.h>
+#include <unistd.h>
#include "tools.h"
// TRANSLATORS: The name of the language, as written natively
@@ -101,9 +103,13 @@
if (Locales.Size() > 0) {
dsyslog("found %d locales in %s", Locales.Size(), I18nLocaleDir);
char *OldLocale = strdup(setlocale(LC_MESSAGES, NULL));
+ setlocale(LC_MESSAGES, "");
for (int i = 0; i < Locales.Size(); i++) {
- if (i < I18N_MAX_LANGUAGES - 1) {
- if (setlocale(LC_MESSAGES, Locales[i])) {
+ cString FileName = cString::sprintf("%s/%s/LC_MESSAGES/vdr.mo", I18nLocaleDir, Locales[i]);
+ if (access(FileName, F_OK) == 0) { // found a locale with VDR texts
+ if (i < I18N_MAX_LANGUAGES - 1) {
+ setenv("LANGUAGE", Locales[i], 1);
+ textdomain("vdr");
if (strstr(OldLocale, Locales[i]) == OldLocale)
CurrentLanguage = LanguageLocales.Size();
LanguageLocales.Append(strdup(Locales[i]));
@@ -117,11 +123,13 @@
}
LanguageCodes.Append(strdup(Code));
}
+ else {
+ esyslog("ERROR: too many locales - increase I18N_MAX_LANGUAGES!");
+ break;
+ }
}
- else
- esyslog("ERROR: too many locales - increase I18N_MAX_LANGUAGES!");
}
- setlocale(LC_MESSAGES, OldLocale);
+ setenv("LANGUAGE", LanguageLocales[CurrentLanguage], 1);
free(OldLocale);
}
// Prepare any known language codes for which there was no locale:
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
