Release Notes –

These releases are mostly a compatibility fixers for WordPress 4.5 with a few new improvements. A complete list is available in Changelog.

If you update with normal download using WP update page, the update should work ok. If you do it manually through file upload, remember to deactivate old plugin, update files and then reactivate plugin. Simple overwriting files on disk, while plugin is kept active, will not work correctly. If you forgot, try deactivate/reactivate plugin manually once more. Pressing “Save Changes” button on Settings/Languages configuration page may also help to make the update proper.

There are probably more problems to fix, let us continue collecting the list of them on thread Issues with WordPress 4.5. Please, do not put messages there, which are not related to WP 4.5. Use the standard troubleshooting procedure instead.

The author team apologizes for any inconvenience the recent instability cased and thank all, who helped promptly to discover the problems and to test the solution.


Release Notes 3.4

Release date is July 7, 2015.

Version 3.4 fixes a few bugs reported recently, which means that new bugs may appear – do not forget to make a reasonable backup before upgrading. Of course, please report a problem if you find one.

The complete list of changes is available in Changelog and is not repeated here, rather just a few main things are highlighted below.

New Options and Features

  • This release is concentrated on finalizing Integration Framework. The whole qTranslate-X’s configuration is now loaded from a JSON-encoded file i18n-config.json, which may be customized as desired. Developers of themes and plugins can now provide an integration file with their distribution, which will be auto-loaded into qTranslate-X on a plugin activation. One may also provide any additional custom configuration file via option “Configuration Files” on “Integration” tab. Option “Custom Configuration” is a convenience shortcut, which also allows to provide additional custom configuration. Please, review Integration Guide for more details.
  • There is a new meta-box named “Language”, which contains a set of Language Switching Buttons (LSB). The meta-box, as any other meta-box, can be placed anywhere on the screen (/wp-admin/post.php). You may find new LSB meta-box useful, if you have a lot of stuff on the screen. Extra set of LSB placed right at the tips of your fingers may significantly reduce amount of page scrolling you would have to do otherwise. You may also turn LSB meta-box off, as any other meta-box, if you do not need extra set of LSB.

The things to get confused about

  • The default position of LSB (Language Switching Buttons) is changed at HTML level, although you may not notice a visual difference on the first set. By default, there are now two LSB sets on a standard post page, one above the title and other below the main editor area. If a 3rd-party plugin adds additional set, it may get next to the default one, which would look excessively, but there is nothing actually wrong, it all is still functioning. You may customize the json configuration to remove one of the excessive sets, if really desired, or simply wait for other plugin to update their code.
  • There are reports that QTranslate Slug works much better after its last update. However, it is still not native to qTranslate-X and we have not tested it much. If something goes wrong, the first thing to try is to turn off QTranslate Slug.
  • Locale for Japanese language has been changed from ‘jp_JP’ to ‘jp’ to match the one that WordPress uses.

You may find helpful to review the list of Former Known Issues Resolved and the list of Known Issues still existing, although many problems, resolved quickly enough, were never recorded in the list of Known Issues.

Please, enjoy the new features of version 3.4, and do not hesitate to report a problem, if you encounter one.

Release Notes 3.3

Version 3.3 fixes a number of bugs reported recently, which means that new bugs may appear – do not forget to make a reasonable backup before upgrading. Of course, please report a problem if you find one.

You may find helpful to review the list of Former Known Issues Resolved and the list of Known Issues still existing.

There is a couple of new options

A detailed Changelog is available at WordPress site and it will not be repeated here. A few new options worth of mentioning are listed below:

  • Option “Highlight Style” – controls how translatable multilingual fields are styled to be distinctive from all the other normal fields. It is not important for simple sites, where only title and content are translatable, but when there are many integrated plugins, together with customization through options “Custom Fields”, it may become quite confusing to know which field is translatable and which is not. This option allows to visualize each translatable field. There are two different styles provided out of the box, and there is a way to put in your own custom CSS to highlight translatable fields any way you wish. This option is expected to be loved by the majority of users, while there is also a way to turn highlighting off at global site level, or per user choice. The original implementation of highlighting belongs to Michel Weimerskirch, whose contribution is appreciated very much.
  • Option “LSB Style” – controls how Language Switching Buttons (LSB) are displayed. There is a couple of presets, as well as a way to provide your own CSS.
  • Choice “Single Language Mode” for option “Editor Mode” – provides unbounded compatibility with other plugins and themes. There are no LSB in this mode, and the edit language is the same as admin one. You have to change admin language, if you wish to edit content in other languages. This mode introduces certain inconvenience, which is supposed to be outweighed by the compatibility benefits, if compatibility issue is a problem for a particular plugin and theme set. However, this essentially works the same way as normal LSB in case a user consciously decides not to switch the edit language during one editing session. This is why the advanced users may still use the default LSB mode, while taking special care of translatable fields at trouble. If you do not switch edit language during a session of editing of incompatible translatable field, then after pressing “Update” button your changes will be saved. If you switch language with LSB after editing an incompatible field and before pressing “Update” button, the changes may be lost. Conscious not switching the edit language on certain fields allows you to still use LSB mode, which bring convenience back for all other well-behaving fields.
  • Option “Post Types” – to disable translation of certain custom post types.

Points to get confused about

  • If you use plugin QTranslate Slug, expect some things do not work as expected, although it may appear working most of the time. When something is wrong, try turning QTranslate Slug off, before reporting the problem.
  • Japanese predefined locale has changed to ‘ja_JP’, which may cause to disable language after update. Please, enable it again.
  • The logic of using the list of languages on configuration page ‘/options-general.php?page=qtranslate-x’  is changed. All languages are now always shown, but only edited ones are stored in the database.

What to expect in the future releases

The next version will be dedicated to finalizing the 3rd-party integration interface. Your comments and suggestions are very welcome. Once the interface is finalized we will keep supporting it and encourage the 3rd-party developers to use the designated interface functions only, avoiding direct access of internal variables, as they are always a subject to be re-designed.

One the next versions will hopefully be dedicated to recovering functionality of QTranslate Slug in a native for qTranslate-X way.

Technical details

Below are technical details, which you may choose not to read at this time, since it will not affect the way you work.

The major new enhancement from technical point of view is how the translatable fields are implemented. You have probably learned in the past how qTranslate used to deal with multilingual fields. Java script of qTranslate would create a hidden copy of each translatable field, where multilingual content is stored, and rename the original field to make it temporary hold a single language text, which user can modify. When LSB is pressed, the single-language content is combined with other languages texts and stored in multilingual hidden field, while other language text is copied back to the original single-language field. Operation of copying texts back and forth would also happen on blur event, to update multilingual hidden field with a new content of edited single-language text. When “Update” button is pressed the content of hidden multilingual field is sent to the server. The original, renamed field, with the last edited single language text gets lost.

This way of working has trouble when blur event is not fired on time for whatever reason, or when a custom plugin makes use of the original field name and gets confused when it is renamed. These two are major reasons for incompatibility problems.

The new way of working implemented in version 3.3 no longer does renaming of the fields and no longer depends on blur event. Here is what happens:

  • Java script of qTranslate-X now creates an additional hidden fields for each language and each translatable field, while the original field remains untouched.
  • On page load, the multilingual content of the original filed gets distributed between the hidden fields according to the language, and the content of original field is replaced with the content of active edit language.
  • When LSB is pressed, content of hidden fields get copied back and forth to the original field to switch the language appropriately. If no LSB button is pressed during editing session, the original field keeps single language loaded at the time of page load.
  • When “Update” button is pressed, all the fields, original and all its language satellites are sent to a server and re-combining of multilingual content happens at the server side. The content of last edited field is used for the last active edit language, which makes it  impossible to lose last modification.

In this way, qTranslate-X has no opportunity to break anything when other plugin or theme alters a translatable field content in a special non-standard way. This way makes it possible to implement “Single Language Editor Mode”, in which nothing special happens to translatable fields and compatibility issue becomes irrelevant.

Some advanced editing plugins like “Visual Composer” of any kind, for example, make a copy of the original translatable field to run their own way of editing. When editing is done they copy the relevant content back to the original field. For qTranslate-X, there is no way to know about such customization in a general way, which frequently makes two plugins incompatible.

To simplify the integration, qTranslate-X now provides a few Java script functions, including ‘addLanguageSwitchBeforeListener’ and ‘addLanguageSwitchAfterListener’, for example, which enables plugins to do their custom actions on language switch action. Unless an advanced plugin is integrated, it will most likely not be incompatible with qTranslate-X. The good news is that you would not care about it, if “Single Language Editor Mode” is in use. The other good news is that a 3rd-party plugin author may enable compatibility easily enough, if one wishes to cooperate.

The integration interface is now being designed and will hopefully take its final shape in the next version. Please, let the conflicting plugin authors know that qTranslate -X is ready to cooperate with them to tune the easiest possible way of general integration.

Please, enjoy the new features of version 3.3, and do not hesitate to report a problem, if you encounter one.