Textgroups for built-in interface translation

My proposals for Drupal 7:
I think that dividing the built-in interface texts into textgroups is an excellent idea. Exactly as said in the original D6 help text, I would love to separate translations on administrative pages from the rest (using already existing feature of textgroups), for the following gains:

1. Greatly reducing the amount of strings to translate on average site. Consider that usually a site has only just one admin-person, who often know English well, and so need no translations on admin pages. This person might even prefer original English descriptions, to avoid struggle with misleading, terms-confusing translations. While translating from scratch, which is often the case with various contribs, omitting administrative texts would be safely possible with textgroups, reducing the workload greatly.

2. Performance boost: Choice to not translate administrative texts will reduce size of locales_target table a lot. Excluding administrative texts from the default textgroup will also reduce amount of cache-processed data on regular pages - a lot!

3. More focused string search (by textgroup additionally) on administrative page.

Introducing the textgroups for built-in inteface texts would involve:

A. Providing a second core textgroup 'admin' in locale.module

B. Extending t(), format_plural() and locale() calls with another optional argument, specifying the texgroup to use, defaulting to the 'default' textgroup previously used, so that no code needs to be changed, unless newly using some other textgroup. This will enable the built-in administrative texts to be moved into the separate textgroup, being still handled by existing code. Also this will enable the current t() and related code to be re-used for any other textgroup, avoiding code-duplication from locale.module where possible. (For example, the object-translation function dt() suggested elsewhere http://drupal.org/node/141461 might decide to use t() calls as it's subpart for handling single strings where possible, to simplify code, using already existing database-/cache-handling.) The cache will be only built/loaded for the used textgroup, obviously, to avoid increased overhead on regular pages.

C. Providing a wrapper at() ('administrative text') function to simplify update of existing code:

<?php
function at($string, $args = array(), $langcode = NULL, $group = 'admin') {
  return t($string, $args, $langcode, $group);˝
}
?>

Such wrappers might be internally used by any other modules, to easily put their texts into separate textgroups.

D. Changing all t() calls on administrative pages to at() - a lot of work, I know, but it's a relatively simple search-and-replace task.

E. Updating the .po template generator to split the files into textgroups, allowing separate distribution of admin translations.

F. Pruning the abandoned admin-strings from default textgroup after update. This will not be possible immediately, but dead strings will be excluded from cache-processing already, and pruning feature is about to come - I'm cooking it right now. See http://drupal.org/node/171646

Sure, fixing D6 is the first now. But I've a few more thoughts to consider while waiting for me to prepare a help-text-patch:

Current situation: As far as I can see (correct me if I'm wrong), the textgroup feature is included in D6 very visibly (appearing on admin pages, in help text...) but not supported properly by the core t() system, and so hardly ever usable for modules. We have a nice hook for modules, to define a new textgroup, but if a module wants to really translate strings with that group - the only way I can see is to clone the whole t() and related code into each module, with the only change being an edit to the hard-coded textgroup name. That seems wrong to me: Module developers will either ignore it, because dividing the strings into groups is not worth the effort with own t() implementation, OR we're going to have a dozen of t() clones around the modules soon, difficult to maintain/update and possibly buggy (let alone the size of code). Both degrades the benefits of textgroups, no matter how we change the help-text.

So, I would be tempted to say "Let's try to get my proposal B. into D6" (new argument on t() ). Unfortunately, it surely qualifies as an API change, although it's NOT a change to break any existing code.

Against that - IMO it also qualifies as an usability-bugfix to the existing textgroups feature, allowing modules to really use it for strings translation - no matter how the usage will finally look like, like my proposals or not - and preventing t() clones in modules done just to deal with one missing argument on core function. Modules are still free to handle locale tables on their own if needed, but IMO that's a bit rare and risky case, and so should NOT be required by default.

A patch for this would be easy, and I'll be happy to provide it quickly, but first an opinion from core commiters is needed. Thanks.

OK, I got the point (and saw something of the mentioned efforts while searching Drupal.org). But then, the mention of separating translations of admin pages (which basically goes my way) *SHOULD* be removed from the help-text, as your last comment in fact means that text groups are *NOT* meant to be used for this. Translations of built-in interface should be always limited only to the one default textgroup, as nothing else will be ever accessible to a t() call, you basically said (correct me if I took this wrong), so the present help-text is pure nonsence. It should tell things about module-defined translations of some entirely different texts, not a part of the user interface, as it stands now.

(BTW - also consider, that the last added $langcode argument also breaks your line the same way IMO - translating emails to different user's languages is definitely NOT the originally designed purpose of t() too. If other translations need other storages, then it might easily turn out, that the whole concept of textgroups is good for nothing, so I'm unsure why it's included in D6 at all. This is all a bit above my level of understanding of the locale system development, though, so forgive me ignorance if that's the case.)

Now proceeding to create a help-text patch, coming back soon.

Attaching a patch - the help text change. More abstract wording to avoid false impressions from not-working-yet examples, plus mention of extra text groups being only just module-provided, not out-of-box existing.

I don't understand the argument about $langcode... As long as you use t() on literal strings in code, it is used for what it was meant to be used. If you need to translate the literal text to a different language, then this is in the boundaries of t() IMHO. Maybe you can elaborate?
Then $langcode is OK :) But in this case I can't understand, why it's NOT OK to enable t() to translate other text groups (like mentioned admin helps) which are also literal texts in code, only just deserving a move to other textgroup for performance and translators' work efficiency. This whole issue was meant to be ONLY about literal texts in code.

Perhaps my reference to dt() proposals was incorrect, but I thought that objects might also contain some (minor?) amount of fixed in-code strings in boundaries of t(), wanting to re-use existing t() code without throwing the strings into default textgroup. Most probably I didn't get the point there, so please ignore the said reference.

Now, can you please comment my patch, so we can go on?

Seems we got out of sync with issue status.

I didn't have anything particularly concrete in mind, just gathered a very vague idea of some code-defined label + user-defined value pairs. As I already said, I just used a not-fully-understood example along the way, didn't really have a point in that part. So I just say sorry.

Thanks.