Title: plugin strings in admin not translated
Last modified: August 24, 2016

---

# plugin strings in admin not translated

 *  Resolved [xnau webdesign](https://wordpress.org/support/users/xnau/)
 * (@xnau)
 * [11 years ago](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/)
 * I have a custom plugin running on a site using qtranslate-x. I’m passing all 
   display strings through the WP translation function __() and those strings are
   using the language tags like this: [:en].
 * On the frontend it’s no problem, everything is translated, but in the admin, 
   the strings are untranslated. This was working when I was using the original 
   qtranslate, but qtranslate-x doesn’t translate those strings in the admin.
 * What do I need to do differently to get qtranslate-x to translate those strings
   in the admin?
 * [https://wordpress.org/plugins/qtranslate-x/](https://wordpress.org/plugins/qtranslate-x/)

Viewing 15 replies - 16 through 30 (of 35 total)

[←](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/?output_format=md)
[1](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/?output_format=md)
2 [3](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/3/?output_format=md)
[→](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/3/?output_format=md)

 *  Plugin Author [Gunu](https://wordpress.org/support/users/grafcom/)
 * (@grafcom)
 * [10 years, 12 months ago](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/2/#post-6118760)
 * > Most themes/plugins use __() translation by default, otherwise you may ask 
   > theme author to make this little modification for each field you need to be
   > translatable.
   >  Also, proper way for them to pass a variable through a filter,
   > and **then you can put the filter name in “Custom Filters” configuration to
   > integrate their plugin**. This is the best and proper way which does not require
   > any knowledge about q-X.
 * Can you find the filters and then put in the right place in de Settings – Languages–
   Custom Integration?
 * Read also this:
    [Is it possible to translate theme custom fields?](https://qtranslatexteam.wordpress.com/faq/#HowToTranslateCustomFields)
   and this [Can I enable Language Switching Buttons on my plugin custom page?](https://qtranslatexteam.wordpress.com/faq/#CustomPluginLSB)
 *  [Boyan Raichev](https://wordpress.org/support/users/studioreforma/)
 * (@studioreforma)
 * [10 years, 12 months ago](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/2/#post-6118765)
 * Maybe I am not explaining things well. There are no custom filters – I am talking
   about the standard wordpress function __() which triggers the ‘gettext’ filter.
 * The problem is that these two functions:
    add_filter(‘gettext’, ‘qtranxf_gettext’,
   0); add_filter(‘gettext_with_context’, ‘qtranxf_gettext_with_context’,0); are
   now only loaded on the front end, so any plugins or themes that use __() on the
   backend without a domain (so in our case with [:] language tags) would not work
   in the admin area anymore.
 * While using classes and language switching buttons might be more user friendly,
   there are cases (like printing an invoice in my case) where they cannot be used,
   so the combination of __() and language tags is needed.
 *  Plugin Author [John Clause](https://wordpress.org/support/users/johnclause/)
 * (@johnclause)
 * [10 years, 12 months ago](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/2/#post-6118766)
 * This is by design. Admin pages are supposed to have the strings untranslated,
   otherwise it will be impossible to make them respond to Language Switching Buttons(
   LSB) and/or to edit them, if needed.
 * It is unusual and not recommended to use code like this `_e('[:bg]test1[:en]test2')`.
   Such static translation is normally handled by .po/mo files. q-X is designed 
   to handle dynamic translations.
 * It only makes sense to do so if you wish those strings to respond to LSB, which
   is possible with the latest version from [GitHub](https://github.com/qTranslate-Team/qtranslate-x).
   Read [Integration Guide](https://qtranslatexteam.wordpress.com/integration/),
   look for ‘display’ encoding. But, once again, it is better to use po/mo files
   framework in such a case.
 *  Thread Starter [xnau webdesign](https://wordpress.org/support/users/xnau/)
 * (@xnau)
 * [10 years, 12 months ago](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/2/#post-6118768)
 * I’m sorry, but the broad assertion that such strings shouldn’t be translated 
   doesn’t allow for much flexibility. If a string is meant to be untranslated, 
   then the code sinply prints the string without going through the translation 
   function.
 * As a developer, I need to be able to show both translated and untranslated strings
   in the admin, and I need standard way of doing so that does not only work with
   a particular trnaslation plugin. Static translations (such as __(‘string’) ) 
   are in my experience a generally compatible way to make strings available for
   translation where the user has defined a string with language tags. (therefore
   cannot be placed in a PO file) They would expect to see it untranslated in a 
   context where the string is to be edited, but in other contexts, that is not 
   desirable.
 * Since using a filter is the method offered here, the workaround I intend to use
   is to set up a filter that loops through the translation function, I’m hoping
   it will be compatible with most translation plugins.
 *     ```
       <?php
       // use this where stranslated strings are to be displayed
       echo apply_filter('plugin_admin_string_translate', $string);
       // this callback is set up in the plugin
       add_filter('plugin_admin_string_translate', 'plugin_admin_translate_string');
       function plugin_admin_translate_string($string) {
          return __($string);
       }
       ?>
       ```
   
 *  Thread Starter [xnau webdesign](https://wordpress.org/support/users/xnau/)
 * (@xnau)
 * [10 years, 12 months ago](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/2/#post-6118769)
 * sorry…the WP function is ‘apply_filters’ not ‘apply_filter’
 *  Thread Starter [xnau webdesign](https://wordpress.org/support/users/xnau/)
 * (@xnau)
 * [10 years, 12 months ago](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/2/#post-6118770)
 * …and I spoke too soon, because it turns out the “custom filters” are not active
   in the admin, so that won’t work.
 * What do you suggest developers do to show translated strings that aren’t in PO/
   MO files in the admin?
 *  [Boyan Raichev](https://wordpress.org/support/users/studioreforma/)
 * (@studioreforma)
 * [10 years, 12 months ago](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/2/#post-6118772)
 * [@john](https://wordpress.org/support/users/john/) Clause,
    we are not talking
   about static content, but about user-created content, therefore it is not possible
   to work with PO/MO files.
 * The LSB way is good in scenarios where the admin part is only for entering the
   information and the front-end for displaying and using that information. But 
   there are many use-cases when this information is also needed on the admin part.
 * __() is the standard WP function for translations. I still cannot understand 
   why would a translation plugin decide not to follow this practice on the admin
   site. Performance could not be an issue here, after all speed is not the top 
   priority for the admin area.
 * If I copy the gettext filter and the respective function from frontend to some
   of the other files, so that it is loaded in the backend (just like it used to
   be before version 3.3) – everything works correctly, LSB work. So what you say
   that
 * > Admin pages are supposed to have the strings untranslated, otherwise it will
   > be impossible to make them respond to Language Switching Buttons (LSB) and/
   > or to edit them, if needed.
 * is not affected by running the filter for __()…
 * `add_filter('gettext', 'qtranxf_gettext',0);`
 *  Plugin Author [John Clause](https://wordpress.org/support/users/johnclause/)
 * (@johnclause)
 * [10 years, 12 months ago](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/2/#post-6118775)
 * 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](https://qtranslatexteam.wordpress.com/integration/)
   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](http://vc.wpbakery.com/)”
   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](https://github.com/qTranslate-Team/qtranslate-x/issues).
 *  [Boyan Raichev](https://wordpress.org/support/users/studioreforma/)
 * (@studioreforma)
 * [10 years, 12 months ago](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/2/#post-6118776)
 * While it is true that __() is not originally meant for dynamic translation, WordPress
   is not at all meant for multilingual sites. It is only properly geared for single
   language sites with the ability of having different langs for this single lang.
   People still need multilingual sites though and __() is the only universal function
   that would allow plugin and theme author to create plugins and themes that work
   well with multilingual sites.
 * So for me it is plugins like WPBakery that do not follow the standard gettext
   approach and need to be changed, rather than qtranslate.
 * What you suggest will of course work, but it is not at all user-friendly and 
   I don’t find it to be a strong and elegant solution. Seeing that several other
   people have had the same problem like me maybe it will make sense to let users
   have the option to translate gettext in the admin within the q-x options, like
   a compatibility function…?
 *  Plugin Author [John Clause](https://wordpress.org/support/users/johnclause/)
 * (@johnclause)
 * [10 years, 12 months ago](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/2/#post-6118778)
 * 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?
 *  [Boyan Raichev](https://wordpress.org/support/users/studioreforma/)
 * (@studioreforma)
 * [10 years, 12 months ago](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/2/#post-6118784)
 * Sounds good.
 * As I said – these problems with __() do exist, and they WP’s fault – there are
   no proper functions for multilanguage sites. So perhaps we should also post a
   suggestion to WP that a specific function is created for dynamic translation 
   of strings? Like for example _s($str) , so multilanguage plugins can hook up 
   to it and translate according to the language tags they have decided to use. 
   Then it will be quite clear to plugin developers: __() is for use with a domain
   and po/mo files, while the new function is for strings that contain all languages
   within.
 *  Plugin Author [John Clause](https://wordpress.org/support/users/johnclause/)
 * (@johnclause)
 * [10 years, 11 months ago](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/2/#post-6118798)
 * The new version at [GitHub](https://github.com/qTranslate-Team/qtranslate-x) 
   has those filters, described [here](https://raw.githubusercontent.com/qTranslate-Team/qtranslate-x/master/inc/i18n-interface.php).
   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/](https://qtranslatexteam.wordpress.com/integration/),
   which describes these ideas.
 * Any contributing remarks are appreciated.
 *  [Boyan Raichev](https://wordpress.org/support/users/studioreforma/)
 * (@studioreforma)
 * [10 years, 11 months ago](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/2/#post-6118803)
 * John, thanks for the quick response. It sounds great, I will test it later this
   week and report back if I run into some issues
 *  [Ariakan](https://wordpress.org/support/users/ariakan/)
 * (@ariakan)
 * [10 years, 11 months ago](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/2/#post-6118811)
 * I installed the last version from Github. I still have a problem :
 * **[http://i.imgur.com/255bQrk.png](http://i.imgur.com/255bQrk.png)**
 * I used Types to create this custom post type : [https://wordpress.org/plugins/types/](https://wordpress.org/plugins/types/)
 *  Plugin Author [John Clause](https://wordpress.org/support/users/johnclause/)
 * (@johnclause)
 * [10 years, 11 months ago](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/2/#post-6118813)
 * [@ariakan](https://wordpress.org/support/users/ariakan/): Can you read PHP? Could
   you figure out which filter needs to be enabled? It is very likely WP passes 
   that value through a filter before putting it on the screen. Could you find a
   place in the code where this value is printed on the screen and let us know?
 * Currently, q-X enables configurable filters on front-end only, but this will 
   change soon.

Viewing 15 replies - 16 through 30 (of 35 total)

[←](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/?output_format=md)
[1](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/?output_format=md)
2 [3](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/3/?output_format=md)
[→](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/3/?output_format=md)

The topic ‘plugin strings in admin not translated’ is closed to new replies.

 * ![](https://s.w.org/plugins/geopattern-icon/qtranslate-x_f9f9f9.svg)
 * [qTranslate X](https://wordpress.org/plugins/qtranslate-x/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/qtranslate-x/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/qtranslate-x/)
 * [Active Topics](https://wordpress.org/support/plugin/qtranslate-x/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/qtranslate-x/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/qtranslate-x/reviews/)

 * 35 replies
 * 6 participants
 * Last reply from: [Boyan Raichev](https://wordpress.org/support/users/studioreforma/)
 * Last activity: [10 years, 7 months ago](https://wordpress.org/support/topic/plugin-strings-in-admin-not-translated/page/3/#post-6118869)
 * Status: resolved