Boyan Raichev

Just a delayed feedback…
So, the new Integration options (classes and json conf) worked great for me on simpler projects. I still have issues setting them up to work with my shopping cart. One problem is for example when sending a shipping confirmation email. This happens on the admin side, since it’s triggered by the store manager, but since it’s generated on the server (rather than the browser) it’s not possible to use language buttons. Similar when generating an invoice, which in my case is set up in a way that language buttons are not an option. Anyway, I am just moving the gettext filter from the frontend file to the qtranslatex-core file after every update, so I can keep using __() in the admin for the time being. In the future, I will probably rework those parts of the shopping cart, so that they can be used with language buttons (rather than depend on the current language of the backend,as they do now).

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

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.

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…?

@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);

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.

I already tried turning all other plugins off…

In Qtranslate X release notes for last version it says:

Enhancement: filters ‘gettext’ and ‘gettext_with_context’ are moved to qtranslate_frontend.php, as they are not needed on admin side.

So __(‘[:en]test[:de]test2’) in admin would no longer work… I believe @xnau is referring to the same problem, which is why I wrote here.

@gunu – the problem seems to be that the gettext filter is now moved to qtranslate_frontend with version 3.3… So Qtranslate X just does not work on __() calls in the admin any more… I find this veeeeery strange. __() calls were the way that plugins could let users have multilingual content with different multilanguage plugins. One should not be supposed to develop for a specific multilanguage plugin?–?my code should work with all major multilanguage plugins.

Here is the use-case in more detail: I have a shopping cart and site user can enter custom payment methods, for example. These payment methods have a name. So the user would be able to name them like [:en]Bank Transfer[:de]überweisung . This is not only used on the frontend, but also on the backend – in the order information. Or for example, when the seller prints the invoice for the purchase, the invoice is supposed to be in the correct language for the buyer.

I have the same problem –?I have a plugin that saves some strings in wp_options. I used to save content with lang string like [:en] and passing them trought __() would always leave the relevant translation in past (with original qtranslate, then qtranslate m). Now it does not.

In fact, just putting _e(‘[:bg]test1[:en]test2’); directly in my php for admin page still does not translate anything? It just echoes [:bg]test1[:en]test2
This means Qtranslate X is not automatically translating __() function… What should I do?

you should use wp_update_post instead, the code is pretty much there, commented out

Well that other plugin doesn’t work for me, it doesn’t do auto expiration, which is what we need.

just tested something, which proved my theory. If in this plugin settings I choose to switch the posts to “trash” rather than draft – it works. It uses another function, (wp_trash_post), so basically everything works fine except for the wp_transition_post_status function.

I could change this in my code easily, but it’s better if the plugin is changed so that it works for everyone…

I believe the problem lies in the function used – wp_transition_post_status
in post.php this calls to transition_post_status to make the change, but there is no such function in wordpress, the function is actually called _transition_post_status. The other functions that wp_transition_post_status calls are ok, which explains why emails are sent.

This function is basically intended for stg else, it is for publishing posts, not for unpublishing. I see that the plugin used another function in the past, maybe this is when it stopped working?

I will test this on a test install…

Wow that was fast ??

I did get the update and it works perfectly now! Thanks!