[Resolved] WPML + ACF Multilingual Setup Review & Best Practices
This thread is resolved. Here is a description of the problem and solution.
Problem: The client is implementing WPML with Advanced Custom Fields (ACF) Multilingual and seeks confirmation on best practices for field translation settings, ensuring layout elements sync across languages, and maintaining a scalable multilingual structure. Solution: We recommend setting ACF Field Groups to 'Not translatable' and choosing the appropriate translation preferences for fields: use 'Copy' for layout/structure fields (like repeaters, icons, CTAs) to maintain synchronization across languages, and 'Translate' for user-facing text fields to allow proper content translation. It's important not to manage ACF fields from the WPML → Settings → Custom Fields Translation screen but directly from the ACF Field Group edit screen. The fields listed there, including dynamically created ones, are normal for ACF-based sites and should remain as configured without manual adjustments. For detailed guidelines, refer to ACF Field Groups translation settings and recommended custom fields translation preferences for ACF and WPML.
If this solution does not fully address your issue or seems outdated, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If further assistance is needed, please open a new support ticket at WPML support forum.
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.
I am currently implementing WPML with Advanced Custom Fields (ACF) Multilingual on one of my client websites (Vidanova Pension Fund) and have reached approximately 90% completion.
Before proceeding with the remaining two websites, I would like to request a session with your team to review the current setup and confirm that the configuration follows best practices.
Specifically, I would appreciate guidance on:
• Proper configuration of ACF field translation settings (Copy vs Translate) to ensure a scalable and maintainable multilingual structure
• Ensuring that layout elements (icon boxes, CTAs, repeaters, etc.) automatically sync across languages without requiring manual duplication
• Validating that our workflow (NL as default → EN as translation) is correctly implemented
• Recommendations to avoid future issues when content is updated by non-technical users
• General review of the current implementation before replicating it across additional websites
The goal is to ensure that:
• Content updates in the default language propagate correctly
• The setup is efficient and maintainable long-term
• We avoid structural inconsistencies between languages
I would appreciate the possibility of a short session (e.g. 30–60 minutes) to walk through the setup and receive your recommendations.
Thank you for your detailed questions these are all very valid points when setting up a scalable multilingual structure.
At the moment, we do not provide live sessions or calls, and support is handled via the forum. However, I’ll do my best to guide you here.
Regarding ACF and WPML setup:
- Depending on the translation method you’re using, you can choose Option 1: Same fields across languages or Option 2: Different fields across languages
In general use Copy for layout/structure fields (repeaters, icons, CTAs, etc.) so they stay in sync across languages and se Translate for user-facing content. This ensures that updates in the default language propagate correctly while still allowing proper translation of content
If you’d like, feel free to share specific examples, and I’ll gladly review your setup and provide more targeted recommendations.
I have aligned the setup based on your recommendations:
• ACF Field Groups are set to Not translatable
• layout/structure fields are set to Copy
• user-facing text fields are set to Translate
The setup is now working much better, and key pages such as the Home page, FAQs, and Annual Reports are displaying correctly in both Dutch and English.
My remaining concern is the very large list of custom fields shown under WPML → Settings → Custom Fields Translation. To make this easier to review, I prepared an XLSX file with the field list and my current classification work.
Please refer to the XLSX file here: hidden link
Could you please advise whether my approach is correct, especially regarding:
• which fields can safely remain ignored or untouched
• which fields should clearly be treated as Copy vs Translate
• whether this field list looks normal for an ACF-based site of this type
My goal is to make sure the setup is scalable and maintainable before I continue with the other two websites.
Thanks for the update glad to hear things are working better now.
Regarding the Custom Fields Translation screen: you should not manage ACF fields from there. The correct place to set ACF translation preferences is always in the ACF Field Group edit screen, as you already did. Then correct settings will be synced to the pages / posts and that settings page also.
The fields you see in that list (including ones like 0, 1, etc.) are expected they are dynamically created/custom fields stored per post and can vary depending on content structure. This is normal for ACF based sites.
So in your case:
- your current approach (setting fields in ACF groups) is correct
- you can safely leave the WPML → Custom Fields list as is
- no need to manually adjust or “clean” that list
I would like to inform you that, based on your recommendations, the setup is now working as expected. The ACF Field Groups are configured using “Same fields across languages,” and content updates in the default language are correctly reflected and translated in the secondary language. So far, everything seems stable and aligned.
I do have one additional question regarding language support:
Papiamentu (Pap) is not available by default in WPML. I understand that it can be added manually as a custom language. However, Google Translate does support Papiamentu: hidden link
Would it be possible to configure WPML in such a way that Papiamentu can be used as a translation language leveraging available translation engines (e.g., Google Translate or others)?
Specifically:
• Can WPML fully support Papiamentu as a custom language for page translations?
• If added manually, can it be integrated with automatic translation services?
• Are there any limitations or best practices we should consider when using a non-default language like Papiamentu?
Your advice on this would be highly appreciated before we proceed further with the remaining websites.
Thank you again for your support.
Best regards,
Bassam Al Dana
Millennium Net Services
New threads created by Dražen and linked to this one are listed below:
