Bug 1028988

Summary: Language panel shouldn't allow setting non-UTF-8 encodings
Product: [openSUSE] openSUSE Tumbleweed Reporter: Federico Mena Quintero <federico>
Component: YaST2Assignee: E-mail List <yast2-maintainers>
Status: RESOLVED FEATURE QA Contact: Jiri Srain <jsrain>
Severity: Normal    
Priority: P5 - None    
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
URL: https://fate.suse.com/323355
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Federico Mena Quintero 2017-03-10 23:42:29 UTC
Bug #1020619 resulted from a customer who tried to run GNOME in a non-UTF-8 encoding, and it Didn't Go Well :)

I posted a comment there, along the lines of this:

1. GNOME is *not* written to work in any other encoding than UTF-8.  Everything assumes UTF-8.  Code shouldn't blow up if it is passed invalid UTF-8, of course (e.g. through corrupted data or through a data file with another encoding), but this is different than trying to run the environment itself in a non-UTF-8 encoding.

2. If the customer really requires running an application / in-house system / whatever in a locale-specific encoding, they should isolate it and run *only that* with the locale-specific encoding, not all of GNOME.  They can do this with a shell script along the lines of

  #!/bin/sh

  export LANG=de_DE@euro
  /opt/legacy/whatever $*

3. Please tell customers to *not* uncheck Yast's "use UTF-8 encoding" checkbox.  This is probably a holdover from many moons ago, but we've been writing software to use only UTF-8 only for more than 15 years now :)


To summarize: software shouldn't crash if it gets a data file in an unexpected character encoding.  However, we've been writing software whose *internal representation* of data is in UTF-8, for many years now.

YaST still includes a checkbox, "Use UTF-8 encoding" in the Details window of the Languages panel, that makes it possible to turn off UTF-8 for the whole environment.  I think we should remove this in 2017 :)
Comment 1 Stefan Hundhammer 2017-03-13 13:38:17 UTC
Are you sure this will work for all Japanese, Korean and Chines users, too?
I am all for getting rid of non-UTF-8 locales, but did all Japanese users make the migration from Shift-JIS to UTF-8?
Comment 2 Federico Mena Quintero 2017-03-13 15:52:20 UTC
(In reply to Stefan Hundhammer from comment #1)
> Are you sure this will work for all Japanese, Korean and Chines users, too?
> I am all for getting rid of non-UTF-8 locales, but did all Japanese users
> make the migration from Shift-JIS to UTF-8?

My hypothesis is that if they were not using UTF-8 locales, their desktops would explode in similar ways to bug #1020619; we would get frequent bug reports about this.

Is it possible to ask them?  Do you know of similar bugs coming from CJK users?
Comment 3 Stefan Hundhammer 2017-04-18 08:11:56 UTC
Looks like this got stuck; nobody seems to know how to proceed.

IIRC this is a decision we cannot make on this level; this needs to go up to product / project manager or architect level. I suggest you open a FATE entry for this so it goes through the proper channels. We cannot just change anything as fundamental as this on the developer level.

Therefore, closing as RESOLVED FEATURE.
Comment 4 Federico Mena Quintero 2017-04-25 15:09:31 UTC
Filed https://fate.suse.com/323355 for this.