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.
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?
LikeLike
Would there be any way to keep using qtranslatex with UF using a separate plugin if you remove support?
LikeLike
forgot to enable reply notifications for the above two, hence this one.
LikeLike
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.
LikeLike
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 😀
LikeLike
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.
LikeLike