locale choices: <null>, C, C.UTF-8, en_US.UTF-8 and availability

[Osamu Aoki <osamu@debian.org>]

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