Since the beginning of WordPress the desire to publish the content in different languages is huge. But the topic can quickly become complex, because not only the rendering of content in the form of text in different languages is an issue, we also have to take care of the meta data for content, for images that can be different depending on the language and the use of the admin interface in the preferred language. Thus, only a part would be covered depending on the requirements (a example on StackExchange) it would quickly become an project and WordPress would be just a “small” framework behind it. There are already many Plugins available, the different approaches – new tables in the system or separation of content for each language in a table entry to post, or other solutions.
All these solutions have their limitations, are inflexible and you go into a dependency that will be hard to get out and with each update of WordPress you have to check if the Plugin is still working or has any bugs with the new version. Therefore, I would suggest a solution that we use in our Inpsyde Team frequently for customers and maintained their strength in the flexibility, in extensibility and in its capacity to use the WordPress standard without changing the core or anything else. You can deactivate the Plugin at any time, you won’t lose anything, your website remains the same.
- 2/3, if not even more, of the worldwide population speak another language
- Go global with your company
- Better distribution of content
- Service for the client
- Search Engine Optimization
WordPress Multisite provides the solution already.
This makes the management of different instances, with similarities and differences, with the help of an installation possible. The exchange of data is possible via core functions, which get united and simplified via Plugin.
- WordPress Core Functions
- No dependency to Plugins
- Independent to WordPress development*
- Control Themes, Plugins at a central place, use them decentralized
- Low maintenance
- Seperating languages in Backend/Frontend (user dependent)
- Complete mirrored or in every content form seperated
- Subdomains or Subdirectories
- de.example.com, example.com/de
- Seperate Domains via Domainmapping
- example.de, example.com
- Free in development in design and usability
- Optimization not only on frontend, also lang-attributes, SEO
With all these requirements and benefits, we use a base that is available as a Plugin here: MultilingualPress . The plugin provides several convenient tools to use Multisite for the implementation of multilingualism.
This plugin simplifies the identification of different blogs in the network to a language and linking to other blogs, so that when you publish the content in blog A, it will create a post as draft in blog B. Thus, the articles are in relation, the system knows this and with the help of some functions, it may be used in the frontend and backend.
The Plugin provides in the article or page the ability to see a meta box with the content of the linked data, in the simplest case as a translation aid. Similarly, there is a widget that simplifies the frontend to change. In each blog you can be make some adjustments, assigning a flag and language.
WordPress Multisite provides the basis and with some adjustments, a clean, controlled solution exists for the use of WordPress in a multilingual environment. Now it’s up to you – use Multisite, Test the Plugin and give us a feedback.
This was our last door of our Advent Calendar. We hope you enjoyed it!
We wish you a Merry Christmas and thanks a lot for reading our posts!
27 responses to “Best Practice for Multilanguage WordPress Content? New Plugin!”
What are the benefits of this pluginin comparision of Wpml? Wpml looks like more advanced and user interface is better for multi languages.
@Frank: Bin sehr gespannt, werde es demnächst mal austesten. Wir haben mit WPML mehrere (auch große) Projekte umgesetzt und sind überhaupt nicht happy damit…
[…] WPEngineer wird heute die Erstellung von mehrsprachigem Inhalt thematisiert. Bei 24ways wird heute Frontendentwicklung als Handwerk […]
@jam: but the plugins create many custom tables, use many, many selects for date form db; not an default function from WordPress; an Update of WordPress is heavy and a risk. The code is more complex, hard for maintenance and the bigest problem is the functionality with WP; if the plugin stop the development, the blog has an problem; becouse the standard of WP was change.
@FRank (cannot see you comment here, but recieved it on email) If you could combine functionality of your plugin and user interface from wpml, then it would be a strong one!
By the way – what about string translation? I mean, WPML has a functionality for this and this is wery useful for developer. IT can translate strings in theme files easy.
Also, are ther solved the problem with same slugs in each language you need? For example – DE language can have post with slug /product name (www.blabla.com/de/product_name) and the same product nam client wants to see on english page f.e. http://www.balbla.com/en/product_name
WordPress does not allow you to careate same slug pages. What arre your approach to this?
@jam: this job doing WP Multiiste; different domains; with a plugin also first level domains; example.com and exampl.de or the default of WP with subdomian de.example.com and ru.example.com or with forderstructures: example.com/de/product and example.com/ru/product. This is also possible with different languages in one country-area; like swiss: example.com/ch_fr/product, example.com/ch_de/product and many more.
@jam: for translation in theme-files; if the theme write with a WP codex, standard, thant can write easy different languages in gettext files (mo/po) with the plugin Codestyling Localization. For bad themes with bad syntax and codex; maybe! we will include this in the pro plugin; but ist not so fast and performant; the strings are in the database.
@Frank Yes, strings are in the database, but this is usefull sometimes. And sometimes this is acceptable.
I also think that with WPML it is as good as it gets. The plugin is under constant development, so there are really no worries with an update of WP, they have their plugin ready for it long before the update takes place.
Recently they completed a tutorial on how to set up WPML on Multisite (http://wpml.org/documentation/essential-multilingual-plugins/multilingual-site-network-with-domain-mapping/), so instead of making a Multisite install specifically to be able to run your site in multiple languages, you can run WPML on Multisite and choose which sites you want to have multilingual and which in one language.
Before WPML existed your solution would be a great one, now with WPML however, I think you unnecessarily complicate things.
@piet Frank is doing a good thing. There must be more than one great plugin for multilanguages out, not only Wpml (the best one). Those arguments against wpml (fb structures, additional queries) are correct, but this is important in cases when you try to create a very, very complex sites. In my opinion in such cases try to avoid free cms, create it from scratch.
@jam, there was another plugin to enable multilingual functionality, qTranslate, but last time I heard it no longer is compatible with the current WordPress version. WPML immediately noticed that too and came with a qTranslate to WPML Importer (http://wpml.org/2011/12/qtranslate-to-wpml-importer/); that is one of the things I meant with “under constant development”.
I agree with you that competition is a good thing, I just think that going the Multisite way to enable multilingual functionality is not the ideal way.
@piet agree, multisite is just a workaround.
i personally like Multilingual Press’ aproach
Wow! Great plugin, just what I needed. I’m also using Multisite to make different languages, because this is the only way to make a real, complete site in different language.
@jam and @piet: think all the possibilities, you can use different plugins, themes with this solution. And the compatibility with all plugins is also done, because every site is a seperate site.
The maintenance and the work at the beginning is more with this solution, but it is worth the time.
So everything is possible with this plugin, what is possible with WPML, but not everything is possible with WPML, what is possible with this plugin.
@surbma seperate sites for small business – no no no solution. Hard to maintenance.
@jam the question is, what are the needs of the clients. If WPML is enough, there is no need for this solution. This way is for websites with greater needs.
Just a very simple example on a multisite network: it is not possible to have different languages on different domains with WPML.
A very interesting plugin. It would be great, if you could combine the basic idea of your plugin and the editing view of qtranslate to enable a user to add several language versions using the same editing view. This way the link between the posts would be created automatically in the process.
The plugin seem don’t work with custom post type … Someone have a solution?
I found the issue… juste add your custom post type after others, on line 450 of the file “inpsyde-multilingualpress.php”
Work fine !!
I don’t believe flags should be used as a language selector – flags represent countries not languages.
@FRank : How to add Gujarati language in Multilingual Press plugin ?
what about know for qTranslate plugin ? why are not work in wordpress 3.3.1 ? plz some help..
The plugin works in 3.3.1 and greater; but its important, that you have install an Multisite. The language list will we create more items, yes.
I dont like qtranslate; different languages in one post is not great: to heavy for the database.
@FRank : thanks, for this your important think. so i can use all time Multilingual Press plugin.
Hi, one question, does it support custom post types? taxonomies?
@dimitris: not on default; you must add an an small custom snippet and add your custom post type via filter hook to the plugin.
thank you for your reply , i will try to create a test site for this as i am really interested in the method.