WordPress is a free and open source blogging tool and a content management system (CMS) based on PHP and MySQL. It is a scalable, robust and extensible application and provides a rich plug-in architecture and a template system. According CMS Usage Statistics provided by builtwith.com, WordPress is used by more than 51.0% of the top million websites as of December 2013. It is certainly the most popular blogging system in use on the Web.
It was first released in May 2003 by its founders, Matt Mullenweg and Mike Little. The most recent version, 3.8 was released as a preview on 10 December 2013 and a stable version followed on 12 December. As of 17 December 2013, version 3.8 has been downloaded well over 2 million times.
In this blog entry, we shall discuss using WordPress to support and manage multiple language websites. This will be the second post in a four-post series.
Preparing to support a multilingual website
WordPress does not support bilingual or multilingual websites out-of-the-box. However, you can use third-party plugins which will allow you to create and support a WordPress powered multilingual website.
Some free (non-premium) options include the Polylang, qTranslate or xili-language plugins and are installable on standalone WordPress sites. For multisite WordPress (one website per language), there are plugins such as Multisite Language Switcher, Zanto or Multilingual Press (Free). On the premium side there is Multilingual Press (Pro) with extended features (compared to its free version counter-part) and the WPML plugin.
Different types of multilingual plugins
The different plugins currently available for providing multilingual website support to WordPress generally fall under one of the following categories:
1. One language per post (e.g. WPML – paid, xili-language, Polylang or Bogo)
These plugins associate a single language per post and allows users to create translations for the given post as new posts (the same is done with pages, tag, categories, etc.). As such, multiple versions (in different languages) for the same content exist. This allows related groups of content and allows users to switch between the display languages.
|The standard WordPress database is not modified (clean install and uninstall).||Increases the complexity of the database and plugin architecture.|
|Everything associated with the post (including custom fields) are available for translation.||Additional tables may be required increasing the SQL overhead.|
|Avoids duplication of translation effort by leveraging the use of the theme’s displayed terms. Simply translate specific terms for the new target languages.||The plugin requires several hooks to filter content based on the current language.|
|It works well alongside other plugins which are unaware of localization.|
2. All languages in a single post (e.g. qTranslate)
The plugins store all the language contents within the same post. They use language meta-tags to distinguish between contents in different languages. Pre-processing is done when a post is to be displayed to ensure only the active language content remains.
|Side-by-side translation/editing.||Manual effort to create language tags to ensure the plugin works.|
|No additional tables/hooks to be implemented.||Clean uninstall may be difficult as multilingual content is interleaved within posts, pages, etc.|
3. Translations on the generated pages (e.g. Transposh and Global Translator)
These plugins perform translation on pages generated by WordPress. The plugin typically uses machine translation to create translated versions which can subsequently be modified by the publisher later.
|Easy to install and get running quickly.||Automatic translation is not the best practice and can result in poor translations.|
|Simple process to edit translations.||Changes in the original content may break translations.|
4. External translation services (e.g. Google AJAX Translation)
These plugins normally use online translation services (e.g. Google Translate). The translation process is done on-demand and uses the external service.
|The database contents for posts remain unmodified (easy install and uninstall).||Automatic translation is not the best practice and can result in poor translations.|
|Translation is automated.||Typically users are unable to change the translation produced.|
5. Each language in its own WordPress installation (e.g. Multisite Language Switcher, Multilingual Press, and Zanto)
Using the WordPress Multisite installation, a separate site is created for each language you plan on supporting. Each site is configured to use the same theme and plugins. Translation relationships are maintained among the different sites as updates are made to the source language.
|Each language site is a regular WordPress website.||Additional administrative responsibilities.|
|If the plugin fails, the sites continue to work as normal.||If the plugin fails, new content relationships are not created.|
Choosing the right multilingual approach
Choosing the most suitable multilingual plugin is no trivial matter and should be given the time it deserves. Each approach has its pros and cons and should be evaluated against your specific needs using the following as metrics:
- The development team’s skills sets
- The level of customizations to be added to your WordPress website in addition to multilingual support
- The number of plugins you plan to use and how well the approach works with them
- Is the WordPress Multisite a vial option for your project along with the administration it requires
- The translation workflows to be implemented on your website
- Will you be adopting a live translation approach or an offline approach using CAT tools
In any case, installing a multilingual plugin is a considerable investment and should not be done directly on your LIVE website on a first-time basis. It would be a good idea to first create a separate Development site (migration of your LIVE site). Once you have verified that everything works correctly between all the required plugins and the theme, only then should you deploy to the LIVE production environment.
In summary, a thorough walk-through of the pros and cons of each of the different plugin types along with fully understanding your requirements are critical in determining which approach will be the best fit for your project.
GPI Resources on Multilingual CMS and Connectors
GPI offers custom CMS translation services connectors to a variety of web content management systems and client relationship management systems in order to streamline localization workflows and access to translation project information across your enterprise. For more information, check Multilingual CMS Translation Connectors.