Bug 663900

Despite it be a i18 bug, It seems to need some fix from initscript.

Thanks for your report.


--
Fedora Bugzappers Team

I suspect systemd is starting gettys in the system locale; earlier inits did not set the locale for their child processes.

Hmm, I would argue that systemd is doing the right thing here by passing the locale env to getty/login. Ad that getty/login is doing the wrong thing when it gets these env vars passed.

It seems login should not translate some strings it currently translates. Reassigning to login/util-linux.

The 'password' prompt may be coming from PAM.

I'm sorry, but the prompt is translated and will stay translated in the PAM modules. The PAM modules do not know (well they can find out the service but it does not make any sense to query it for this purpose) which environment they are running in and other applications might well expect to get the strings translated. So the locale env variables should be unset in getty probably.

Skipping translation of only some strings is not an correct fix - and it would be a regression for non-English locales that can be displayed correctly.

The problem is not application-specific - the Linux console can not display all required glyphs.  Thus the locale should not ever be set one of the far Eastern locales for any process running on the console in in the first place.

See what /etc/profile.d/lang.sh is doing (at least on F14).  Whatever process sets the locale for the getty/login/shell process subtree running on the console needs to do something similar.

Well, we can definitely reset LANG explicitly for the gettys we spawn. That way things will work again as they always did. That will ensure that the prompts are in english again, which is good for indian languages -- but is not that great for languages using latin letters.

i.e. this way because the console cannot do indian letters we'd be unable to show "Kennwort:" instead of "Password:" for de_DE. Not ideal either.

Again, see what /etc/profile.d/lang.sh does.

Note that agetty(8) and  login(1) use locales. The originally used mingetty(8) is without locale support.

(In reply to comment #8)
> Again, see what /etc/profile.d/lang.sh does.

Well, lang.sh doesn't look right to me. i.e. log in on the console with indian locale, then lang.sh will fix this for you. But, then connect from there via ssh to another machine which also uses indian locale. You'll get indian chars from the other machine because TERM is passed on via ssh, but LANG isn't, and the tty type will not be vt but pty.

So, if we do care about proper localization for getty/login, then at some place we'd have to do the logic from lang.sh (but with the problem i pointed out above fixed) and that logic would need to run somwhere as part of getty/login so that its effect are visible in getty/login already. 

Karel, what's your opinion about adding this ugly hack to agetty?

The right fix of course would be to introduce some mechanism which could tell gettext/glibc/whatever to use UTF8 on the console, but avoid the indian chars or so.

I will now unset LANG before spawning getty. That's the short term fix. Given that console is crufty anyway maybe that's simply where we should leave things and then forget about them.

systemd git now unsets all locale settings when spawning a getty on the console. This should fix the immediate problem. I will now reassign this to util-linux as RFE in the hope that agetty maybe can be extended with a local blacklist of some sorts (for example /etc/vtlocale.blacklist), that patches the locale iff it is run on the console and the locale is set to one of the indian languages. Such fixup code will always be ugly, but if we do it we probably should do it as part of the initializaiton of getty (and not later, post-login), so that getty itself can be translated.

There are two separate locales.

* Locale used in the login process.  This uses the system locale.  I don't really have an opinion about whether this should be set in systemd or in *getty.

* Locale used in the session after login.  This is a _per-user_ setting (~/.i18n), and I don't see much reason to handle this in the privileged *getty process - having it in profile.d/lang.sh is quite fine IMHO, and it handles all login methods.  The ssh problem from comment #10 remains, but that's neither here or there - if the profile.d/lang.sh functionality were moved to *getty, it should also be provided inside sshd, and the lack of information applies to sshd just as well as to profile.d/lang.sh.

(In reply to comment #12)
> There are two separate locales.
> 
> * Locale used in the login process.  This uses the system locale.  I don't
> really have an opinion about whether this should be set in systemd or in
> *getty.

Actually... To the extent systemd can write status or error messages to the Linux console, systemd itself should, eventually, also set the system locale and do the filtering (because, eventually, the messages should support translation).

I still can't see a clear reason to "logically" place the responsibility for filtering the locale should be to systemd or to the various programs that use the console (i.e. should getty set the locale and filter it, and should gdm set the locale and not filter it, or should both be handled by systemd?) - but if the code needs to exist inside systemd anyway, placing the responsibility with systemd would probably result in the simplest design.

I.e. systemd would be responsible for setting locales for services it starts, and could be configured to filter it for services that use the Linux console.  None of the system-wide daemons would care about /etc/sysconfig/i18n, parsing it, or worry about filtering the data.

Ideally it should be possible to share the locale filtering code between systemd and profile.d/lang.sh (e.g. a script that gets the L* environment variables on stdin and outputs filtered settings on stdout), but that's probably just too much bike shedding from me.

just small update - languages includes Indian + CJK (Asian) and
bug #652513 (need some exception to have LANG=en_US in grub.conf for CIJK) can be reference

This issue should be duplicate of Bug #652513.

*** This bug has been marked as a duplicate of bug 652513 ***

Reopening. The discussion here is not closed and the other bug is not too informative.

Any updates on the dicsussion? if it's a bit hard to get this fixed in f15 time frame, I'd like to push a workaround in grubby for this issue though. I'm pretty sure getting rid of LANG or set non-CJKI locales to LANG in the kernel parameter helps for this at least.

I don't see this issue on f15 alpha anymore. in /etc/systemd/getty.target.wants/getty@tty?.service:


# Unset locale for the console getty since the console has problems
# displaying some internationalized messages.
Environment=LANG= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY= LC_MESSAGE= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE= LC_MEASUREMENT= LC_IDENTIFICATION=

Is that a fix for this issue right?

If so, shouldn't it include LC_ALL as well?

if there are any way to give it a process, right.

(In reply to comment #18)
> I don't see this issue on f15 alpha anymore. in
> /etc/systemd/getty.target.wants/getty@tty?.service:
> 
> 
> # Unset locale for the console getty since the console has problems
> # displaying some internationalized messages.
> Environment=LANG= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY=
> LC_MESSAGE= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE= LC_MEASUREMENT=
> LC_IDENTIFICATION=
> 
> Is that a fix for this issue right?

Yes, it should be.

(In reply to comment #19)
> If so, shouldn't it include LC_ALL as well?

systemd will never set LC_ALL itself, since that is mostly an environment variable mostly useful to override the normal settings you do with LANG and the other LC_xxx variables. Since systemd won't set this var we hence don't need to unset it in the getty.

(In reply to comment #21)
> (In reply to comment #18)
> > I don't see this issue on f15 alpha anymore. in
> > /etc/systemd/getty.target.wants/getty@tty?.service:
> > 
> > 
> > # Unset locale for the console getty since the console has problems
> > # displaying some internationalized messages.
> > Environment=LANG= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY=
> > LC_MESSAGE= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE= LC_MEASUREMENT=
> > LC_IDENTIFICATION=
> > 
> > Is that a fix for this issue right?
> 
> Yes, it should be.

Thanks. let's close this or change the bug status to MODIFIED at least then :)
changing to MODIFIED so far. that would be better if confirming by someone else as well.

Looks good to me too.  Thanks!