- 10/31/12 20:19:53 (2 years ago)
- 1 edited
r378604 r619595 14 14 Handles creation of multilingual content. 15 15 16 ** Plugin is under development. Please be patient. ** 16 This plugin is a work in progress and an effort to be an alternative for handling with multiple languages in a single WordPress translation. 17 18 Here is a description of how it works: 19 20 1. Current solutions and why I dont like them: 21 22 Q-Translate -> saves the content of the post int the same post_content field of the database, separating the languages with html comments.. When the theme outputs the content of a post, it gets filtered and displays only one language. Appart from that, this is an excelent plugin. But I junt cant sleep well at night knowing my database is like this... 23 24 WPML -> creates a lot of extra tables in a complex database structure and is associated with a translating service. In the top of that, the plugin does a lot more than juts adding the multi language support and claims itself as a cms solution for wordpress... I like plugin that do only one thing very well done. 25 26 2. How do I think that can be done? 27 28 2.1 translating posts 29 30 First, I think it can be done without adding any extra table or doing anything out of the database structure. 31 32 The approach Im using is to treat translations as post types. So, for instance, if I would translate my posts to spanish, there would be the native "post" post type and the plugin would add the "post_translation_es" post type. 33 34 In the edit posts screen, there would be an extra column called 'translations' that would show for each post if it already have the spanish translation. If it has, there is a button 'edit', if it dont, 'add'. If you go to the edit screen of the spanish posts, you would see the same thing, the other way round. 35 36 This part is already coded and working fine. 37 38 2.2 translating everything else (appart from taxonomies) 39 40 I think its nice to be able to translate everything on the site (The site title, te text of a text widget, etc). So what Im trying to do is to add a filter in get_option() and update/add_option() to allways check which language are we visiting right now (int the front end or the admin, does not matter) and allways look for a corresponding option in the current language. 41 42 For instance.. if you do a get_option('option_name') and are visiting the spanish site, it will try to find an option called 'option_name_es'. If there is not, it will get the default. Same thing when saving. 17 43 18 44 == Installation ==
Note: See TracChangeset for help on using the changeset viewer.