Follow for free plugins, new theme releases and theme news
Plugin Description
See https://wordpress.org/extend/plugins/wpml2wpmsls/
WPML stores each entry as a separate post and uses some custom tables to connect the translations.
If you de-activate the plugin or have issues with functionality related to version updates, you get one site with multi-lingual confusion.
See Getting WordPress to speak your language for more details how /
why using a WordPress MultiSite / Network is becomming the recommended strategy for multilingual sites. At least until it is fully supported in core.
This plugin:
- Converts the WPML translation records into meta fields on actual posts or post types
- Helps with the export/import to your new WPMS site the data.
- Restores the meta data back to options so that Multisite Language Switcher will recognize all your translations.
You will need to handle conversion of any strings, .po files or other language elements separately.
Download
You can download the latest stable version of WPML2WPMSLS from the WordPress
Plugin Repository at https://wordpress.org/plugins/WPML2WPMSLS/>
Help and Support
Please post questions, request for help to the WordPress plugin forum dedicated to it: https://wordpress.org/support/plugin/WPML2WPMSLS.
TO-DO’s
= Complete the enhancements for WordPress export. =
Currently, if you have 100 posts translated into 3 languages, you would export all posts once, import that same .xml file into 3 sites and delete the 200 from each
site which are not the corresponding language. Then, you would be able to run steps 7 and 8 of the usage instructions above. With an enhanced WordPress export feature
built into this plugin you would be able to specify the language for export to filter files. In that same scenario, you would run 3 exports (100 posts each of unique
language) and import each language-based export file into the new sites before running the same steps 11 thru 13 above.
Source and Development
WPML2WPMSLS welcomes friendly contributors wanting to lend a hand, be it in
the form of code through SVN patches, user support, platform portability
testing, security consulting, localization help, etc.
The [current] goal is to keep the plugin self-contained (ie: no 3rd-party lib)
for easier security maintenance, while keeping the code clean and extensible.
Active development for the plugin is handled via GitHub with releases being published to the WordPress Plugin Repository:
Project History
Originally started because, well, you know…Efficiency or lazyness – your pick.
Screenshots
No screenshots provided
