Installer should have option to install English system with e.g. European locale defaults

[Kurt George Gjerde]

Installing Dapper with English language and Norwegian location gives me en_AU as locale. Personally I'd prefer en_DK with a touch of en_FI.

(SimonLaw says: ubiquity should probably prompt you to select some form of locale, if you pick a language and location combination that doesn't exist in the locale database.)

[Simon Law (sfllaw)]

Dapper.1 and Edgy both have more reasonable archive selection.
See bug 40107 for more information.

As for your language problem, that's something that is a proper bug.
Since this report actually reported two issues, I'm transforming it
into just one. In the future, please report separate issues as separate
bugs. This helps us track them more appropriately.

Thanks!

[era (era)]

In https://answers.launchpad.net/ubuntu/+source/ubiquity/+question/33280 I am suggesting a fallback mechanism to en_DK if the user selects English language together with a location which doesn't have an English locale defined for it. I'm not sure how far this is generalizable, but at least for large parts of Europe, this will probably produce more or less what the user had hoped for (metric measurements, A4 paper, reasonably sane date format, week starts on Monday).

I am unfamiliar with the history of the en_DK locale, but my speculation is that it exists specifically as a "Euro English" fallback, as I believe Denmark doesn't have any particularly significant English-speaking population.

[era (era)]

In nominating this as a paper cut, I would like to reiterate my idea to fall back to en_DK if the installer language is English and the location does not have a valid en_XX locale defined for it. It's obviously tricky to solve the more general case of any-to-any but I would expect English-to-any to be by far the most common scenario for a multilingual installation.

[era (era)]

An even simpler and more general workaround would be to allow advanced users to specify a system locale in the installer, perhaps in the "Advanced ..." dialog at the very end (although at the moment, that one contains completely unrelated options, pertaining to boot loader device etc)

[Mikko Rantalainen (mira)]

How about expanding the current locale system to include special country code ZZ for every language? Such locale should be defined to always default to ISO compatible values: SI system (metric measurements), A4 paper, ISO 8601 date format and week numbers etc. The implementation of en_ZZ.UTF-8 could be identical to en_DK.UTF-8 for a start. The installer could default to ZZ country code locale if selected location has no specific locale. According to http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2 the country code ZZ is reserved for user assigned values. Unfortunately, there does not exists official "undefined" country code (similar to UND language code) which would be appropriate here.

When it comes to formatting numbers, it seems that ISO has never successfully defined format for decimal numbers. According to http://en.wikipedia.org/wiki/Decimal_separator it seems that some ISO blueprints have defined comma (,) as decimal separator (instead of US period) and space as digit grouping symbol (instead of US comma). At least most of the continental Europe follow this system, AFAIK. According to http://en.wikipedia.org/wiki/SI the 10th resolution of CGPM in 2003 declared both comma and period as acceptable decimal separators. The only concensus seems to be that English usage is period, other usage is comma.

For LC_COLLATE, I'm completely lost. Perhaps ZZ country locale should always implement http://www.unicode.org/unicode/reports/tr10/

[Mikko Rantalainen (mira)]

It just occurred me that en_ZZ.UTF-8 should probably be just en.UTF-8. That is, text in English, without any country specific exceptions. Sounds like ISO compatible feature to me. Apply the same logic for other languages.

[Mikko Rantalainen (mira)]

Close to bug 40107 (I don't think this is a duplicate, rather one is depending on another)

[Martin Albisetti (beuno)]

Thank you for bringing this bug to our attention. Unfortunately a paper cut should be a small usability issue that affects many people and is quick and easy to fix. I'm afraid this bug can't be addressed as part of this project.
A paper cut is a minor usability annoyance that an average user would encounter on his/her first day of using a new installation of Ubuntu 9.10.

[era (era)]

Are you saying that major usability issues with (potentially) a quick and easy fix are out of scope? Or that the proposed fix is too complex? Or that not many users will encounter this problem? For the population who needs to support multiple users with different languages on their system (think server administrators in any larger corporation, or household computers in a significant fraction of multilingual families) this is one of the first hurdles they will encounter, and currently inordinately hard to solve; this is decidedly not an "average user" in the US but still a significant segment in many other parts of the world.

[era (era)]

> It just occurred me that en_ZZ.UTF-8 should probably be just en.UTF-8.
> That is, text in English, without any country specific exceptions.
> Sounds like ISO compatible feature to me. Apply the same logic for other languages.

For many languages, the expectation is that LL should simply be equivalent to LL_TT where LL is the language code and TT is the only territory code where the language has a significant user population. (Also FWIW actually ISO date formats are only popularly used in Sweden and Japan AFAIK.)

[Martin Albisetti (beuno)]

On Thu, Jul 2, 2009 at 7:43 PM, era<email address hidden> wrote:
> Are you saying that major usability issues with (potentially) a quick
> and easy fix are out of scope?  Or that the proposed fix is too complex?
> Or that not many users will encounter this problem?

In this case, that not many users are affected by this issue.

[Mikko Rantalainen (mira)]

> For many languages, the expectation is that LL should simply be equivalent
> to LL_TT where LL is the language code and TT is the only territory code
> where the language has a significant user population.

So, do you think that "en" should be equal to "en_UK" instead of "en_US" (USA has a significant part of population that prefers e.g. Spanish over English)?

I'd prefer "en" to mean "English without any country specific details (compatible with all international standards where possible)" instead of "English with random country specific details".

I'm aware that historically "en" has been equivalent to "en_US" but is there any actual reason for this?

[era (era)]

Mikko Rantalainen: I think overriding "en" as you suggest is going to come as a surprise to people who already have a well-established expectation for legacy behavior. Certainly Ubuntu should not make such a change unilaterally.

If it wasn't for the legacy burden, I'd support this suggestion -- it would be elegant and transparent, but alas, in this the best of all possible worlds, it would bring a nasty surprise for a significant population of users.

[era (era)]

BTW the language issue is a red herring -- US citizens who want Spanish language should obviously have a es_US locale to choose from. But aside from that, again, I don't think you can break with the US legacy without anchoring the decision in pertinent standardization bodies, outside of Ubuntu.

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Launchpad Janitor (janitor)]

[Expired for ubiquity (Ubuntu) because there has been no activity for 60 days.]