Clean up language support
Rediscuss the structure of language-support-* metapackages vs. language-selector's dynamic detection of missing packages; right now this is a wild mix, and I'd like to consistently use language-selector for everything.
This should also cover installing missing language packs when you install new software from software-
- Martin Pitt
- David Planella
- Martin Pitt
- Series goal:
- Accepted for oneiric
- Milestone target:
- Started by
- Martin Pitt on 2011-10-24
- Completed by
- Martin Pitt on 2011-10-24
Work items (oneiric-alpha-2):
Get rid of all language-support-* metapackages in favour of dynamic installation in language-selector: DONE
Stop building language-support-* in langpack-o-matic: DONE
Add the remaining language-support-* dependencies to language-selector: DONE
Contact the design team to give Language Selector a workflow/UI review (keeping the move to the control-center module in mind): DONE
[arnegoetje] Confirm whether Arabic needs an input method: DONE
Work items (oneiric-alpha-3):
[mpt] Research how other platforms name the "Language Support" application <https:/
Rename "Language support" to "Languages" or to the result of the research in the previous work item (no reason to break all translations just for one or even zero cycles, until the control center capplet is used): DROPPED
Implement new $LANGUAGE widget (upstream language settings makes great progress, this work would be redundant): DROPPED
[mpt] Design language installation in gnome-control-
Reimplement language-selector GTK UI in gnome-control-
Work items (ubuntu-
[gunnarhj] Provide internationaliz
Catch all session on language support
- Currently a wild mix to install locale-related packages
- language-support packages
- more dynamic detection in language-selector
- That might be the best path: more dynamic, more extendable, easier to maintain
- Proposal - move to that system, drop language-support-* metapackages
- Solves automatically instaling missing langpacks and support packs for e. g. installing kwrite on Ubuntu
- Easier to maintain, as we have pattern based matching instead of static dependency list
Prerequisite: software-center integration, i. e. automatically call check-language-
- Some work in this direction already: https:/
No problem for OEM builds, already uses check-language-
Behind-the-scenes fixup of missing langpacks? -> Takes very long, user might interrupt it unintentionally, also uses significant network bandwidth
UI of l-s concerns:
- drag&drop list is too small, not accessible, and not discoverable
- user is expected to dnd a greyed out item, which is unusual
English | <- | English (US) ^
Spanish Portugese v
German | -> |
Problem: it is not clear that the setting is per-user --> rename to "Apply for all users"?
l-s help is currently not translatable, needs i18n'ing the build system
gnome 3 c-c only offers a simple locale selector; depending on the outcome of the current c-c extensions
- Discussion we might need to replace this with embedding l-s
UndiFined: male* / female note it is in male by default (bug 47504)
Arne Götje: Arabic has keyboard layouts in XKB, so input method is not needed.
pitti, 2011-05-17: Thanks David for already drafting this! I swapped drafter/approver (as this was mainly meant for peer review) and clarified some work items. Based on the recent discussion on desktop-devel@ it looks like we're going to submit at least a large portion of that work upstream.
--> dpm, ack
Added an action for Martin as per our IRC conversation
I'm working on this design (https:/
- thanks Rodrigo; I have no idea about the "Customize" either, users can't install per-user locales, nor does it make much sense to change the locale definition. The only thing that I can imagine is that this would allow you to set different locales for different categories, like en_GB.UTF-8 for LC_PAPER and LC_TIME, and fr_FR.UTF-8 for LC_MONETARY. But this is a bit outside of what you should be able to control with a GUI, IMHO. The one thing that does make sense is to be able to set LANGUAGE and LANG individually, i. e. use a locale ($LANG) for paper, time, etc., but use another language for strings.
- the "Input Sources" Tab seems unnecessarily complex to me -- is that actually a keyboard layout selector? Could it perhaps say "Keyboard"? Does that combine the input method (ibus module)?
- Having a separate "System" tab seems a bit undiscoverable to me. IMHO the individual tabs should have an "Apply system wide..." button, but I guess the designers already discussed that. Just my personal opinion.
- Rodrigo, will you work based on these guidelines: https:/
- Maybe the current approach with "IBus Preferences" + "Keyboard Preferences" + "im-switch" isn't that bad, after all.
- I agree with Martin's comments on the "Customize" button, but I think that adding a "System" tab might be a good idea.
- When you come to the "Language" tab, I'd like to strike a blow for the current Ubuntu approach where each option represents an available translation. file://