When adding _x to the keywords, try it this way:
This tells the parser to watch out for _x and to take the first argument as msgid and the second argument as a comment, which will then be recognized as context by poEdit and inserted as msgctxt.
Oddly enough, my poEdit then shows me the msgid twice in the "new/old" messages window. However, in the ...
You could hook into the action switch_blog. You get the new blog ID as the first argument here. But loading the complete translation files here is expensive, you also have to restore the old files after that.
WordPress does not use native gettext functions, but some custom code that is much slower. See #17268. The performance penalty for that would be huge.
I would opt for readability and use a rather verbose solution:
if ( 1 == $hours and 1 == $mins )
_e( 'One hour and one minute', 'your_text_domain' );
elseif ( 1 == $hours )
printf( __( 'One hour and %d minutes', 'your_text_domain' ), $mins );
elseif ( 1 == $mins )
printf( __( '%d hours and one minute', 'your_text_domain' ), $hours );
Just add the full string of the plugin name into the plugin's text domain. WordPress looks this up automatically. Same with Description, PluginURI, Author and AuthorURI.
See the internal function _get_plugin_data_markup_translate.
The string extractor in Glotpress (and my own plugin Loco Translate) adds these header strings automatically to new POT files.
One error: the function is load_theme_textdomain(), not load_textdomain(). The former is used for Themes to define/load a textdomain; the latter is for core, I believe. (Plugins have an analogous function, load_plugin_textdomain().)
load_theme_textdomain( get_theme_text_domain(), get_template_directory() . '/languages' );
Best way would probably be to use the built in Internationalization function in WordPress. This will then translate according to the language pack being used.
The "U" character to a date() call gives the unix timestamp, which is just what you need in this case, for passing to date_i18n().
echo date_i18n('j F Y @ g:i a', $item->get_date('U'))...
To find the answer to this question, you just need to look at how WordPress retrieves the translations. Ultimately it is the load_textdomain() function that does this. When we take a look at its source we find that it creates a MO object and loads the translations from a .mo file into it. Then it stores that object in a global variable called $l10n, which is ...
WordPress doesn't quite have a practice of localizing something that isn't core/plugin/theme.
My educated guess would be that it will work just fine with same concepts, but you will have to write custom loading logic. Use lower level load_textdomain(), since higher level functions are meant for plugins/themes specifically.
As long as you determine and load ...
With honor to @Wyck's link, I managed to add a language variable by adding an action hook to init and set the locale into cookie using PHP's setcookie() function.
For details, visit: Setting custom cookies in Wordpress