Hi, This post is about Debian packaging. (Not about user configuration)
As I understand for the locale value: LANG = <null>, or C System can always be set to this way and the system acts 100% POSIX manner. No locale data generation is required. Non-ASCII characters may not be processed as UTF-8 encoded and they are corrupted. LANG = C.UTF-8 (Not defined in anywhere easily found but available) System can always be set this way under Jessie(??) and system acts 100% POSIX manner for ASCII characters while not corrupting UTF-8 character processing. No locale data generation seems to be required under Jessie. LANG = en_US.UTF-8 System can be set this way if only locale data for en_US is generated during installation by the user or locales-all is installed. One of the package I maintain (ibus) has gettext data pairing en_US.UTF-8 data with localized text. Currently, user choice in localized luggage is translated back to en_US.UTF-8 string and that English text containing non-ASCII is used for further processing. Naturally, the upstream code sets the locale to en_US.UTF-8 to get the English text. This is problematic if the user chose for initial locale setup contain only en_GB.UTF-8 without en_US.UTF-8. Jessie seems to have C.UTF-8 available as default, am I safe to use C.UTF-8 as always available UTF-8 compatible English system? I see several ways to fix packaging of ibus: * Patch the upstream source with s/en_US.UTF-8/C.UTF-8/g . * Add locales-all to package dependency is another solution. * (If locales package always set up en_US.UTF-8, I am off the hook.) I guess some apps may be in the same situation. How other DDs are coping with apps which set its internal locale value temporarily to the default en_US.UTF-8? Regards, Osamu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140914164231.GA26155@goofy.local