pluginsA Google search for “WordPress CMS enabling plugins” yields 341,000 results, many of them blog posts titled “5 essential CMS plugins for WordPress“.

What I’d really like to know is what you’re using when you build full websites with WordPress.

We’re asking this for a reason. The next release of WPML (1.1), will put an emphasis on localizing texts created by other plugins and theme functions.

So, collecting a list of popular plugins which WPML users need will be very helpful.

The challenges of making other plugins multilingual

Plugins typically interact with WordPress in two ways. They access the database and produce HTML. WPML needs to make sure that both these operations are done correctly.

For example, a whole family of related posts plugins indexes posts and searches other posts for similar keywords (when done correctly, this operation can be quite fast). This means that to work correctly, in multilingual sites, they would need to either create individual, per language, indexes or use the language attribute as a parameter for the index.

Considering the fact that these plugins were written with no consideration for a multilingual environment, this can be quite a serious challenge.

And, on the other side, plugins also render text. A simple thing such as a sentence saying “you may also be interested in these posts” is less of a problem. Most likely it’s already wrapped in the gettext call and localized through the plugin’s .mo file.

However, dynamic texts are more of a problem. For example, look at the title tags produced by the famous All-in-One SEO plugin. There are titles per page and also for the home page, categories, search, etc.

WPML would also handle the per-post/page texts without any problem. The texts in the plugin admin screen are a bit more of a problem. They fall into the same category as widget titles and contents. These cannot be translated with a .mo file (since the texts are entered by the user) and also cannot be translated per page, as they’re entered once in the admin section.

How WPML can help other plugins become truly multilingual

In order for other plugins to become multilingual WPML is going to add localization functions which can be called from these plugins. The localization function should:

  1. Register texts that need localization, so that the admin can provide translations.
  2. Hook to the text render, so that the correct text is displayed per language.
  3. Be an optional process. This means that the plugin will run file without WPML (but in a single language) and with WPML in multiple languages.

There are two approaches that can be taken here. One is to allow other plugins to tell WPML to hook to them and another is for WPML to create the translation functions for the plugins to call.

Not just plugins, theme functions too!

Premium themes (or your own custom themes) sometimes add a great deal of functionality to a website. This ranges from navigational aids, to a complete makeover (even WordPress’ mother wouldn’t recognize it).

Since we all can be very creative when it comes to writing theme functions, it’s important to establish some guidelines. Just like plugin localization, we need to get to a state where the same theme can run perfectly without WPML and run multilingual with it.

So, what are you doing?

Tell us what you’re using for your sites. It’s important to know now, so that WPML can support it.

Any major plugins that need multilingual support?

Any theme practices that have a hard time coexisting with WPML?

If it’s a simple thing, leave a comment here. For technical discussions (which we love), head to our forum and start a new thread.

3 Responses to “What are your CMS enabling plugins?”

  1. I use: Atahualpa Theme, All in One SEO Pack and some widgets.

    How about making it possible to have the same plugin and widget
    installed several times (one for each language)?

    • Why do you need to install the same plugin several times? With WPML, you use the same WP install to serve all the languages, and you install each plugin once.

  2. I guess it would be an easier way for WPML to handle 100s of different widgets and plugins if WPML installs them separately once for each language (and hides that complexity from the user).