While small one-line texts are not a problem, updating and translating big chunks of text is currently really difficult in Drupal:
- The texts are written in multiple lines mixed with php. It takes a php coder to fix a typo most of the times.
- The localization system performance is awful for big texts, searches are done using full source text.
- The translation process is usually quite hard because you need to translate line by line, you usually miss the context.

This (proof of concept) patch, which only takes care so far of a pair texts in the node module, introduces a new system on which big texts are stored on a text file, then retrieved when needed using a text key:

drupal_get_text('node', 'module-help', ...);
drupal_get_text('node', 'welcome-page-nocontent', ..);

The single text files are searched in the filesystem, can be overridden using variables, can be localized using the locale system or a translation file can be found on the filesystem..... The proposed file system structure is as follows:

modules/node/text/module-help.html  (Original English text)
modules/node/translations/es/module-help.html (Spanish translation included in node file)
translations/modules/node/es/module-help.html (Spanish translation in an alternate folder..)

This approach has some important advantages:

  • The texts are not mixed with php code, people on the documentation team could easily update them without the risk of breaking any code.
  • The handling of big texts would be much better with the localization system only doing text searches for small ones, that maybe could be cached all at once. This still needs some UI and text updating into the db
  • Translators finally get to see the whole text for translating, and they translate the full text at once, not line by line like until now
  • Drupal code would be much shorter, as we take this huge unreadable texts out of the php files. The text files are only loaded when needed
  • It is fully compatible with the old approach, we can still use t() for small texts into the code

This could be used for most of help texts, user emails, and in general for any text longer than one line. In summary, we move from this (php file):

    $default_message = '<h1 class="title">' . t('Welcome to your new Drupal website!') . '</h1>';
    $default_message .= '<p>' . t('Please follow these steps to set up and start using your website:') . '</p>';
    $default_message .= '<ol>';
    $default_message .= '<li>' . t('<strong>Configure your website</strong> Once logged in, visit the <a href="@admin">administration section</a>, where you can <a href="@config">customize and configure</a> all aspects of your website.', array('@admin' => url('admin'), '@config' => url('admin/settings'))) . '</li>';

to this (html file):

<h1 class="title">Welcome to your new Drupal website!</h1>
<p>Please follow these steps to set up and start using your website:</p>
<li><strong>Configure your website</strong> Once logged in, visit the <a href="@admin">administration section</a>, where you can <a href="@config">customize and configure</a> all aspects of your website.</li>

Note: this patch may overlap with this one #299050: Help System - Master Patch
however I think it is quite a different approach (it's not only for help texts but for all long texts) like to be on a different thread.

#12 module_get_text_01.patch36.1 KBJose Reyero
Passed: 10268 passes, 0 fails, 0 exceptions View
drupal_get_text.patch16.99 KBJose Reyero
Passed: 10268 passes, 0 fails, 0 exceptions View
Members fund testing for the Drupal project. Drupal Association Learn more


Jose Reyero’s picture

Issue tags: +i18n sprint
tstoeckler’s picture

Would there be a UI then for the translation? If I got your idea correctly then to translate or edit these texts you would have to create a new text file, which in the case of user e-Mails is really a regression if I just want to change the wording a little bit and don't have a UI to do this.

Jose Reyero’s picture


Yes, there will be a UI, though there are bits of that yet to be implemented. The idea is that all the strings can be translated using the localization system, which already supports different text groups. What is missing in the patch is the install part for the modules on which, if locale enabled, it should import all the texts for that module as source strings.

tomamic’s picture

If it can help... localization in Java is quite simple and effective:


Basically, you provide different localized properties file, and their names are trailed with their locale id ("_en", or even "_en_US").
In the properties files you have simple name/value couples.

This would strip all massages off code.

catch’s picture

Status: Active » Needs work

I agree with merlinofchaos on the help text issue that we should keep the help system separate - afaik the new help system is only going to be for admin/help and popups, not for inline/variable text - and it's that which this patch helps most with.

So if I understand it right, this patch has the following benefits:

# Very long strings from code move into separate files.

# Long strings from the {variables} table can also be moved to this system, at least for defaults. Since variables are loaded on every single page load, that's a lot of memory saved. So something like http://api.drupal.org/api/function/_user_mail_text/6 could more or less disappear.

# We move long texts out of the locales tables unless they're customized on a per-site basis - which as Jose says would massively reduce the size of the locales table too.

# Something like the string_overrides module would still allow for small tweaks to these texts without using the whole locale system on monolingual sites - simply by setting variables.

# We could still provide settings for things like the e-mail texts in core - again by saving customized strings as variables, but keep the defaults in text files.

# It lets us do all this without completely overhauling both the variable and locale systems.

Nothing major jumped out for a first look at the patch, so great start overall. Are you planning to convert all long texts in this patch or in a followup?

tstoeckler’s picture

Just to make sure I understood this correctly: The goal is to have the default texts stored in files for instance in the module's folder in case of the module's help text (just an example...) and to have string overrides, for instance changes to the e-mail texts or custom localization stored in the database. And Language packs could include their own files for e.g. those e-mail packs, right? And contrib modules could ship with translated versions of their text files as well, right? If this is the way this is supposed to work, then:
Great job, Jose A Reyero!!!

Jose Reyero’s picture

The answer is yes to all.

This may relate too to the variable defaults (long story) patch: #145164: DX: Use hook_variable_info to declare variables and defaults

Yes, that's the idea. The part of looking into a separate folder (/translations) is aiming at that language packs :-)

Jose Reyero’s picture

Status: Needs work » Postponed

I think I have a better solution (that may later be expanded to search for text files).

So I'd prefer to move forward this other one, which I think has more chances to get somewhere as it is not that radical approach: #368560: Make texts in modules readable, better text handling and localization

(marking this one a postponed, but if someone wants to move on with it feel free to change that)

merlinofchaos’s picture

Just FYI, I also see no reason that we couldn't run these help topics through drupal_get_text() or something as a secondary method of translation, where we consider the primary method to be directly via file, and then the secondary looks in the database. That's something that would come a little later, of course. There's a nice little routine that looks in different places for the help text and takes the first one it finds; a future patch could expand that quite a bit.

gaele’s picture

Using drupal_get-text() for help pages would introduce the possibility for granular access control, right? So we could hide help for modules the user has no access to?
Anyway I would support this patch if only for the translation in context purpose.

Jose Reyero’s picture

When I look at this three patches in queue I see that there's a lot of overlap currently, but I think there could be some great synergy here If we re-scope them all a little bit. Besides this one:
#368560: Make texts in modules readable, better text handling and localization
#299050: Help System - Master Patch
I see it working like:
- module_get_text(), for searching texts (included help texts) belonging to a module
- drupal_get_text() searching for db string overrides (variables, localization) and if not found, defaulting to the file system -> file get text
- file_get_text() would be a file api level function that searches for localized texts in alternate folders if locale enabled
- the hook help just needs to implement module_get_text() / file_get_text() when it fits, the help system really doesn't need to know where the text comes from.

This has nothing to do with access control, you'd need that implemented in the help system itself.

Jose Reyero’s picture

Title: Localization for big texts / text in text files. » Hanlde big texts / module text files / readable and localizable / get rid of _user_get_text()
Status: Postponed » Needs review
36.1 KB
Passed: 10268 passes, 0 fails, 0 exceptions View

Updated this patch merging also this one #368560: Make texts in modules readable, better text handling and localization

Now we have:

  • A single handler for all module long texts: module_get_text($module, $text_id)
  • All texts / arguments can be either in the module.text.inc or on its own file
  • All texts can be overridden (using variables) or localized (locale_get_text(), not implemented yet)

This should make

    Make the code and the texts much more readable
  • Get rid _user_get_text() finally
  • Big help texts easy to edit as html files

Status: Needs review » Needs work

The last submitted patch failed testing.

Dave Reid’s picture

Status: Needs work » Needs review

Testing failure on bot #4 (user picture tests). Resetting.

stella’s picture

Status: Needs review » Needs work

This is looking pretty good. I've only done a visual review so far, but I have an issue with the inconsistency in the help_about.html files in relation to $Id$ lines.

The modules/user/text/help_about.html file has the following line:

<!-- $Id$ -->

but none of the other new help_about.html files do. Files missing a $Id$ line are:

  • modules/node/text/help_about.html
  • modules/node/text/page_welcome_nocontent.html
  • modules/user/user.text.inc
  • modules/node/node.text.inc

Then there's a minor indentation issue in modules/node/node.admin.inc for the line:
+ $form['access'] = array(
There's also a lot of trailing spaces on lines in the code which probably should be removed too.


David_Rothstein’s picture

I was pointed here from #391924: Use Fields to store text variables, especially those that require text format support as a possible related issue. It seems like the two issues are very complementary, since there we're talking about storing user-entered values for variables in a way that they could (hopefully) be translated via the Field API, whereas here you're talking about storing the default values of those variables.

From a quick glance at this patch, I don't see any obvious ways they would conflict at all (except for the dumb minor thing that both patches are trying to introduce a new function with the same name, "drupal_get_text" :) So mostly just subscribing for now.

catch’s picture

I don't like the big switch statements here - could we use hook_text_$key() instead / as well?

Gerhard Killesreiter’s picture

I want to point out that we at some time split up the giant helptexts into smaller strings in order to make them easier translatable. This seems like a step in the opposite direction to me.

Jose Reyero’s picture

Status: Needs work » Postponed


True because it was imposible to keep translations up to date with the localization system. This is an alternate to avoid that and translate texts as a whole (so translations won't get lost every time you fix a comma in the source)

I've done this other patch, which reuses some of the ideas here but I think is way better (consistent, secure, flexible...), please follow #517044: Improve text handling, texts in text files (editable, overridable, translatable, etc...)

In the meanwhile I'll mark this as postponed.

tstoeckler’s picture

Title: Hanlde big texts / module text files / readable and localizable / get rid of _user_get_text() » Handle big texts / module text files / readable and localizable / get rid of _user_get_text()
plach’s picture

Version: 7.x-dev » 8.x-dev
jibran’s picture

Status: Postponed » Needs work

As per #19

Jose Reyero’s picture

Status: Needs work » Closed (won't fix)

No need for this anymore, handled by config system now.