codestyling

Found an subsequent error within the sidebar login plugin!
During testing my fix, I also used a WordPress single install, that uses a subfolder install but still running at top level domain.
Having such an install, the plugin won’t work either caused by warnings issued by WP ajax core. Seems related to ajax call user identification within the admin-ajax.php from WordPress itself.

Should be handled within WP Core and also the login plugin author could request the nopriv action directly instead.

after all this plugin is for languages not for countries

Yes and no. 🙂
Lets say german (my native language). The language is “de” but spoken in at least 3 counties:
“de_AT” -> Austria
“de_DE” -> Germany
“de_LU” -> Luxembourg
and will have differences within translations. So it’s essential to have the right country to get the right differences.
Ask US if they are ammused to get a GB translation even if both are englisch 😉

Nevertheless a more sophisticated fallback would be worth to provide. I will check, what impact this will have (beside the aboves shown) and potentially implement it. Thanks for responding.

No extension required, use build in filters within your own multisite must use plugin for this purpose:

apply_filters( 'default_option_' . $option, $default );

in this case it will look like:

function my_defaults($default) {
   //patch here the StdClass members
   return $default;
}
add_filter( 'default_option_wp-native-dashboard', 'my_defaults' );

will only be called, if the option was not at the database.

Could you please give me the locale used for the language?
RTL is not used normally for “zh_..” locales.

Has been added to stylesheets and will be available with next update.
Thanks for reporting.

There a several point to meet to get WordPress showing the es_ES translations:
1.) your wp-config.php should have WPLANG set to “es_ES”
2.) your folder /wp-content/languages/ should have the appropriated WordPress Core translation files for es_ES (WordPress itself)
3.) your Theme should have the correct es_ES translation files at the themes folder defined by author of theme (should be handled by my plugin)
4.) you need the *.mo files to get translations show, don’t forget to generate the mo-file for the theme.

If you meet this conditions, you should get the spaninsh translations. The only things you won’t get, are:
– if Theme author did accidentally use the textdomain “default” within the theme, you will not get this translations as long as they are not contained at the WordPress core translations.
– if Theme author used copied code with different textdomains for other Themes/Plugins you won’t get the translations
This 2 points can only be changed by editing the Theme and set the correct Themes textdomain. This have to be done preferably by the Theme author. My Plugins warns about more than one textdomain within a Theme or Plugin. If you get this warning during translation, it have to be solved by Theme author.

Has been solved in meanwhile. It’s a handling issue rather than a plugin issue. May i have to enlarge the documentation how to use it.

The translation you have is for version 1.2.1 of the theme but you have version 1.3 of theme. The author did change quite a lot of texts, so your previous translation doesn’t match the new theme 100%. Texts not longer matching are threat as none translated and this leads to “loosing” approx 200 translation strings.
The only way to handle this is to compare the old *.po file with a fresh scanned one and adjust the msgid strings appropriated. Afterwards the translation can be adjusted using my plugin as required.