How a drupal multilingual websystem can take down your manpower and how to solve this

13 Sep 2011

Joris Snoek
Digital Consultant
+31 (0)20 - 261 14 99

We are working an implementation of a large multi-langual drupal social media websystem, and stumbled upon an issue that we ran into all multi-langual Drupal websites before: managing a loooooot of English 'strings' (200+). Or: English words in your website that are not content manageable via nodes.

So I want to bring up a content management translate issue here.

After the installation of the 'Locale' module (that's in Drupal core optional). You can translate these words via admin/build/translate/search.

FYI: Drupal core has got 731 strings that can be translated. You can download packs here: http://drupal.org/project/Translations

But the big issue here is: Drupal hard-wired that the text coded in the 't()-function' in your module/theming functions is always English. No matter what the sites default language is. I think this happens in the function code on http://api.drupal.org/api/function/t/6

  ..
  // Translate with locale module if enabled.
  elseif (function_exists('locale') && $langcode != 'en') {
    $string = locale($string, $langcode);
   }
  // It only returns a translation if $langcode is not 'en'.
  // $langcode is not your prefix! It can't be changed.
  ..

So if your customer wants to change an English word, what do you have to do..?
Indeed: change your code!
I hear you say... "rather not, every time..!"

For starters, that provides three problems:
1. Your help-desk / project manager / code engineer gets an unnecessary work-load; in compare to customers can do it fully themselves.
2. Your customers can't manage this by themselves; what can make them dislike you on this issue.
3. Drupal core code can't be 'hacked' / changed. So Drupal core English can't be altered at all.

Wouldn't it be very nice if your customers could manage English words all by himself?
We figured a way out for this, without installing a module that makes you dependent on it. So you can preserve the 'en' path (url) prefix AND be able to translate via the user interface.

The fix

1. Create a custom language

In admin/settings/language/add create a 'custom language', we call this for example 'English US'.
So fill out the form and create that custom language.

2. Set this language to prefix of 'en'

Set the original 'English' prefix to something else then 'en', for example: 'en-uk'
Set the custom language 'English US' prefix to 'en'.

3. Set this custom language as default

Set your custom language 'English US' as default 'English'.

4. Your content managers can translate 'English'

When you give them enough permissions, they can manage the 'English' strings in admin/build/translate/search.

Related links

Translations pack
Translating user defined strings
Hardcoded language strings
String translation: why using t() for user specified text is evil? (oldie)
Keyword-based translation system (Newbie, Drupal 8)

Feedback, Questions about internationalization (i18n) in Drupal?

Or maybe you know a nice module / code snippet that does the trick...
Please hit me on Twitter for all your feedback, and any other issue!

PS

Hope we can work on our own fully multi-lingual website soon :-).
Don't underestimate the development impact of Drupal i18n on your site!
Avoid getting into a scope-creep with your customer: think very well about i18n on your Drupal site, make a functional design and graphical design / wireframes before you write any HTML and Drupal code.

Comments

Nóg meer
kennis nodig?

Check ons ons blog archief >