Update May/5/2019
We released ACFML 1.3 which resolves the problems with translation for ACF Option pages, as well as adds support for Dynamic Blocks in ACF 5.8.
With release of ACFML 1.2 we decided to handle translation of ACF Options Pages with String Translation. After providing values on the option page, you have to WPML String Translations screen and translate their values. After getting client feedback, we’re reverting this change.
When we made this change in ACFML 1.2, we didn’t realize that it doesn’t cover all the kind of ACF options that you need to translate. As a result, some sites have lost translations for some ACF options. Of course, we’re sorry about this and we’re acting now to fix it.
The next release of ACFML reverts on this change. You will be able to use again WPML’s language switcher to translate ACF’s Options pages.
If you’ve already created translations using String Translation with ACFML 1.2, don’t worry. After updating ACFML to version 1.3, all your options strings and their translations will be migrated to the old format.
We will be releasing this update during this week. We just released ACFML 1.3, which resolves the problems and adds support for new features in ACF 5.8. If you’re missing anything between ACF and WPML, or something else broke, please let us know so that we can handle it quickly for you. Leave your comments and we’ll get back to you.
Yeah, and what impact do you think this will have on ones business when we suddenly have to spend days trying to fix the havoc this causes?
And this: “… we didn’t realize that it doesn’t cover all the kind of ACF options that you need to translate”. Doh!
Yeah, what a surprice there for you, sigh!
I’m not very happy with the problem that we caused. As soon as we realized it, we started the fix which I’ve announced now. Would you like someone from our support team to help you go through sites and fix these problems? If so, please create a support ticket about it AND add another comment here with the link to the ticket. This way, I’ll follow up and see that our supporters handle it correctly.
As hundred of users I can’t activate String Translation because it crashes my server: http://bit.ly/2ZYITmt
And yes… I followed one by one all recommendations in your articles to improve performance.
Sergio, can you please open a support ticket so that we can help you? Right now, there are over 1/2 million production websites using String Translation. I’m pretty sure that we can find what’s not working on your site and get it running quickly. But we need to know the problem. Thanks.
I wonder what the rationale was to use string translations here. Apart from the fact that it seems obvious that string translations can not cover the variety of values in ACF (some of which might even be post objects that will be translated in the loop anyway), it seems like worse UX to have to use the String Translation feature, when the options are on a different page altogether. I feel like switching languages to translate the options (as it was) makes more sense.
I can see the benefit of the String Translations interface for hardcoded string from templates/plugins only, which otherwise would not be accesible to non-programmers (even then, I feel it requires someone with some understanding of WordPress to operate the String Translations interface).
Thanks for listening to the community. Keep up the good work!
P.S.: There’s a typo in the second sentence of this post: After providing values on the option page, you have to to WPML String Translations screen and translate their values.
This was a design mistake on our side, which we’re correcting now. I wrote this blog post and let you know about it, so that you don’t have to find out by browsing Option pages which have lost their translations. As I’ve explained in this post, we are reverting the design now and restoring translations that you had before so that you don’t need to deal with it. Thanks for spotting the ‘to to’ typo. Fixing.
Hi Amir,
Your older method is flawed aswell, because swithing the default language of a website, rare as that may be, results in lost and/or swithed data from one language to another. For this reason, I have been “hard-coding” the language code into ACFs “post_id”, which you should advise all your users to do. As a result, this had no effect on my projects.
Here’s what I mean:
Use `’post_id’ => ‘option_’. ICL_LANGUAGE_CODE` to define the options page and
`get_field(‘foo’, ‘option_’. ICL_LANGUAGE_CODE)` to retrieve them.
IMHO, this should be the default method you advise your users to use.
You should definitely offer compensation of some kind. My clients site was broken, we were looking into the issue for a whole day. Finally, I talked for 2.5 hours with your support who had no knowledge of this issue.
This is a paid plugin and we paid good money for it and mistakes like this caused by pure negligence are unacceptable.
Darius, of course I’m very sorry for this issue. As soon as we realized we’ve made a design mistake, we started correcting it and wrote to clients, to avoid wasting anyone’s time. If you have any other sites that need fixing, please open a new ticket in our support and add a message here. I’ll make sure that our supporters fix any remaining content issues on your site(s), so that you don’t need to spend your time doing it.
I’m happy for this announcements and revert back to old way of doing it (string translation does not cover all, but it is also quite hard to use especially for clients who are not technical). Not happy that it happened, but these kind of things do happen in SW development, even for super big companies like Microsoft. Good that you have reacted fast and release update soon!
Thanks for your understanding!
Thanks for your prompt attention to this. This was only an issue for me on a site under development so easier to work through than for some others who’ve responded above, but still, development is difficult and mistakes happen. You’ve owned up and are fixing it which is all anyone can ask. Looking forward to the update.
Thank you for your support and understanding. We just released ACFML 1.3, which resolves the issues with the Options pages and adds translation support for the new Dynamic Blocks in ACF 5.8.
We’ve noticed that the media does not “translate” over when doing translations. I have to go into the article and manually move the media over. This was not an issue before.
thanks
Jerry