Chpe, you had an idea on how to implement this ? We need to get it in
before 31. I remember we discussed it but I forgot all details :/

My proposal was to simply add a comment in the source for the
translators. For example, in my en_GB translation, i translate 'System
default' to 'British English (Default)'.
This takes care of the case when there is a transation available for
the user's locale.

Now, in case the user's locale does _not_ have a translation, we still
pick up the two-letter code, but currently the user can't tell that
from the 'System language' string. I thought of using suitable _NL_*
arguments to nl_langinfo, and use that to build the ui string. But the
glibc docs say those _NL_* we'd be interested in are a GNU extension,
so we'd leave out non-GNU systems. Still, could be better than
nothing. What do you think?

Sounds good. As long as we add proper checks for system that doesnt
have  that func ...

Created attachment 18437 [details] [review]
proposed fix, needs portability changes

Looks good. For portability we can just copy glib checks I guess.

So we need to check in the translators comment before July 31.

The translator's comment has been there since before 1.0, but still
almost all translations don't follow it. I think we should file bugs
against translations which don't follow it, and close this bug.
Further work seems like lost time since we will abandon this setting
after 1.2 (see bug 130446).

Comment on attachment 18437 [details] [review]
proposed fix, needs portability changes

Marking obsolete attachments in open bugs.

L10n applet didn't make 2.8, so we still need to deal with this for 1.4.0.
Someone needs to mass-file bugs against translations.

Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o

Fixed in cvs. It now reads like this: "System language [en]".