Home›Support›English Support›[Resolved] Migrating older WPML with ACF to ACFML "Same fields across languages"
[Resolved] Migrating older WPML with ACF to ACFML "Same fields across languages"
This thread is resolved. Here is a description of the problem and solution.
Problem: The client is refactoring a custom theme on a WPML-powered nonprofit site with a substantial amount of content and is concerned about the risks of changing WPML settings. They are interested in using new WPML features, specifically the ACFML Addon, to handle custom fields and repeater fields better. The client also has issues with field labels appearing in the translation editor and is looking for a workflow to manage gettext strings efficiently without affecting site performance.
Solution:
1) For an options page, we recommend using "different fields across languages" to allow language switching.
2) For content that maintains the same structure across translations, use "same fields across languages". For the homepage with different content recommendations per language, duplicate the field group and apply "different fields across languages".
4) String Translation performance has improved since WPML version 4.4, as it now uses PO files instead of the database, which can be found in wp-content/languages/wpml.
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
Hi, we've been using our wpml powered nonprofit site for years (since 2016, I think) and are currently refactoring our custom theme, which has made and will continue to make heavy use of ACF and Custom Post Types and Classic Editor (no Gutenberg).
The site has grown substantially over the years (close to a thousand posts in the main language, translated into 10 other languages by professional translators). Since starting wpml has developed further too.
So I'd like to implement some of the new(ish) features but with that much valuable content, touching any setting in WPML seems high-risk even with backups, because it's almost impossible to check for every edge case, especially in languages that no one in our team speaks themselves.
I've noticed that there's now the ACFML Addon that should help with cleaner and easier translation (or non-translation) of custom fields. Sounds promising. In the past repeater fields often had sync issues and lost data.
Now to my specific Question:
What's the best way to migrate a legacy site to use the newer functions? (Apart from a copy-paste mega-marathon)
Or would you even recommend changing anything in our case?
I don't need to translate the Field Labels/Names at all as those are only shown in the Backend. Our Translators only need to translate (some of) the custom field values.
So I don't really want to click through hundreds of String entries (remember, 11 languages) and copy and paste the untranslated field label.
Simply changing the field-group Post Type to non translatable seemed to have deleted all previously translated custom field values in my test environment.
Edit: I've just tried to update the legacy field group translations, by clicking "Overwrite with [main language] Content" which deleted the existing (translated) fields and created a new empty text field called "(no label)". So this doesn't work anymore. Now I'm officially stuck.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Hi there! before we dive into the configuration, i'd like to have some info about how you use the site because that will be the key on what config to use.
1) Do you have an options page on your site (made by ACF of course)?
2) Do you translate or localize your content?
- Translate: You use the same exact structure in your pages but you change the values (i.e: same amount of repeaters and flexible fields between languages and in the same order, but with translated text).
- Localize: You change the structure in the translations (i.e: maybe same amount of repeaters with different orders or different amount of repeater/flexible field elements between the languages and the content is translated)
This is the key to understand what to do next.
-----------------
Then i ask you another question: do you use the translation editor to translate the content (or do you want to do it?)
----------------
If possible, create a staging site in the meantime so we can then run a few tests according to your answers.
1.) Yes and no, an options page was not used in the past, but will be with the new and updated custom theme. Some of these options will be the same across languages, but the page will also contain a repeater with content for the footer that would need to be translated 1 to 1 (So no different numbers or order of repeaters)
2.) For our posts (acf) content our concept is to translate the exact structure. This structure should be kept in sync across languages. Some fields just need to be copied (phone numbers, adresses), some fields need to be translated (e.g. complex opening times).
The only place where we might want to deviate from that "translate"-concept is our home page. Home will be a custom page template that also has a repeater to choose different posts (post object field). So spanish speakers will recieve different content recommendations than arabic speakers.
3.) Our content is always created in the main language (German). To edit non-german content our team only use the translation editor. New content is usually translated by outside professional translators that get a temporary account (translator role). We use the wpml translation management for that.
Sure, I'll create a staging site for you to check out and run tests. Where can I confidentially send the credentials to?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
1) For the options page, i suggest that you use "different fields across languages" mainly because with the "same fields across languages" you will not be able to switch from one language to another (because this option is aimed at pages and content where the translation editor can be used). the configuration will almost be the same, so it will not create issues even if you leave the same structure across languages.
2) from what i understand, then i think it's best if we test "same fields across laguages" and then check the homepage to see where it deviates from that configuration (if it doesn't work) and in that case, i'd suggest that you duplicate the field group for the homepage and apply it only to that homepage wth "different fields across languages", that way you keep things separated and work in a cleaner and easier way with ACF + WPML.
3) if the same info will apply to the homepage, then i think "same fields across languages" is the option for you!
-------------
As next steps:
A) you can set one field group as a test for the options page (with "different fields across languages), setup the options page and lastly check it out on the front-end. does it work for all the languages?
B) if you have a field group that contains all the info from a page (as in, the page doesn't have more than one field group assigned), use that as a test initially. set it to "same fields across languages" and then go to said page. edit the original (german, from what i understand) and maybe add a character to the title to prompt a WPML update. then update the translations and check them in the front-end.
step b will have to be done only once on the pages, after you set the new translation preference on the field group, since afterwards it will sync the "copy" field values as soon as you hit the save button!
try that out and then let me know how things go before we can continue.
Hi Alejandro, just checking in to say that I'm still on it, but need a little more time, before I can replicate all the steps with backups. I'll get back to you next week.
Thanks again for your helpful answers, I've been able to proceed now and was able to thoroughly check all new and old settings and also update wpml to the latest version without any real hick-ups.
This cleaned up my ACF Dashboard nicely.
However this created a new issue:
When creating a translation job of a post, all attached Field Labels show up in the translation editor. To clarify: I mean the backend Labels that I have given to my custom fields in ACF Dashboard. All our wp users speak the primary language (german) so the admin area does not need any translation.
Of course, the corresponding field values still need to be translated for the frontend.
My workaround now is to go into string translation, select all strings from that field group and delete them from string translation.
However, once I change something in the Field Group or just save a Group, those strings are back and need to be deleted by me again to keep them from showing up.
Is there a way to tell string translation that none of the (backend) field labels need to be translated?
---
Regarding said string translation, I have another question:
Up until now I've translated gettext strings in my custom theme the native wordpress way with poedit. With some added help from your automatic po translation tool ( hidden link )
Not all our languages are supported and having real humans checking the strings in context would be good too, so using string translation for that seems a good option.
However from years ago I remember that String Translation used to decrease site performance significantly and was only meant as a band-aid to enable non-developer type users to translate badly hard-coded strings in the template.
I did import/update the .mo file over at the "theme and plugin localization" settings page (Quote: "WPML has detected changed or new MO files. There are new or updated .mo files. WPML needs to scan them to find strings for translation.") and now I can create new translation jobs for those strings.
My question: After translators have finished translating the strings, should I then export the strings back into a po file for maximum performance? (bottom menu on string translation dashboard)
Or does the string translation plugin of 2023 create those files by itself and is maybe powered by gettext anyway? I wasn't really able to find specifics on that.
2) you can't delete those strings (yet). they will be hidden, though in a future version of WPML So you can safely ignore them (They need to be there because they are technically string packages)
3) About String translation. it's nice that you've tested our new tool (PTC = Private Translation Cloud).
String Translation used to decrease performance because it loaded the strings in the database. this changed in version 4.4 of WPML and it now uses the standard WP way of creating PO files.
In fact as soon as you translate a string, you'll see a PO file appear in wp-content/languages/WPML . the database way from before still exists but it's disabled by default (it's a useful way when you use load balancers or different servers to host a website)
They are read from there increasing performance and eliminating the issues that we had with it before. I guess you could also put them in the normal WP directory with the correct naming structure and they would work as well (even with String Translation disabled), though.
