Clean up language support

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://live.gnome.org/Design/SystemSettings/RegionAndLanguage?action=diff&rev2=21&rev1=20>: DONE
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-center <https://live.gnome.org/Design/SystemSettings/RegionAndLanguage#inline-installation>: DONE
Reimplement language-selector GTK UI in gnome-control-center 3 (vastly extend upstream's "Language & Layouts" dialog) -> not enough time this cycle (done by Rodrigo, but not tied to the cycle): DROPPED

Work items (ubuntu-11.10-beta-1):
[gunnarhj] Provide internationalization support to the Language Selector help (we'll use the gnome one next cycle, so no need to spend work on this now): DROPPED

Session Notes:

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
Advantages:
 - 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-support as part of the dependency resolution process
  - Some work in this direction already: https://bugs.launchpad.net/bugs/396414

 No problem for OEM builds, already uses check-language-support

 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

 Strawman:

 Available: Active:
 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

dpm, 2011-05-26:
Added an action for Martin as per our IRC conversation

rodrigo-moya, 2011-06-21:
I'm working on this design (https://live.gnome.org/Design/SystemSettings/RegionAndLanguage) for gnome-control-center 3.1.x. The formats tab is done, just missing the 'Customize' button, which is not clear yet what it should do. After that, will work on the input methods thing, so let me know if you get some comments to that design ASAP.

pitti, 2011-06-21:
- 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.

gunnarhj, 2011-06-24:
- Rodrigo, will you work based on these guidelines: https://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/InputLanguage Sounds like an interesting but complex approach. One thought that strikes me is the risk for oversimplifying the UI. "the user should not have to know anything about ibus or xkb" - Don't Asian users in general know which input method system they use? (Not a rhetorical question; I don't know the answer.)
- 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:///usr/share/gdm/language-options