4

I'm developing a website that can use both Russian and English as front-end language. The theme has translated strings in both languages.

Now my problem is, whenever i use a hook when i'm logged in (for example hooking to post publish), the strings are translated based on user's locale, not website's. These strings are saved as metadata so i can't change them after being saved.

This also happens when someone sends a request using admin-ajax. The respond will use user's locale instead of front-ends. So i have no control over it.

Example:

add_action('wp_ajax_my_ajax', 'my_ajax_function');
function my_ajax_function(){
    _e('Hello!','text-domain');
}

I want the Hello! string to be in the website's language, not user's.

Example 2 :

add_action( 'publish_post', 'example_hook' );
function example_hook($post_id){
    $data = __('Hello!','text-domain');
    add_post_meta($post_id, 'my_metadata', $data);
}

This saves a translation of Hello! based on the language of the user who published the post, which is not cool, and should be based on the language of the website.

Is it possible to set everything that is happening in the theme (including ajax handlers in functions.php) to use the website's locale?

2

(this kind of issues is part of why my standard recommendation is to not have front end with two languages)

The core reason to the problem is that your ajax returns text. AJAX should be treated like API which provide machine level values which the front end translate to human text. When your code is built like that, you also end up with a better and more flexible code since your business logic is decoupled from the presentation one.

So what you should do is include a value to text translation in the JS handling the AJAX (if you short in development time, instead of integer type of values use the english text as a "value" instead of plain text.

This obviously bloats the JS therefor it is probably better to use the wp_localize_script to enqueue only what is needed based on context, but just having it in the JS itself is not the end of the world. (this obvious depends a lot on how do you get the actual translation, if it is in the usual wordpress .mo file, then the only option is the first one).

(for people that think wtf?, even if your site is in english you most likely need to do date time localization, and that can be done only on browser side, same goes for currency, thousands separator, so the idea of JS side localization, while not very popular in WP right now, have some real world problems that can be solved almost only in that way, therefor extending the localization in JS should be a natural thing)

  • This doesn't only happen in ajax request. I've added another example that is not related to ajax at all. – Jack Johansson May 25 '17 at 17:16
  • @JackJohansson, this is why the first sentence of the answer, multisite with a site per language/locale is IMO the cleanest way to do such things. – Mark Kaplun May 25 '17 at 18:39
  • Unfortunately i don't have control over that. This is a theme that the user chooses to install, so i can't rely on them installing it on a multisite and configure it. – Jack Johansson May 25 '17 at 18:41
  • ... and the answer to your second example is similar in nature to the first one. store only value in the meta, convert it to text only on html output. – Mark Kaplun May 25 '17 at 18:42
  • Yeh I know.... clients can't live with them and can't without them – Mark Kaplun May 25 '17 at 18:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.