Voting starts in March for the Drupal Association Board election.
I was deeply involved with adding textgroups into core (in). They proved to be a very flawed concept over the years though. The goal of textgroups in locale module was to avoid coding a custom translation backend for all the configuration pieces in Drupal: menus, blocks, contact forms, etc. These all need translation for some of their properties but all our custom, so it looked like it makes sense to provide a central storage place for them.
Now, all that Drupal core does is this central storage place, and it exposes editing/translation for these on the regular locale UI. There are various issues with that as I've detailed in my post on why using t() is wrong for configuration items (read at http://groups.drupal.org/node/149984):
- the locale subsystem assumes the source strings are English, while for configuration that is not true; we assume the configuration strings are in the site default language, which can be wrong at times as well; this messes up the translation editing UI and process quite a bit; English to other language and foreign language to other foreign language items show up side by side
- the locale subsystem does not have any structure or relations between strings; if you have t('Home') and t('Next'), these are just standalone strings to translate; a menu item has a title and description, a contact form as a subject and an autoreply text; these should be edited related to each other, not in isolation; the locale system does not provide anything for that
- the locale subsystem does not have provisions for input widgets and validation; the translations input are checked for XSS, but that is it; if your input should be email addresses or a username, validation will not be available; also the widget will not have autocompletion, a format selector or anything like that
- the main reason we reused this was for .po file versions of the custom configuration strings to be exportable and importable for free; turns out it was impossible to use this feature on Drupal 6 for years(!) see, so it was not actually that much desired
- text stored with the locale subsystem obeys the generic "translate interface" permission, which can be too broad to let people edit allowed field values or reconfigure contact forms
The i18n module makes a LOT of effort to plug in some holes in this system. It tries to augment the permission handling for example with its own input format checker, so that you at least don't get text for translation that was in a source input format that the site did not allow for translation. It is a distinct setting though for i18n, not a permission, since it cannot be dynamic. i18n module also uses the context feature in Drupal 7 to store structure for these strings, but that makes the filtering and the overall locale interface very confusing.
All-in-all, I've proposed for i18n in Drupal 7 to move away from textgroups to a better system, and Drupal 8 should not have any reason whatsoever to keep this frankeinstein there. If we happen to not solve any of the configuration translation needs, textgroups is still a very bad idea to try and support some contributed module to do that.
It should not take a lot to remove this given we only support it on the schema level and minimally on the UI, there is no real API to get data in or out of textgroups (minus the .po import/export which is pretty standard).
|#41||remove-textgroups-for-good-4.patch||41.76 KB||Gábor Hojtsy|
PASSED: [[SimpleTest]]: [MySQL] 33,638 pass(es). View
|#37||remove-textgroups-for-good_3.patch||40.38 KB||Gábor Hojtsy|
PASSED: [[SimpleTest]]: [MySQL] 33,563 pass(es). View
|#29||remove-textgroups-for-good_3.patch||41.04 KB||Gábor Hojtsy|
PASSED: [[SimpleTest]]: [MySQL] 33,513 pass(es). View
|#27||remove-textgroups-for-good_2.patch||41.03 KB||Gábor Hojtsy|
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch remove-textgroups-for-good_2.patch. View
|#24||remove-textgroups-for-good_0.patch||41.03 KB||Gábor Hojtsy|
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch remove-textgroups-for-good_0_0.patch. View