Ok, I understand, but what about these packages? <div class="Ih2E3d">myspell-en-au myspell-en-gb myspell-en-za openoffice.org-help-en-gb openoffice.org-l10n-en-gb openoffice.org-l10n-en-za openoffice.org-thesaurus-en-au thunderbird-locale-en-gb </div>wbritish <div style="text-align: left;" id="result_box" dir="ltr">You need to have English support in 2 types (UK and US) of English?</div> As I said before: "It is curious, UK & U.S English.. Also, it has even dialects of English: myspell-en-au (English australian) or myspell-en-za (English southafrican)..." 2009/2/9 Colin Watson <<a href="mailto:cjwatson@ubuntu.com">cjwatson@ubuntu.com</a>> <div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Firstly, the original source of this was <a href="https://bugs.launchpad.net/ubuntu/+source/localechooser/+bug/13452" target="_blank">https://bugs.launchpad.net/ubuntu/+source/localechooser/+bug/13452</a>. It's useful in a few slightly arcane contexts (oem-config comes immediately to mind) to have a UTF-8 locale that's guaranteed to exist immediately after a fresh installation. C doesn't qualify, because it doesn't define handling of non-ASCII characters, and for instance if you run newt applications in LC_ALL=C you won't get any non-ASCII characters displayed; it's somewhat useful for this kind of purpose that we always generate en_US.UTF-8. (Yes, I know there are other roundabout answers, but there is software in Ubuntu that depends on this at the moment.) Making sure that we always have some help files is a useful property, as Martin says, since this is *not* an area where the gettext properties Paul Smith described apply (the language-pack-* packages themselves are nice and simple, but the grottier edges of language-support-* certainly aren't); and in general it is useful to have a fallback in the event that the native support packages are insufficient. I know that English isn't universally spoken, of course, but it does have rather wide second- or third-language coverage and it has the more important property that it tends to have very complete help files and the like, since it's usually the language in which help files are originally written. I don't think the installer has a reasonable way to perform the substitution you suggest (only openoffice.org-help-en-us and gimp-help-en). We have language-support-* for a reason; I wouldn't be happy about having to dig around inside this abstraction in the installer. In short: yes, I have long been aware that the fact that we always install English language support is suboptimal for various reasons. For languages with very broad translation coverage, such as Spanish, it is probably generally unwelcome; for languages with much narrower coverage it is not clear that the same reaction would hold. The current state is a compromise between various requirements, so I would rather not simply revert it in favour of one extreme. Perhaps we could do a finer-grained job of installing fallback packages, maybe using the relatively new language-support-TYPE-LL packages, or maybe with the aid of some additional metadata in those packages to indicate whether they provide something reasonably complete. -- Colin Watson [<a href="mailto:cjwatson@ubuntu.com">cjwatson@ubuntu.com</a>] </blockquote></div>