Skip Navigation

We’ve been asked how to translate texts that appear in the site but are not a part of posts or pages. Some examples are:

  • Text widget
  • Blog tagline
  • Other widget titles

What we’re thinking about is adding a generic string translation facilty which will allow localizing anything that’s text. The way it will work is:

When new texts are created (by the widgets save or blog configuration save), they will be automatically added to the list of strings in the website. Each string will have entries in all the site’s languages, which will be user editable.

If there’s a translation for a certain language, that translation will be shown. Otherwise, the original value of the string is shown.

It’s very similar to the way WordPress uses .mo files to localize itself, just managed automaitcally (without the need to search for new strings and add them to the .po/.pot file).

Do we translate according to string contents or token names?

.po / .mo files handle strings according to their contents. It doesn’t matter where the string is used but only what it contains. For example, if you translate the word ‘Save’, it can be used in a form for saving the current values or in the context of “Save the Earth”.

The translation table (to Spanish) looks like:

String Translation
Save Guardar

When you use the multilingual string, you would normally enter something like:

<?php _e('Save') ?>

If there is translation for the string, it will be output. Otherwise, the original text is displayed.

Resource files in applications normally use a different approach. Each string gets a token, that describes what the string is used for.  Translations are organized according to the tokens and not the string values. In this case, the translation table would be:

Token String Translation
SAVE_BUTTON Save Guardar

In the theme, this string will be displayed like:

<?php _st('SAVE_BUTTON') ?>

It appears like a minor change, but it’s very important. Now, the translation is arranged according to the context of the string and where it’s being used and not according to the contents. Several strings that have the same value can have different translations – each on matching the context of the string.

Pros and cons for using tokens to organize translations

When writing PHP code that includes localized strings, it’s easier organizing translations by string contents without using any tokens. Writing is more straight forward. You just wrap texts in gettext calls, like __(‘foo’) and _e(‘foo’), and you’re done. The code is easier to read and much easier to manage. Gettext does all the work for you.

However, handling the translation for these strings is a bit of a pain in the b**t. You don’t really know what you’re translating and which parts of the site have been translated. It’s just a bunch of strings that are used by ‘somthing’ (but no one can tell for sure by what).

String translation in WPML

In the next release of WPML, we plan to include string translation. We’re a bit biased for arranging translations according to tokens. Since a program is doing the bookkeeping, creating tokens and using them is not going to be a problem. The advantages of this method would be in the translation interface. When you go to translate a string, you’ll see immediately what you’re translating, where it’s used and how it will appear when translated.

What do you think?

Got other suggestions?

11 Responses to “Translation for text widgets, tagline and other texts”

  1. What about translation of URLs? E.g. and (I know I can already translate the category name).

    • Hi Martin. You mean translate the WP category base that you can configure under the permalinks settings section, right?

      We don’t have this feature currently – we’ll consider it for the next releases. There will soon be a forum and a ‘suggestions’ section in which you can add any ideas about features you would like to see.

      Meanwhile you can change ‘category’ to something more generic (if the English word ‘category’ is an issue for you) at /wp-admin/options-permalink.php.

      Thank you for your input!

  2. Hi

    Great post! And thank you for inviting us to ponder and comment on this very important issue.

    I am not as hesitant as you perhaps seem to be. I have done a lot of localization work in poEdit (yes, even in the source code of themes and plugins, if necessary).

    If you gettext your source code, then you can differentiate between singular and plural phrases. E.g., “there is one user” or “there are two users”. In stead of __ or _c or _e, you can use __gettext:1,2 or __gettext_noop:1,2 etc.

    Now, does the translator have a clue?

    Yes, indeed. In two ways, at least when using poEdit. First, the strings to be translated are sorted by line numbers. That does not keep all strings together that really are related. But it does group them, and in practice it is not problem.

    Moreover, if the translator unzips the source code – I always do – poEdit lets you open the source code and go to the right line and check the code. Even with only a little bit of knowledge about programming the translator can gather much from that. In addition, poEdit can open the source code in an external editor, where you can review all the code for the file.

    Now, if the programmers write nice code with lots of comments – and that is a good programming habit anyway – then the translator really have a lot of resources available.

    With a new update/upgrade of the source code, poEdit scans the source code and detects which strings are new. It even adds suggestions for the modified/new strings (using simple user configurable rules). Often that means that the translator is shown the new string and the translation for the old string. That is a good solution, if only few letters or words are changed.

    Of course, the translator can search the original strings or the translated strings. At present, he cannot search and replace, but it can be opened in an editor and edited.

    I must admit that I like the simple yet powerful interface of poEdit. So I would say that you should go for it.

    Another tool which is available from within WordPress, is the plugin Codestyling Localization. C.L. is already a mature plugin and a new even better version is in the making. C.L. integrates nicely with Google Translation using Google’s API (as far as I remember). C.L. saves .po files and generates .mo files. The new version will allow the translator to view the original strings, his own translations and a third language of his choice. That is really a nice feature, especially if you translate software written by, e.g., German programmers. Sometimes their German is better than their English! 😉 I am not affiliated with C.L. in any way. I just happened to know and translate C.L. into Danish!

    So your bias is not unreasonable. Nevertheless, I really think that you should consider to go for gettexting.

    • Hi Georg,

      Thanks for the very detailed feedback. I think that you’re a bit off the chart for an average WordPress developer (and of course, translator).

      We work with dozens of translators. A small part of them has enough technical skill to unzip source code, but very few will actually know what’s inside and how to handle it.

      We do a large volume of translation work and our criteria for a good translator is someone who can translate professionally, not be a top end WordPress developer.

      So, I prefer to make the tool-chain as simple as possible, allowing all translators to use it and not only developer-translators.

      We’ll be starting to work on the string translation for the plugin very soon and I’d love to get your feedback, once there’s something to see.

  3. Are there currently any *easy* solutions for translating “text widgets, tagline and other texts”? If so, can you point me to a How-To? If not, when do you think WPML will come out with this oh so important feature?

    Thanks in advance for your help with this!

    • Hi Randy,

      The easiest thing to do right now is wrap these texts in gettext calls and add their translation to your theme’s .mo file.

      The Text Widget will be difficult to wrap, so for now, just include that text in your theme (also wrapped in __() calls). It’s not very elegant, but will do the trick.

      The upcoming release (0.99) is still a bug-fix release. After that, we’re back to adding major functions and we’ll get to work on this one too.

  4. where is this “po/mo” file located, what’s it’s name, should it be “po” or “mo”? unfortunately it’s not clear. plz post a simple instruction how to create translations for

    • WordPress needs the .mo files. You can check the exact locations where to store them in WPML->Theme and plugins localization.

  5. Have there been any updates on this? Just go WPML for a bilingual RU-EN site and need to get three front page widgets translated. All are text widgets at the moment. I do not see how I can wrap them in gettext calls unless I remove the text widgets and add them to the theme. I was hoping there would be an easier way now..

    • I’m not sure that I understand what you’re trying to do. How about starting a new thread in the forum and asking the support folks to help you do this?