Abstracting language settings out of locale (updated)

The first implementation detail we are looking at for Drupal 6-dev i18n is abstracting language settings out of the locale interface. In Drupal 5, the locale module handles the list of available languages (which is reused in i18n related contrib modules). The data stored about languages is not enough for most purposes (native names are not stored, RTL-LTR direction information is not available), and extending modules really have no way to plug into the language management screen.

The goal here is to have a language management interface, where you can get a handle on the languages you would like to make available on your site (either as interface languages and/or content languages, it does not matter). The languages will be stored more generically (ie not in a "locale_*" table), so they are to be reused by design by the locale and any other translation modules.

Note: screenshot updated to reflect latest development.

Visit the flickr page for notes and full screen view.

This new approach dictates that languages should have their own management screen. I got into doing a first mockup this morning, so we see where we are going and can talk about interface, code and database schemas if need be. In this mockup, the import and export functionality (which is actually tied to interface translations and not to languages) is moved to an interface string management screen. Also we get the locale related pieces removed from languages table, and new details added.

Thanks to tips from Jose Reyero, here we have the native name of languages stored, so we can show a better list of selectable languages on a German page for example showing native names too. We also store the directionality of the langauge used, so themes can conform to LTR and RTL languages too. The Drupal built in language list (in locale.inc) already has the native languages listed, we need to extend it with the directionality information, so if you add a language by picking one from the list, you get the right directionality with it.

This is a generic language list management screen. How this can be reused (or even extended) by locale and i18n related functionality is still an open question.

• Either we allow altering of the displayed form, so modules can add columns (like "enable for interface localization", "interface localization percentage" and such).
• Or locale and i18n related functionality can provide their own tables, where the language list is a given, and specific setup options are presented there.
• A third option would be to have a language editing interface per language (simlifying the overview table to not display a form, but really only some information), where settings can be placed. Block editing is a possible model for this kind of interface.

A bigger architectural question is where the language management code should reside. Either we should add a language.module to handle general language setup, or we keep this functionality as part of the locale module. The question is wheter it is deemed a valid use case when someone does not need interface translation functionality but needs content translation functionality (eg. an English blog with ocassional French posts, but no French interface). On such a site, the locale module would be something to get rid of, if possible.

Questions to you:

• Do you have anything generic to store per language (which is not already stored in Drupal 5 and is not in the above mockup)?
• Is the above interface useable, or we need a separate editing screen even for these basic settings?
• Should we tie language management into locale module or a new language.module (on which locale and i18n functionality depend)?
• You surely have something else to add, which I am not thiking of!

Get the code from the Development Seed SVN, where anonymous checkout is allowed.