Ultimate FIelds loses its multilingual functionality

The next big version of Ultimate Fields is in development and will probably get released in the fall. Version 3 (2 was 99% ready, but I decided to skip it) brings tons of changes even on top of 2, but this is a topic for another article.

One of those changes will be the removal of qTranslate support. I am aware that many users choose Ultimate Fields because of this feature, however at the time of writing this article qTranslate has been long gone and qTranslate X is not being maintained anymore.

When Ultimate Fields 1 was released, qTranslate was a very popular plugin and even I was using it for most of my projects. Since then I came to the conclusion that there are too many things, which are problematic about the one field-multiple values approach. That, combined with the fact that qTranslate X is not really being supported led me to this decision.

If you are using Ultimate Fields in combination with qTranslate X at the moment, please write a comment below this article to describe what types of multilingual fields you are using.

If enough people request it, I will probably try to implement some limited multilingual functionality (no conditional logic, no repeatable fields, no required fields) in order not to break any websites.

6 thoughts on “Ultimate FIelds loses its multilingual functionality”

  1. Since multilingual functions are implemented by estending a base adapte classr, and since there is the option of adding more adapters, I don’t understand the need to remove support. The file would just be there, and if qtranslateX is not being maintained, there will be no required updates either. Or am I missing something?

  2. The problem is that the new version (internally called 3) is a complete rewrite with pretty much nothing of the old one left. From this point of view, I’d consider multilingual functionality a new feature based on an old idea, rather than something that is just lurking in the shadows.

    One of the key principles of the plugin is that I want as many things as possible to be supported in as many places as possible. I don’t want to tease too much like I did with this post, but the new version will have support for more than 10 locations, while the old one only had support for two: post meta and options pages. Some of those locations make it extremely hard and un-intuitive to have multilingual switchers or anything like that.

    The same applies to the user interface. There will be, for example, a very sophisticated conditional-logic defition interface (a mouthful, I know) and writing the multilingual functionality for that wold be a huge effort. I can list a lot more reasons, but the point is that I’m not strictly removing the functionality, I’m just leaving it out.

    Based on this, I guess you already realize that there isn’t antything that is really suitable for separate use as a plugin. In your case, the only solution would be to stick back to v.1. I’m saying this because I remember you from the forums and you’re probably the single person that utilizes the multilingual functionality the most, so there isn’t really a quick fix for that.

    1. Thank you for explaining. One question though, I could still manually enter a multilingual string, correct? Just your present multilingual interface would be missing? If you were to provide a hook in the uf function then a plugin or theme can parse & modify the output string, correct? If not, that’s fine, too 🙂 but I had to ask 😀

      1. There will be (and already are) hooks in the data API of the plugin, which let you split/extract multilingual values. This means that if you have a text field you can safely use the syntax of qTranslate X to enter multiple values.

        The issue is that Ultimate FIelds allowed most of its standard fields to be multilingual. If you were to have a “Select Page” field for example, it would expect a numerical value, but would get a strangely formatted string, which will surely break it.

Leave a Reply