The big locale cleanup (and adding text domain functionality)

@meba, search works for me! Unless you enable a language and set that to the language used by Drupal, the locale tables will not get populated with strings to search for (and the search for will inform you that no results were found). Do you have records in the locales_source table at least? Did the search say you have no results, or it returns to the same page.

@meba, GNU Gettext has the concept of "text domains" or "translation domains", and I figured we'd rather bring that in, instead of reinventing the wheel here. http://www.gnu.org/software/gettext/manual/gettext.html#Interface-to-get... Different modules would register their own text domains with locale module, so we can provide an interface to translate aggregator categories, content type names, profile field labels and so on. I have a post about this here: http://groups.drupal.org/node/3772

@Dries, you are right, the menu API could probably make use of a generic callback allowing us to call functions in include files. I guess you marked code needs works because of meba's concerns, so I am awaiting more information from meba about search problems.

Grabbed latest Drupal HEAD, applied the patch (1 hunk failed). Updated that to reflect the latest menu localization changes.

Tested all forms:
- adding language from predefined list
- adding custom language
- enabling languages, changing default
- configuring language negotiation
- translation overview screen
- translation search with different options (yes it works just as before, don't know what meba sees)
- translation import
- translation template export
- translation export

All forms and screens worked. I fixed one notice bug in PO exporting, which showed up when I had no translation for certain terms and the translation was undefined in the table join.

Unless we know something better then "text domain" for these different translation domains, I would say this is ready to go in. Please review!

The patch!

@meba, where do you think that documentation should go? I'll definitely document hook_locale() in contrib/docs, but I don't think this has a place to add in Drupal core. Anyway, domains allow you to add translation for more stuff, let them being exported and such. Watch this: http://hojtsy.hu/drop/dtvideo.mpeg

Erm, yeah. Some more thinking and I figured we have no documentation for the overview page, where people will face these domains. Added the following as help text for that page:

This page provides an overview of interface translation on the site. Different text domains allow you to translate parts of Drupal. Text domains (like aggregator and user profile) are provided by some modules you use (aggregator and profile module respectively), while the built-in interface domain is always available.

This hopefully sheds some light on what is that text domain thing. (Yes, I know people will not watch my video, needless to point out :)

Meba, the number of text domains depend on how many can we finish before the code freeze. We are way into trying to come up with a performant solution for "dynamic object translation" (internal name for translation of certain Drupal objects). We are looking at these for that feature in Drupal core:

- (built-in domain already exists)
- aggregator categories and feeds
- user profile labels and categories (categories still need to be factored out to be a separate object, like in aggregator, the current profile module implementation is very translation unfriendly as far as categories go)
- content type names, body labels, etc
- variables AKA site settings (these still require the default values to be factored out to a hook, so you don't need to provide a default value parameter to variable_get() a bazillion of times you use the variable, plus we can easily provide a settings translation interface based on these)
- user defined block titles and contents

At last, we can possibly provide menu items and taxonomy translation, but the above come first, because they are a lot more straightforward (except the two outstanding issues, which should be fixed regardless of our efforts going in or not).

That adds up to at most 8 domains in Drupal core. Any number of domains can show up if people start to update contrib modules. Maybe CCK will go fine under "content types", but others might need to provide their own types. You can have as many languages on the site as you wish also, so I am not sure how that table can scale. Having languages on the vertical axis mirrors the layout of the language setup table, so that seemed logical.

Dries, the fundamental difference between what you see and what Drupal 6 users of locale module will see, is that they have node module turned on by default, as well as site settings, so they will start with three domains already listed and being available (I am in the hopes that we can deliver that functionality in time for Drupal 6), making it a lot more obvious that domains group translation by function / area of web site. You needed to see the video to see that you can have more domains, and to see the role of domains in the system. Drupal 6 users with locale module will have three domains enabled by default already.

What about this help text?

This page provides an overview of interface translation on the site. Translation of the Drupal interface is organized into text domains, allowing you to export different domains for translation as well as focus on translating parts of your web site at a time. Text domains (like aggregator and user profile) are provided by some modules you use (aggregator and profile module respectively), while the built-in interface domain is always available.

I need to point out another aspect. Although it is an ideal goal to translate a site 100%, but most of the time it is neither feasible neither even required. While the built-in interface or site settings might not be required to get translated 100%, your user profile details would be. Some translation teams simply skip big admin help texts and leave that in English to concentrate on the user interface of the site. Some site settings will not require translation, even if they are translatable in a usual sense. So different domains might need different levels of completeness, of which the overview provides a good picture of. Because this is site specific, I don't really know how to put hints into the documentation about this.

Dries, you did it! :) That sounds a lot more user friendly compare to my version. Fixed the text to say "grouped into" which is more accurate as far as I know then "grouped in". Updated patch attached.

Meba, "content" is hard to define. Some people prefer to call their menu and taxonomies "interface", because these are used for navigation and such. After a brief discussion with Dries, he added some suggestions, which come up in this patch:

- renamed "text domains" to "text groups" to be super-simple, that also removed confusion of internet domain name support for languages, which is (for us) obviously different, but could have been confusing
- added constants for language directions: LANGUAGE_RTL and LANGUAGE_LTR
- removed debug code from theme function
- renamed "built-in" text group to "default" text group (the translations are definitely not built in)

Dries also pointed out that we should simplify the search screen, which is definitely on the horizon, but would be too much for this patch.

New patch attached! I tested it with all screens: langauge setup, add, edit, configure, translation overview, search, import and export template and translation, and all seem to work.

Erm, you cite the following lines:

1153: if (!isset($trans2->lid)) { // no translation in current language
1126: }
915: * @param $op
248: return $form;

I don't see how any of these would be E_ALL problems. How did you come to the conclusion? Care to work with the latest patch, so we can make progress?

Erm, excuse me, 248 was in locale.module, not in locale.inc. That might make sense to fix:

if ($form['#id'] == 'node-form') {
if (variable_get('language_' . $form['#node']->type, 0)) {

Updated:

if ($form['#id'] == 'node-form') {
if (isset($form['#node']->type) && variable_get('language_' . $form['#node']->type, 0)) {

The others still need clarification.

OK, these E_ALL fixes included:

- used isset($topop) in place of $topop != NULL, does the same but is E_ALL compatible
- used if (!empty($varname)) in place of all the if ($varname) stuff used (that was the reason for most if not all E_ALL problems)

Updated patch attached.

Indeed, both RTLs are typos, if we don't have direction information from the predefined list, then it means it is LTR, not RTL. The default function parameter should assume the same for consistency. Patch committed, thanks.