Tag Info

New answers tagged

0

For starts, I would follow @Fischi list, even if I believe is not very precise because of the lack of reliable source (in the sense that they would really reflect the both the actual and potential use of these languages). Also, remember that these numbers maybe reflect the LACK of localized plugins and maybe an increased availability of plugins in, let's ...


3

load_theme_textdomain() needs an absolute path to the directory, so you should set your THEME_URL like so define("THEME_URL", get_template_directory()); define("TRANSLATION_URL", THEME_URL . "/languages"); It wasn't working for you because get_bloginfo("template_url") is an URL and not an absolute path on your server.


5

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 offer all kinds of language signs. The big prolbem (for me) ...


2

Before I start, you should never ever use extract(). It is unreliable, and extremely hard to debug when it fails. For this specific reasons, it was (almost) completely removed from core and the codex. For more complete details, see trac ticket 22400. Along with query_posts, these are the two most commonly used and two worst functions to use. Lets get back ...


3

The define('WPLANG', 'ru_RU'); in the wp-config.php is no longer needed, as WordPress stores this value in the database (starting from version 4.0). However, I suppose your problem is actually something different. Your Steps: Add a filter to locale To ensure your language is set correctly, use a code like this: add_filter( 'locale', 'f711_set_language' ...



Top 50 recent answers are included