herrvigg

At least did you try the solution i proposed? Maybe polylang also uses the gettext filter and this would solve the problem for everyone.

Imo the plugins should stick to the standard WP behavior. If you begin to write if function_exists(xxx) then you’re doing it wrong. Think if every plugin had to know what other plugins do… You can do it temporarily because one plugin is not respecting the workflow and you wait for a fix, but it’s a bad practice. The whole concept of WP is based on filters and the plugin should simply handle those.

I don’t know exactly how the other plugins work, but this is what qTranslate-X does through the gettext filter (and not wp_translate, sorry). Here is the WP reference.

https://codex.www.ads-software.com/Function_Reference/_2

And how qTranslate-X deals with it (line 1130): https://github.com/qTranslate-Team/qtranslate-x/blob/master/qtranslate_frontend.php

About Super Socializer, it handles the translation well for some fields, but not for theChampLoginOptions[‘title’], theChampLoginOptions[’email_popup_text’], and maybe others. It assumes the language is fixed when the admin defines the settings, which is a bad assumption as the clients can select a different language. The simplest way to fix it is to call the standard function __(.

• This reply was modified 7 years, 3 months ago by herrvigg.

hello,
nice you wrote about this, i’ve just been trying to solve the same problem from yesterday! ^^

The main issue is that the plugin saves most of the label from the admin pages and stores them in the options, but displays a few ones of them without calling the standard translation __(xxx) when sent to the client. This assumes the language will not change on client side, which is a (sad) limitation. The labels should always be translated depending on the client locale settings, not limited to the language used by the admin of the website.

@jonmoore: it seems you picked the source file from admin/social_login.php. The translation is only considered when the default options are saved during the installation of the plugin.

Imo, the good way to handle it is rather in inc/social_login.php which outputs the login fields to the client. Output the translated label with __($theChampLoginOptions['title']).

Here is the whole piece of code:

if(isset($theChampLoginOptions['title']) && $theChampLoginOptions['title'] != ''){
					$html .= '<div class="the_champ_social_login_title">'. __($theChampLoginOptions['title'], 'Super-Socializer') .'</div>';

There might be others such as theChampLoginOptions[’email_popup_text’] when the popup is shown. The right output should be __(theChampLoginOptions['email_popup_text']). The author of the plugin should go through all of them.

Still, if the admin wants to change the labels in the settings, he can, but then the translation will not be guaranteed as the new entry might not be found. In theory the translation files should also be changed accordingly, but they should not as they are provided by the plugin itself. For dynamic translation you need another plugin.

About qTranslate-X, it is not recommended to call the qtransxf_xxx functions directly. You should stick with the standard __(xxx) functions because qTranslate will do the translation from it thanks to filters (wp_translate). If you do the change in the proper file i think it should also work for you. This allows you to enter a string like [:en]my english text[:fr]my french text[:]. This means you don’t rely anymore on the .po / .mo files but on qTranslate processing.

TL;DR the Super Socializer plugin should only stick to the standard WP translation with __(xxx) and do it for every text field sent to the client (not only admin side!). Calling specific functions and multiplying the cases is not a viable solution. Other plugins can deal with it through the wp_translate filter.