Como definir localidade em solicitações de ajax?

4

Estou desenvolvendo um site que pode usar tanto russo quanto inglês como idioma inicial. O tema traduziu strings em ambos os idiomas.

Agora, meu problema é que, sempre que eu uso um hook quando estou logado (por exemplo, hooking to post publish), as strings são traduzidas com base na localidade do usuário, não no website. Essas strings são salvas como metadados, então não posso alterá-las depois de serem salvas.

Isso também acontece quando alguém envia uma solicitação usando admin-ajax . A resposta usará a localidade do usuário em vez de front-ends. Então eu não tenho controle sobre isso.

Exemplo:

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

Eu quero que a string Hello! esteja no idioma do site, não no usuário.

Exemplo 2:

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

Isso economiza uma tradução de Hello! com base no idioma do usuário que publicou a postagem, o que não é legal, e deve ser baseado no idioma do site.

É possível definir tudo o que está acontecendo no tema (incluindo manipuladores ajax em functions.php) para usar a localidade do site?

    
por Jack Johansson 25.05.2017 / 06:34

1 resposta

2

(esse tipo de problema faz parte do motivo pelo qual minha recomendação padrão é não ter o front end com dois idiomas)

A principal razão para o problema é que o seu ajax retorna o texto. O AJAX deve ser tratado como API, que fornece valores de nível de máquina que o front end traduz para texto humano. Quando seu código é construído dessa forma, você também obtém um código melhor e mais flexível, já que sua lógica de negócios é desacoplada da apresentação.

Então, o que você deve fazer é incluir um valor para a tradução de texto no JS que manipula o AJAX (se você tiver pouco tempo de desenvolvimento, em vez do tipo inteiro de valores, use o texto em inglês como um "valor" em vez de texto simples. / p>

Isto obviamente incha o JS, pois é provavelmente melhor usar o wp_localize_script para enfileirar apenas o que é necessário com base no contexto, mas apenas tê-lo no próprio JS não é o fim do mundo. (este óbvio depende muito de como você obtém a tradução real, se estiver no usual arquivo .mo wordpress, então a única opção é a primeira).

(para pessoas que pensam wtf ?, mesmo se o seu site estiver em inglês, você provavelmente precisará fazer a localização de data e hora, e isso pode ser feito somente no lado do navegador, o mesmo vale para moeda, separador de milhares, A localização do lado do JS, apesar de não ser muito popular no WP agora, tem alguns problemas do mundo real que podem ser resolvidos quase somente dessa forma, portanto, estender a localização no JS deve ser uma coisa natural)

    
por Mark Kaplun 25.05.2017 / 18:56