plugin strings in admin not translated

Function __() is originally not meant for dynamic translation. The original qTranslate did its trick to filter it through a q-translating function, which helps to get more stuff at front-end to be translated, but if they did not do it the most would still be possible to make work anyway.

The proper way for themes and plugins is to always pass important key string, which may need translation or whatever other alterations through a named filter. Then q-X can have this filter in “Custom Filters” or in JSON configuration file. Moreover, if everybody follows the WP standard well, then _() should not be ever used on a dynamic content, only on static. Dynamic content should always be passed through an appropriate filter instead. This would be the most efficient way, without running a heavy code of __() without a necessity. Function apply_filters leaves much smaller efficiency footprint if runs empty.

we are not talking about static content, but about user-created content, therefore it is not possible to work with PO/MO files

If you, as a developer, need to show some dynamic string translated on your custom admin page, then you can employ the same method as it is done at front end. Pass those values through a filter and call qtranxf_useCurrentLanguageIfNotFoundUseDefaultLanguage on that filter. Using direct call to qtranxf_useCurrentLanguageIfNotFoundUseDefaultLanguage is not recommended, because then you would have to make a test on q-X presence in every place. The only exception is if your plugin/theme requires q-X on activation. Having filter is easier to maintain, since then you may test for q-X presence at one init-like place only and connect an appropriate filter if needed. If your user does not use q-X, then the rest should work as usual.

However, most likely you will want such a dynamic string to respond to LSB then, even if it is not modifiable. Then the first draft of Integration Guide explains how to achieve that.

I still cannot understand why would a translation plugin decide not to follow this practice on the admin site

Because some plugins, for example, “WPBakery Visual Composer” get unrecoverably broken otherwise. They passed some values via ‘__()’ in places where q-X still needs them to be raw-multilingual. So we decided to apply the explained approach as it seems to be much more compatible with WP standard: admin side gets multilingual strings untranslated and does with them whatever it needs to.

And remember, this is a community project, if you have any ideas on how to make the things better, submit them at GitHub.

It bothers me that __() does tons of other things like searching through mo database, while we know for sure from the beginning, that the string is not there. Would not it be reasonable to exclude this unnecessary work? I understand that sometimes we accept overhead as unavoidable evil, but in this case it is avoidable. qTranslate receives a hard to reject critics for doing too much of excessive unnecessary overhead. This is an attempt to reduce it.

I agree that what I described is less user friendly, and that is why it came to my mind that I can add a few standard filters like

'qtranslate_text'
'qtranslate_term'
'qtranslate_url'

and maybe a few more or that kind for different situations, available at both, front and admin sides, and then you would need to write code like this apply_filters('qtranslate_text', $str) instead of __($str), which would be equally user friendly.

I am really reluctant to accept unnecessary overhead from _() in the places where it is surely not really needed.

This way you do not need to implement your own filters and to test presence of q-X, the filters will be automatically connected for you when q-X is active. You may already now add such filters in your development and remove them when new version of q-X is released.

It seems to me that those filters is a better solution than a new option to turn on excessively unnecessary filtering of __(). What do you think?

The new version at GitHub has those filters, described here. So far, I made three functions:

$text = apply_filters('translate_text', $text, $lang=null, $flags=0);
$term = apply_filters('translate_term', $term, $lang=null, $taxonomy=null);
$url  = apply_filters('translate_url', $url, $lang=null);

We would greatly appreciate if you guys find time to test it.

WP’s fault – there are no proper functions for multilanguage sites

It is not “fault” exactly 😉 , they simply could not apparently decide which way to implement it and left it to plugins for now. They did a great job for static translations though. There is a number of plugins dealing with dynamic translations in a different way. At some point, one of them may become exceedingly more popular than others, and then WP will employ it for their framework.

I realized that this method of integration may actually be applicable to any multilingual plugin, regardless to what they do underhood, that is why I decided to name them in a neutral way, without ‘q’.

Similarly, the new JSON configuration file, which is coming up, is also applicable to any multilingual plugin. Once it is complete for some plugin to be integrated, any multilingual plugin could potentially use it to internationalize a plugin/theme. Implementation may be different, but information on what needs to be internationalized is the same for everybody, and it may be provided in those JSON-encoded files for each theme or plugin.

There is a draft-document: https://qtranslatexteam.wordpress.com/integration/, which describes these ideas.

Any contributing remarks are appreciated.