What I normally do when using this combination of plugins is to create one form per language. Easy and effective. You could also try qTranslate quicktags: [:en]English text[:ru]Фамилия. But much probably this will lead to some issues down the road.
One way is to use the WordPress i18n tools. I had to checkout WordPress trunk to make it work. On the command line: svn co http://develop.svn.wordpress.org/trunk once you have trunk somewhere, you’ll then want to call the makepot script. Again, on the command line: php /path/to/wordpress/trunk/tools/i18n/makepot.php wp-theme /path/to/your/theme/ After that script has run, the pot … Read more
__() “Retrieves the translated string from the translate() function” without echoing. _e() does the same thing but echos the output. For more information, take a look at these help articles: Internationalization Localization How to Internationalize Your Plugin Internationalization Security
Load translation files as late as possible for your plugin’s use-case. This allows other plugins as much time as possible to fully initialise. Why should you care about other plugins? Because they may be involved in the localisation process too. For example, changing the site language or filtering translation file paths. They can’t do those … Read more
The easiest way for me is to change language settings for main blog multiple times (as mach as many languages I need) and WordPress will load these languages automatically. And after that I go to Update page and update language packages (loads languages for themes, plugins, etc.)
tl;dr Usually you should be safe by offering your Plugins in English first. If you create a good userbase, you could do your own resarch as to find out which languages are most important to your clients. Another thing to consider would be, if you want to support latin-signs only or if you want to … Read more
The list is available in $GLOBALS[‘l10n’][ $text_domain ]. To get the looong list of translatable WordPress strings just use: print ‘<pre>’ . htmlspecialchars( print_r( $GLOBALS[‘l10n’][‘default’], TRUE ) ) . ‘</pre>’; Do not use these strings in your theme or plugin. They are internal, de facto private. They can change any time, even in minor updates. … Read more
I couldn’t find an answer so I ended up providing the solution. It wasn’t simple given that I am not an expert with wordpress nor with php but WordPress documentation is great so here is the solution: // Set the post language when loading up the page based on the store meta function ppl_set_post_language() { … Read more
esc_html_e() and esc_attr_e() are merely wrapper functions for _ to save a little bit of typing and help with readability. You’re right, there isn’t one for _n, so you’ll just need to do the “wrapping” yourself: printf( esc_attr( _n( ‘%s item’, ‘%s items’, $count, ‘textdomain’ ) ), number_format_i18n( $count ) );
You should move the po- and mo-file with the translation of your plugin outside your plugin’s directory. Whenever you update your plugin, your plugin files are replaced causing any file that is not part of the default plugin package to be deleted. (If you are translating your own plugin, you could as well add the … Read more