On 2018-10-22 11:19, Didier Roche wrote:> Gunnar Hjalmarsson wrote: >> Please note that the language-options script serves the purpose of >> providing a list of languages only, i.e. it let's the user select >> the display language. That should be distinguished from selecting >> the locale for regional formats. For the latter purpose the user is >> offered an option list consisting of all the generated UTF-8 >> locales. > > I'm unsure to understand this split; but that's probably due to my > inexperience.
There are far more locales than translations. The most extreme languages are English, Spanish and Arabic which are all represented by a large number of locales. The script simply restricts the options shown to the users to the available translations instead of showing a long list of locales. Thus, when selecting "language", the user is shown the installed translations, and when selecting "regional format", the user is shown the generated locales. > Let's take from the user's point of view: > - they have a list of language, let's say (randomly :p) that I select > French here > - then I have a list of countries, I select "France", then I have > Euro and a particular date format configured. > > The second part is pre-configured based on the country I selected, > but this is basically fr_FR default, correct? Well, if you are talking about the installer now, the user is currently not offered the option to explicitly select a country. The installer uses the time zone location to 'guess' the user's preferences with respect to currency, date formats etc. and picks a locale for regional formats accordingly. > If I select Portuguese (Brasil), I would have Portuguse (+Brazil > dialect installed) and BRL currency + their date format. If you install from France (i.e. select a French time zone location) you'd still have the fr_FR locale for currency, date format etc. > Then, of course, I can mix and match in some other UI to change the > currency and have Portuguese (Brazil + USD + european date format) if > I want. Yes. Please note, though, that the UIs only allow you to distinguish between display language and regional formats. For a more fine tuned use of the available locale categories, for instance USD for currency and ISO 8601 like date format, you need to use the terminal. (Kubuntu is an exception in this respect; its UI can be used to specify each locale category.) > If I understand you correctly, we need to have locales generated on > disk to know about the avaiable variants, like _foo? Yes, that's how it currently works in Ubuntu. Locales are generated in two ways: - At installation of Ubuntu's language packs - Separately by the installer if needed to pick a locale for regional formats if your time zone location does not match the selected language. I think that g-c-c in vanilla GNOME shows all locales, whether generated or not, and creates the one you select if needed. But OTOH GNOME does not have our language packs; all translations on GNOME are provided by respective application package. So our use of language packs (the ones with LP translations) explains this difference in approach. > I'm trying to see how we can rationalize in the hypothese of a new > installer, and ensuring that both GNOME Control Center (which isn't > in a very good state regarding displaying locales) can be enhanced, > not really focus on "there is that script or that script". Does it > makes sense? Yes, I think it makes sense. > One of the issue in Control Center is that it expects to have all > locales generated to display them IIRC for currency, language and > date options, that's correct, isn't it? I suppose it would be possible to enable g-c-c's locale generation feature and show also locales which are not generated. That way you wouldn't need to install a language only to be able to set a particular locale for regional formats. We should keep in mind that most flavors don't use g-c-c but they use language-selector, which does not have such a locale generation feature. But I think it would be possible to do this in Ubuntu without making things worse for the flavors. I can take on to look closer into this. After all I think it's mostly about modifying one of the g-c-c patches which I'm guilty of anyway. Is there anything else you think of when saying that g-c-c isn't "in a very good state"? > Ok, so we always include "base language", and even if for some > packages (like libreoffice-dictionnaries, thunderbird), we have > splitted by regional settings (due to debian), we install them all, > considering the impact in installed size is minimal. > We would thus change "en" to apply the same semantic, and be included > as soon as en en_* something option is selected, and thus, install > all en_*. (which is what check-langage-support wants to do already, > but no ubiquity…). That would prevents bugs like #1732222 to exists. > For the "sync with ubiquity", the all_langpacks sounds like a good > solution, do you mind doing a MP for bionic (as this is really what > we want to fix with a new image respin)? Actually I'm reluctant to do a MP for that, since I don't know how you test proposed changes to the installer. But with that said, there is a tiny debdiff attached to comment #3 in bug #1294858. Possibly that's it, even if it was written four years ago... I'd love to see it applied and being able to test a daily build with it. (And yes, hopefully that change would take care of bug #1732222 too.) If that change works as desired in dd, we could then backport it to bionic. >> Are you talking about creating meta packages to pull the language >> support instead of what's currently in the seed and in >> language-selector's pkg_depends? > I don't really know, it's an opened question. I wonder how we can > minimize and have the best layout for what we want to achieve. (Not > quoting all your sentence, but ack on not diverging from Debian for > the dictionaries for isntance). > ... > I guess your idea of a metapackage isn't bad, and would simplify the > logic in scripts and ubiquity (or rather new ubiquity). We would > have though language-foo and language-minimal-foo. Is there any > corner cases that we are obviously missing here? It almost seems too > simple :p Meta packages wasn't really my idea; it was rather my interpretation of your idea. ;) I'm not sure; I feel there are both pros and cons. Possibly we should postpone this part for now, focus on what we seem to agree on, and then revisit this aspect of a possible simplification. Would doing it in that order make sense to you? It's my understanding that we are agreed on these things so far: 1. For users who select a non-English language in the installer, don't install (or rather uninstall) the English language packs. 2. Make Ubiquity install all language support packages related to the selected language, to behave in consistency with how language-selector uses check-language-support(). 3. Fix the "Formats" selector in g-c-c so it shows all locales, and generates the selected locale if it was not generated previously. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to language-selector in Ubuntu. https://bugs.launchpad.net/bugs/1797860 Title: Language selection installs too many packages Status in language-selector package in Ubuntu: New Bug description: Multiple issues arise when installing any languages in ubuntu: 1. if you select en_GB, en_US is selected instead 2. if you select fr_FR, fr_FR + en_US is selected 3. As soon as en_US is selected (which is always right now), en is then selected, which in turns requests installing all en_* languages. 4. ubiquity, if en_US is selected, only install en_US + en packages, but then, check-language-support wants to bring back all en_* variants (hunspell-en-au hunspell-en-ca hunspell-en-gb hunspell-en-za hyphen-en-ca hyphen-en-gb libreoffice-help-en-gb libreoffice-l10n-en-gb libreoffice-l10n-en-za mythes-en-au thunderbird-locale-en-gb in cosmic for instance) which were discared by ubiquity. The last point is due to /usr/share/language-tools/language-options reporting needing (in the fr_FR default installation for instance): en_US fr_FR en en_AU fr en_GB en_CA A big rework/revamp would be needed in language support, account-services and ubiquity, backed up with tests. Ideally, the seed and check-language-support will always be in sync, the list of package to install is strictly regulated by check-language-support (which is supposed to be the case below, but we see in 4. that it's not), and we limit the number of components disagreeing in which languages are installed/supported. We need to take into account ofc the debian singularirity about generated locales. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/1797860/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
