Improve duplicated language lists

Thanks, that's a design issue, we are just following what is described on https://wiki.ubuntu.com/LanguageAndText#phone-language

Matthew, could you review/comment on that one?

Currently the list includes many languages that, as far as I can tell, do not actually have available translations. For example, it includes 17 varieties of English, when in reality Ubuntu Touch ships with only the three that Launchpad offers for translation -- en_AU, en_CA, and en_GB. <https://launchpad.net/~/+editlanguages> (Plus en@shaw, which I've reported bug 1455917 for.)

I suspect this is because Ubuntu is showing a list of locales rather than actual languages, and many locales share languages. Is that correct? Andreea Pirvu and I are working on the assumption that it is, and that we can separate out the choice of locale into its own step. If you have allowed location detection, possibly the step will be automatic, or at least the default can be based on your location. Either way, that would shorten the list of "languages" from 100 entries to about 50.

If we did limit the list to only those languages for which Ubuntu ships translated strings, that would make bug 1455917 more urgent.

@Matthew: Please note that a list of language options, which represent the available translations, is available via

/usr/share/language-tools/language-options

It has been used for a few years by the applicable desktop GUIs.

I suppose it could be used for Ubuntu Touch as well, provided that the selection of regional formats (certain locale categories) is broken out to a separate UI component.

@Gunnar, thanks for the pointer. Our current list is built from a call to "locale" and some filtering around it, I suggested a small change that make it filter out things without langpack translations but maybe using the script you pointed to would be a better option, I'm going to look at that later (though ideally I would like to avoid calling shell script from the code)

Yeah, it's a shell script, but when you use "locale -a" you shell out anyway, don't you?

accountsservice's Language property matches one of the values in the language-options list, and could safely be used for grabbing the current value.

I suppose the current list is still needed for the regional formats UI component. accountsservice's FormatsLocale property matches one of those values.