Language, langcode, locale, how do I name you? Plans for locale.module in Drupal 8.

Locale.module in Drupal 7 does at least these 4 main tasks (besides some smaller ones):

• Lets you set up languages and configure them.
• Lets you configure how Drupal selects form those languages for certain things (UI, content, etc).
• Offers a backend and an interface to translate the UI of code-supplied interface text. (It does provide a half-baked attempt at providing a generic translation storage backend too which is about to be removed in Drupal 8: http://drupal.org/node/1188430)
• Lets you import and export Gettext .po files with these translations

Now this is a lot of stuff, and I did not even mention some smaller pieces like supporting node languages and other small bits. One thing locale.module does not actually do is setting up locales. Yeah. If you read up locales at wikipedia (let's say), you'll see that locales in their complete sense are things like string ordering rules, currency formats and decimal separator configuration. Well, Drupal does not do that. In the "industry accepted understanding" of the terminology, Drupal does not support locales, it supports languages and localization (UI translation), but not locales.

Why I'm going into theoretic details is that as part of the Drupal 8 multilingual initiative, we need to take a long hard look at poor old locale.module (even though I did not mention this much yet in my posts, I did work on several issues related to it). Let's see the plans we have issues for so far.

• Removing textgroups support to avoid providing a broken half-baked feature for configuration translation making space for a real one (http://drupal.org/node/1188430)
• Provide a real CRUD API for languages so you can save/update/delete/load languages properly with APIs to react to changes or affect the language before saved (http://drupal.org/node/1215716)
• Same for UI translation source and target strings (http://drupal.org/node/361597), which will remove *huge* amounts of duplicate code that is now in l10n_client, l10n_update, i18n, etc.
• Refactor the gettext handling code to serve as a generic API so modules like potx, l10n_update, i18n or their core equivalent features can use it (http://drupal.org/node/1189184)
• Integrate l10n_update functionality in core (http://drupal.org/node/1191488)

Now this last point will actually add one more big subsystem to the set, and if we think about it, it really makes sense to rethink how we organize this and also be honest to world with our naming and move language configuration and language selection configuration to a language.module while the rest can be in a translation.module (name to be decided, thanks Sun for the tips).

So this would get us come to terms with our misuse of "locale" and name our language functionality properly after all. To gradually ease us into this in Drupal 8, I've started an issue about naming conventions for language related things at http://drupal.org/node/1216094 Here is the problem in short.

Locale module's language handling now supports setting up languages with langauge codes, which can then be used to load full language objects, as done with the global $language object by default. However, both the language code, the local loaded objects in functions and the global is called $language at places. The schema almost exclusively uses "language" to identify languages. If you look into the node table, url_alias, the field system tables, etc. All are called "language". However, these are just language codes. When you have such a "language" value, you still need to load in a "language" object, which then contains the language code in its ->language property (logically as used in other places in the schema). However, if you name your object $language, you might be in for some trouble if your code also uses global $language. You might be aware of the same problem for users.

So the main problem is that we call everything $language. The language codes in the database tables, sometimes language codes in variables (which are other times called $langcode), then typically local objects in functions and finally the global $language. Telling what $language is at any place is not really simple.

Compare this to users. You have $uid for the user identifier, $user for the global user and $account used for local users loaded. The equivalent for $uid, $user and $account for languages is $language, $language and $language. Yeah. In fact the $uid equivalent is in many places called $langcode, but this is far from universal. Also, langcode is pretty much against the Drupal coding standards, we don't do "ntype" for node types or "usrname" for usernames. But there is "langcode", which however is universally "language" in the schema.

This all might sound like nitpicky thinking and obsessing with small details, but that we did not get this right before resulted in APIs very incosistent and developers highly confused (including myself). If we'd have clear rules like developers have with $uid, $user and $account, that would be part of our ideal API for language handling. Because langauge support is now all around in Drupal from url aliases all through date formats and field API, it is important to get it right and consistent.

If you'd like to help wordsmithing definitions for languages, please follow up at http://drupal.org/node/1216094. For the more over-arching locale module plans and the eventual language.module, pick the relevant issue as applicable or in other cases comment here.

Thanks for all your feedback, it has been very valuable so far!