Description of problem: The virtual console doesn't have any font for CJK and my understanding is that it won't happen any time in the near future either. How reproducible: every time Steps to Reproduce: 1. Set system or user locale to ja_JP.UTF-8 in (/etc/sysconfig/i18n or ~/.i18n) 2. Login to virtual console 3. $ date 4. $ ls --help 5. etc, etc Actual results: White boxes instead of Japanese text. Expected results: Japanese text, but failing that falling back to LANG=C say would be much better.
Created attachment 99396 [details] Patch to fallback to C locale for CJK in vt interactive shell
C is bad, as you drop UTF-8. en_US.UTF-8 is probably better. But getting a better virtual console is the right fix. :)
What is you then launched something like bterm? You'd have to change the env vars back to the ja ones?
Bill, en_US.UTF-8 is fine. :) Adrian, the above patch works fine with kon2. It doesn't seem to work right with bterm though for some reason (in fc1 at least - I can't test in fc2, since it segfaults (cf bug 113910). [Btw why doesn't PS1 get set when bterm starts?]
comment 4: I can modify bterm to set PS1. bterm was originally put in as a quick hack to do CJK UTF-8 in text mode. I imagine the shell that bterm launches needs to be passed the "interactive" flag and that would setup PS1 and other needed variables.
WHy is the check for PS1 there anyway?
To check that it is an interactive shell. :) Perhaps there is a better way of doing that? Otherwise init runs in the fallback locale too...
Hm. But, really... do you *ever* want to run an app in CJK locale on a VT?
Well for me falling back by default on a vt for interactive shells for CJK is ok. Except for kon and bterm I can't think of any way to display CJK on vt's. (We definitely don't want to fallback for non-interactive shells.)
However I noticed that with the patch startx goes into the fallback locale (like bterm) does: though "LANG=ja_JP.UTF-8 startx" works. :)
Comment 8: the people that like to run CJK on the VT are people with low power machines that aren't meaty enough for X. And it's a question of equality-- if you can do it in English, you should be able to do it in CJK, so the rational goes. I guess if you're doing server maintennance on the console and you /must/ edit a non-English text file, to try to think of a realistic example. But I'm stretching.
Is this still relevant, or is this fixed?
Still happens with rawhide.
NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing status to ASSIGNED for ENG review.
(In reply to comment #9) > (We definitely don't want to fallback for non-interactive shells.) Actually it would be better if Asian locale could also be supressed when booting until rhgb starts. But perhaps that could be handled separately by the init system? I think the basic idea of the original patch is still good. Is there a more elegant approach?
Created attachment 138745 [details] lang.sh.patch updated patch against current lang.sh
Here's a better version. Improvements: - handles the non-UTF-8 case - doesn't override en_IN - catches tcsh as well Bugs remaining, may not be sanely fixable: - If you have ja_JP.eucjp, zh_CN.gb18030, we will end up changing the effective charset.
Created attachment 138805 [details] patch for this issue
Thanks. Should I open a separate bug for the boot message problem?
> - If you have ja_JP.eucjp, zh_CN.gb18030, we will end up changing the effective > charset. I don't think that is a big problem. It would probably be good to test the bogl too. Another case that is harder to catch: ssh from a VC.
I didn't see a boot message problem in initial testing.
Well it is really only the date setting line which still shows white boxes for me. A detail, but it would be nice to get rid of them finally.
I tested bogl and since it doesn't use a login shell the locale is the same as on the console, but I think the functionality of the patch is good enough.
Created attachment 138870 [details] lang.sh.patch2 Maybe this is simpler for maintenance.
Hm, possibly, although it's already committed to CVS in the prior version. :) For the date, it's being done through a pipe. It can be changed to LANG=$LANG date... which breaks all the translations. That's sed-able, though.
Well, except for the part where LANG=$LANG date doesn't work right. :)
Fixed in CVS, will be in 8.46-1, potentially 8.45.4-1.
initscripts-8.45.4-1 has been pushed for fc6, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
I realised yesterday that the change seems to affect gdm's GUI: ie it comes up in English now for CJKI locale.
initscripts-8.45.5-1 has been pushed for fc6, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
Any comments on comment 31 or am I way off?
A change was added for that.