Bug 102958

Does CJK mean "Chinese, Japanese, and Korean"?
Aren't there `any` CJK fonts for "Text mode"?

Are you selecting that CJK languages in the Linuxrc?
(Linuxrc: "C/J/K" + "Text mode")

This might be a duplicate of the bug #103007
ENV variable LANG is set to some of those C/J/K but it is supporsed to be empty.

To comment on #1:

Yes, I mean about anything that is bigger than can fit in 8-bit 80x25 mode.
Linuxrc is not called, I only choose some CJK from the _bootloader_, set Text
mode in the _bootloader_ and the next thing that shows up is _YAST_.
I have tried Japanese only, but it should behave the same for C and K.

Jiri, could we show a information popup that the selected locale 
cannot be used for the text mode and continue without  
retranslating the YaST dialogs? 

When you select language in the boot menu, yast2-country don't get the control -
the language dialog is skipped. I don't know who should show the popup...

Jiri, any idea? 

In NCurses, the langugage dialog will always be shown (since Beta2) 

So what you want is something like: 
 
The selected language cannot be used in text mode.  English is used instead. 
 
?? 
 

Extend to: 
 
 
The selected language cannot be used in text mode.  English is used for the 
installation, but the selected language is used for the new system. 
 

minor fix: 
 
The selected language cannot be used in text mode. English is used for  
installation, but the selected language will be used for the new system. 

fixed in yast2-country-2.12.10

Right after the bootloader finished its splashscreen and starts the kernel:
Could not we just change into framebuffer mode and start yast in fbiterm?

Looks like fbiterm actually _is_ used when CJK language is selected in proper
time (bootloader menu or linuxrc).

So english should be used only in some cases.

Steffen, could you confirm?
How is it solved - who starts fbiterm and when?

The yast start scripts fire up fbiterm if textmode is selected and framebuffer 
is active. Actually, if the vga16fb module would not be broken, we could have 
fbiterm even without vesa fb. 
 
But Jan is right. It is probably a good idea to turn on vesa-fb 
if someone selects textmode + weird language. 
 
Though I think this is really a corner-case. 

Corner case? It's for everyone not meeting the memory requirements imposed by the Qt installer.

jsrain: if I understand it correct, we could skip first language dialog every
time the language is already chosen before.

There are three language selections:
- bootloader
- linuxrc
- yast
Maybe I am wrong but if SUSE is ported to more languages, the bootloader popup
menu is so full that there is not enough space on the 1024x768 it does, while
yast and linuxrc uses a flexible listbox method.

Yes, this is definitly the best way: 
 
If language has been chosen from isolinux menu and there is no reason to avoid 
using it, the dialog can be skipped. In this case, inst_language is supposed 
to return `auto (and then the next dialog won't have the Back button enabled). 
 
If you hande it in inst_language, I will be glad to remove the checking 
whether run the dialog or not from installation.ycp. 

If language is chosen before entering YaST (1st and 2nd option from comment
#19), inst_language  could be skipped becuase language could be shown - either
in Qt or with fbiterm. -> jsrain

But user can start textmode installation and change the language in the yast
menu - now inst_language should not allow the translation to CJK and show the
warning -> jsuchome

However, it would be fine if I could get the information that CJK characters
could be shown correctly -> HuHa, would it be possible for UI::GetDisplayInfo ()
to report some difference?

UI::GetDisplayInfo() returns a map that has a key "HasFullUtf8Support" that 
tells you just that. 

Unfortunately that piece of information is not in the UI builtins doc, but the 
GetDisplayInfo.ycp example will list them all. 

OK, that's not it - this tends to return "true" more often than it seems to 
work. 

Mike, please asses if that is a real problem or yet another academic corner 
case. I don't recall any bug reports from China, Japan, or Korea about that. 

I think my proposal from comment #21 covers all significant situations, so I
would go that way (this means: switch to english if we have text mode and
language wasn't selected before starting YaST).

Stefan> I don't recall any bug reports from China, Japan, or Korea about that. 

There were bugreports about that problem both from Novell Japan and
Novell China.

The Text mode install cannot display CJK, therefore the best solution
would be to keep the user interface in English if a Text-mode
installation done and a language is selected which cannot be displayed
in Text-mode. But the package selection and other language specific
stuff should of course be handled correctly for the selected language,
only the user interface should be in English.

Jan> In 9.3, YAST fell back to using non-CJK (English) in the 80x25 case.

I don't think it did that.

I cannot find the old bug reports at the moment.

In the old bugreports, we discussed whether we could use fbiterm
(frame-buffer terminal which can display CJK) to be able to display
CJK during an ncurses installation.

But Steffen Winterfeld convinced us that this is not a good idea
because fbiterm requires a frame-buffer and if a frame-buffer can be
used, you can just as well use a regular installation with the
YaST2-Qt interface.

The text-mode installation is intended as a fallback for machines
where even a frame-buffer is not possible.

I was merely wondering what the point in using ncurses would be if you 
can go for x11 as well. Anyway, using fbiterm worked in 9.3, IIRC. 

>But Steffen Winterfeld convinced us that this is not a good idea
>because fbiterm requires a frame-buffer and if a frame-buffer can be
>used, you can just as well use a regular installation with the
>YaST2-Qt interface.

But what if I simply do not want, or even can use Qt? See the comment about
memory requirements. And I am _convinced_ that fbi+ncurses takes less than
X11+Qt. Requiring a framebuffer is not hard, it's already in the kernel -- if
you choose 640x480 or anything else numeric in the bootloader, you'll get
nothing less than a fb, so the splashes can show.

Wait, please: it looks like you are discussing something that already works.
According to Steffen, fbiterm actually _is_ used for text installation. So in
such case, everything is OK and we don't have to solve anything, right?

Remaining cases:
1. user selects text installation, but language selects in yast, not before.
Thus we don't have fbiterm and have to continue in english. I'm ready to commint
yast2-country enabling this behaviour if nobody complains.

2. user selects text installation, selects the language, but fbiterm cannot be
started for whatever reason. Is _this_ the case we should care about? (mfabian:
isn't this really corner case? snwint: how is it decided?)
If yes, we have to instruct yast some way about this situation, because
currently it is not able to detect the difference from the case 1.

I just talked to Steffen Winterfeld again to refresh my memory about
this old, long bugreport. It is like this:

There are two different ways to do a "text-mode" installation!

Method 1): write "textmode=1" on the kernel command line.

Method 2): choose "Text Mode" at the bottom left of the menu bar of linuxrc.

Method 1) uses framebuffer and fbiterm and CJK works.

Method 2) uses no framebuffer and CJK does not work.

Method 2) is intended as a fallback for machines were using framebuffer
is impossible.

Jiri> Wait, please: it looks like you are discussing something that
Jiri> already works.  According to Steffen, fbiterm actually _is_ used
Jiri> for text installation. So in such case, everything is OK and we
Jiri> don't have to solve anything, right?

Yes, this is the "textmode=1" on the kernel command line method.
This works with CJK. Nothing to fix here.

Jiri> Remaining cases:
Jiri> 1. user selects text installation, but language selects in yast,
Jiri> not before.  Thus we don't have fbiterm and have to continue in
Jiri> english. I'm ready to commint yast2-country enabling this
Jiri> behaviour if nobody complains.

Sounds like a reasonable solution.

Is it possible to switch only the user interface language to English
but continue to use the selections etc. for Japanese if Japanese
is selected in YaST2 in a real text-mode (no-frame-buffer!) 
installation?

Jiri> 2. user selects text installation, selects the language, but
Jiri> fbiterm cannot be started for whatever reason. Is _this_ the
Jiri> case we should care about? (mfabian: isn't this really corner
Jiri> case?

Looks like a corner case to me.

Just did a quick test: textmode=1 works fine with Japanese in 10.0. 
 
'text mode' via menu really is a fallback for debugging/working around 
problems. 
 
I still see this as a corner-case and people who want it should just go 
for 'textmode=1'. 

Maybe the problem is only that this is not well known.

Would it be possible to display a help for the 'text mode' via
the menu like:

    Attention, this is only a fallback for debugging and
    working around problems, some languages for example
    CJK language will not work.
    If you want to do a "text-mode" installation using a CJK
    language, use "textmode=1" on the kernel command line instead.

Or something like this.

Steffen is right, we have already *all* possibilities:

    - Qt
    - framebuffer text mode
    - non-framebuffer text mode

The problem is only that most people don't know how to use it.  Even I
had to ask Steffen again although I was involved in the last bugreport
concerning this problem.

Mike in comment 35:

"Is it possible to switch only the user interface language to English
but continue to use the selections etc. for Japanese if Japanese
is selected in YaST2 in a real text-mode (no-frame-buffer!) 
installation?"

Yes, exactly this is intended behaviour (see comment #11) .

Ad comment #38:

"Attention, this is only a fallback for debugging and
working around problems, some languages for example
CJK language will not work.
If you want to do a "text-mode" installation using a CJK
language, use "textmode=1" on the kernel command line instead."

This should be described in the documentation and/or support database.

>I still see this as a corner-case and people who want it should just go
>for 'textmode=1'.

But this is documented nowhere. And if it is in the admin/userguide, I doubt
everyone's gonna find that little piece o' text. IMO, this should happen:

At bootloader time, because FB is a kernel-boottime option:
         |  Any Other Lang.          |   CJK
---------+---------------------------+-------------------
Text     |  80x25,Language           |   80x25,English
         |                           |
VESA     |  standard,ncurses,Language|   fbiterm,ncurses,CJK
         |                           |
640x480/ |  Qt,Language              |   Qt,CJK
numeric> |  Qt,Language              |   Qt,CJK

OK, I'll commit proposed solution (see comments #21 and #32).

Jiri, please skip inst_langauge if you find that language was selected,
regarless on text/Qt mode.

Klara, please write an SDB article about installation in text mode (based on
comments #37 and #38).

@#42: OK, submitted to STABLE. 

http://portal.suse.com/sdb/en/2005/09/cihlarov_cjk_textinstall.html  

There is currently no way to get Japanese with text mode.

Indeed, textmode=1 on the kernel command line doesn't work anymore.

I created a new bugreport for this and added you to the CC:.

I'll close this bug as FIXED again (because it contains a lot of
unrelated stuff).

New bug report is bug #226407.