After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 654017 - tests: fix glib_translations_work() in gsettings unit test
tests: fix glib_translations_work() in gsettings unit test
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gsettings
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Allison Karlitskaya (desrt)
gtkdev
Depends on:
Blocks:
 
 
Reported: 2011-07-05 14:55 UTC by Tim-Philipp Müller
Modified: 2011-07-11 04:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
fix glib_translations_work() (807 bytes, patch)
2011-07-05 14:55 UTC, Tim-Philipp Müller
none Details | Review
tests: fix glib_translations_work() (1.13 KB, patch)
2011-07-05 17:31 UTC, Tim-Philipp Müller
committed Details | Review
tests: fix glib_translations_work() (1.13 KB, patch)
2011-07-11 04:09 UTC, Matthias Clasen
committed Details | Review

Description Tim-Philipp Müller 2011-07-05 14:55:51 UTC
Created attachment 191325 [details] [review]
fix glib_translations_work()

make check fails for me like this:

  /gsettings/l10n:                                                     **
ERROR:gsettings.c:646:test_l10n: assertion failed (str == "Unbenannt"): ("Unnamed" == "Unbenannt")
FAIL

Looks like this is because I don't have the necessary bits for the 'de' locale set up, so setlocale (LC_MESSAGES, "de"); fails.

The function glib_translations_work() seems to try and check for that but fails at that, because it makes some assumption about what dcgettext() returns.

In my case the string pointers are different, but still contain the same english language string, so the check yields a false positive.
Comment 1 Matthias Clasen 2011-07-05 15:31:38 UTC
I wouldn't call that an assumption, really.
dcgettext(3) says:

RETURN VALUE
       If a translation was found in one of the specified catalogs, it is con‐
       verted  to  the  locale's codeset and returned. The resulting string is
       statically allocated and must not be modified or freed. Otherwise msgid
       is returned.


In any case, we clearly cannot make the test robust for any combination of uninstalled locales, LANGUAGE/LANG/LC_MESSAGES settings, etc. 

We should probably just state more clearly what the requirements for running 'make check' are.
Comment 2 Tim-Philipp Müller 2011-07-05 15:49:12 UTC
> I wouldn't call that an assumption, really.
> dcgettext(3) says:
> 
> RETURN VALUE
>        If a translation was found in one of the specified catalogs, it is con‐
>        verted  to  the  locale's codeset and returned. The resulting string is
>        statically allocated and must not be modified or freed. Otherwise msgid
>        is returned.

Agreed, I think my guess as to what the problem is was simply wrong.

I think what's happening may be that it does find a translation, only that that is from the current locale, which is "en_GB" in my case, since the previous setlocale() call failed.

So maybe it would be more correct to simply check the return value of setlocale() for NULL and return FALSE if that fails.


> In any case, we clearly cannot make the test robust for any combination of
> uninstalled locales, LANGUAGE/LANG/LC_MESSAGES settings, etc. 

It's an easy and correct fix, so why not fix it?


> We should probably just state more clearly what the requirements for running
> 'make check' are.

That seems unnecessarily unhelpful to me in this case, when a fix is so easy.
Comment 3 Matthias Clasen 2011-07-05 16:02:54 UTC
(In reply to comment #2)

> So maybe it would be more correct to simply check the return value of
> setlocale() for NULL and return FALSE if that fails.

Sounds like a better idea, but does it return NULL in your case ?
Comment 4 Tim-Philipp Müller 2011-07-05 17:31:24 UTC
Created attachment 191333 [details] [review]
tests: fix glib_translations_work()

> Sounds like a better idea, but does it return NULL in your case ?

It does. New patch attached.
Comment 5 Matthias Clasen 2011-07-11 00:26:56 UTC
Review of attachment 191333 [details] [review]:

Looks good.
Comment 6 Matthias Clasen 2011-07-11 04:09:05 UTC
The following fix has been pushed:
7654a84 tests: fix glib_translations_work()
Comment 7 Matthias Clasen 2011-07-11 04:09:11 UTC
Created attachment 191674 [details] [review]
tests: fix glib_translations_work()

If setlocale() to our test locale fails, translations
won't work either.