Today I was looking at https://bugzilla.redhat.com/show_bug.cgi?id=624158; part of that bug involved creating a locale mapping file in initscripts; this seemed like a bad idea. When considering that, I thought of lang-table, and wondered 'how could we get rid of that'. Some thinking later, and... anaconda currently has multiple locale/location screens: - language selection (custom anaconda) - keyboard selection (from s-c-keyboard, but nothing else uses that) - timezone selection (from s-c-date) anaconda needs the following bits of localization info: - locale/language - timezone - keyboard layout - text font anaconda uses the following data sources: - tzdata - lang-table (a custom anaconda file) anaconda does *zero* autodetection. The rest of this is driven by two assumptions: 1) We can do better. 2) We really shouldn't be driving off of configuration sources that only live in anaconda. ... Currently, we have the following data sources available to us: * iso-codes Includes: country subdivisions (state/province), indexed by country countries, and their country code languages Does not map: languages to countries * localedata Maps: languages to countries (more or less) Does not map: languages to a primary locale/country * tzdata Includes: timezones, indexed by country lat/lon for timezones Does not map: locales to country random cities to timezones (only specific timezone cities) * libgweather Includes: many many cities, organized by country - with timezone - with lat/lon - with weather codes Does not map cities/contries to locale * geoclue Maps: current location to: - country - city - lat/lon * xkeyboard-config Maps: language name to xkb layout (1:n, though) country name to xkb layout We also have the following widgetry: * system-config-date - timezone selector Uses: tzdata * system-config-keyboard - keyboard layout selector Uses: custom hardcoded mappings in the code, lang-table * system-config-language - language selector Uses: iso-codes * anaconda language selector - language selector Uses: lang-table and the following other codebases that don't have widgetry split out: * gdm - language and keyboard selectors Uses: iso-codes, xkeyboard-config * gnome-control-center datetime - timezone selecor Uses: tzdata http://live.gnome.org/Design/SystemSettings/DateAndTime * gnome-panel - location selector Uses: libgweather, tzdata and the following widgetry currently in development: * gnome locale configuration applet Uses: iso-codes, xkeyboard-config, and more http://live.gnome.org/Design/SystemSettings/RegionAndLanguage A modest proposal... On boot, as soon as there is networking available, start geoclue. Acquire location information. Then, feed the information as so: - country, lat/lon (from geoclue) -> timezone (from country, lat/lon, via tzdata) -> language (via ???????, see below) -> keyboard layout (from country/language combo, via xkeyboard-config) -> text font (hardcoded!) Notes: - What if we don't have network? Do DHCP always on link! - It's easy to get a list of possible languages given the country. There's no canonical data source of what to use for the *primary* language, though. We could make a mapping table (ugh), or do heuristics (double ugh). - text font is hardcoded to 'latarcyrheb-sun16'. We could conceivable have an override for the very few people who can't use that. We then display as so: ... Current settings: Location: United States [ change ] [ details ] If you click 'change', it pops up a selector dialog that either: - allows you to enter a location (similar to the gnome panel clock code) - allows you to click a location (similar to the control center timezone selector) Either of those resets country, timezone, language, keyboard layout, etc. If you select 'details', (or '>>>', or some expander, to be language-neutral), you get: Language: English [ change ] Country: USA [ change ] Time: 2:33 PM (US Eastern) [ change ] Keyboard Layout: us [ change ] Then, each of those options pops up a single-purpose configuration dialog. anaconda can either use the gnome capplet once it's done, or roll its own. Thoughts? Bill _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
