Autotranslated themes and plugins for WordPress: An idea

Published: ·Updated ·Author: Demetris·WordPress

If you have translated, or prepared for translation, more than a couple of WordPress themes and plugins, there are two things you must have noticed:

  1. WordPress has a good system of internationalization and localization
  2. The translation material can become repetitive

This first is, to my mind, one of the things that have made WordPress so popular. It is also one of the reasons we see some popular plugins and themes published in as many as 20 or 30 different languages.

The issue

The second is something normal, since there are some common things that plugins and themes usually need to say. For example:

  • ← Previous
  • Categories
  • Changes saved.
  • Comments are closed.
  • Edit
  • Edit this entry
  • Next →
  • Next post
  • Permanent link to %s
  • Previous post
  • Save Changes
  • Skip to main content
  • View all posts by %s
  • View all posts in %s
  • View all posts tagged %s
  • etc. etc.

But the repetition starts to seem silly after a while. Why do we have to keep translating over and over strings that are not simply identical but also meant for identical contexts in one and the same application?

Some time ago I decided to translate one of my favourite WordPress themes. I opened its translation file and saw about one hundred strings in total. It’s a usual number for a WordPress theme. Of them, half were strings I had translated, or slight variations of strings I had translated, for other themes before. (For Simplish, Tarski and Thematic.)

So, I said: “No! I can’t keep doing this. It’s silly!”

Now, I happen to be the maintainer of the Greek WordPress translation and, as a result, I am familiar with the strings WordPress comes with. I knew that many strings that themes have in common existed also in the WordPress core.

The WordPress core has more than three thousand strings. Three thousand and eighty-eight (3088), to be exact, in version 3.0. (And that’s without even counting the multi-site strings.) It’s madness, but it also means that you can find almost anything in there.

And this gave me an idea to try an experiment: I was curious to see if it was possible to make a theme not simply internationalized, but also localized out of the box for a substantial part of its strings.

The method

The method I was going to follow was simple. I imagine others have tried it before.

The basic WordPress i18n functions—__(), _e(), esc_attr__() etc.—take two arguments: First, the string to be internationalized; then, the text domain. The text domain can be omitted. If it is omitted, WordPress uses the default, which is default. This is also the text domain of the WordPress core.

So, if a string of your theme or plugin, let’s say “Categories”, also exists in core, you can use the core translation by doing any of the following:

__('Categories');               #   2nd arg omitted
__('Categories', '');           #   2nd arg is empty string
__('Categories', 'default');    #   2nd arg is string “default”

Each of these will give you a string translated out of the box.

The result of the experiment

To keep a long story short, I completed the experiment and the result was better than I expected. My theme had about 100 strings in total. When I finished, seventy (70) of them were localized out of the box!

That is, a WordPress theme 70% translated out of the box!

70% fewer strings for the translators to deal with!

70% fewer things to go wrong on the translation front!

The theme’s strings even fit in one screen in Poedit. You see everything without having to scroll even once.

So, why haven’t we adopted this bright idea already?

Two small technical hurdles

As I said, I imagine other people have played with this idea before. And I suppose they too found a couple of small issues that prevented them from implementing it in practice:

First, even though the default text domain has strings for almost everything, nothing says that any one of these strings will be there in the next WordPress version. If you rely on the core translation of a string and then core modifies or removes this string, your theme or plugin will be left with a partial translation.

Second, we don’t have a script that can make a POT file with only those strings that need translation. That is, a script that makes a POT file ignoring strings with no text domain or with “default” as text domain.

NOTE. The script for making POT files for themes and plugins is at the URL below:

http://svn.automattic.com/wordpress-i18n/tools/trunk/

And, I have to say, it is a very convenient tool: You check the whole directory out with Subversion, run makepot.php on your plugin or theme, and you are done in a second. (Learn more.)

But it does not provide for our case yet.

My proposal

#14972: Proposal: Pool of common strings for core, themes, and plugins – WordPress Trac

I believe these two hurdles are easy to overcome, provided that we agree the autotranslation idea is good, and worth adopting and promoting.

So, I made the above proposal in the WordPress development tracker.

For the first hurdle, it proposes making the necessary modifications to makepot.php.

For the second hurdle, it says this:

Single out a few core strings that are commonly used in plugins and themes and designate them as strings for common use. Then copy these strings into a new file, say, strings-common.php. Once a string is in that file, it will not be liable to change.

Then, if core wants to modify or drop a common-use string for itself, it can do so without affecting the common pool. Plugin and theme authors can use the common pool safely, knowing that its strings are there to stay.

I have thought a bit about the idea and the implementation, and it seems to me it would bring several advantages.

  1. It will encourage theme and plugin authors to avoid duplication by using existing strings.
    • Being all in one file, the strings for common usage will be easy to discover.
  2. It will make translating WordPress plugins and themes more attractive.
  3. It will reduce workload and save time for translators.
    • Hopefully, some of that time will go to more translations, better translations, or a bit of both.
  4. It will improve standardization and QA for the common strings (more eyes will be on them).
    • Importantly, this will also benefit core strings.
  5. It will reduce package sizes for localized plugins and themes.

In fact, I can only think of advantages.

Your thoughts

What do you think?

/dk