There will be a Documentation update soon about how to use these fields with WPML.
As well there will be some development work to improve the usability and manage the restrictions better.
Let me show you what will figure in the document so we can already close this ticket here.
- Values of custom fields for posts and users that have a textfield-like interface should not be registered in WPML String Translation. In fact, this seems to be the current behavior.
==> Those fields get their value directly from the database, and as the current post is in the right language, we get the right values no matter whether they are set to translate, copy or do nothing.
- Each field has additional attributes:
-- Display name
-- Description
-- Validation messages
--- Fields with any sort of text input also have:
---- Placeholder
---- Default value
==> All those strings should be registered with WPML String Translation when the field group is saved, and should be translatable and translated in back-end and front-end.
- We have some special fields that need some sort of translated strings to work properly, this is because they do not expose their values directly and use labels, sometimes even alternative frontend output.
- Those fields are checkbox, checkboxes, radio and select fields.
==> In that case, they do translate their content. Changing the value, label or alternative output on the Types field group GUI sets those fields as Translation needs update in WPML String Translation, and they display the original language value until they get their translation updated.
- Select fields have options that the user can choose from. Each option has a Display text and Custom field content.
- The Display text is used whenever for option names whenever the input field is rendered, be it in back-end or front-end.
- When rendering the field with the [types] shortcode, the Display text is used by default as well.
- Custom field content is the raw value that will be stored in the database. It can be rendered on the front-end only using the raw output [types field='field-slug' output='raw'][/types].
==> Display text should be translatable while Custom field content must remain always the same, as defined field settings. They should never be registered as translatable strings.
==> Translating those values would create all sorts of problems with querying posts, with conditional output, and it also becomes a big problem if WPML gets deactivated (database is suddenly full of values that no longer have any connection to options), or even if the language of a post is changed.
- Translating "Display" text values, the values are registered as WPML strings as soon as the post field group holding the field is saved
==> That means, these strings should always be translated with WPML String Translation.
==> On the contrary, translating the Custom field content value with WPML Translation Manager is a bad practice, since the value works basically just as a “placeholder” for Display text. If the user absolutely needs to translate it, they’re probably using the wrong field type for their purpose, or they need some custom code adjustments.
==> The setting in WPML → Translation Management → Multilingual Content Setup → Custom Fields Translation can be set to Translate, because that means only that the user will be able to select a different option in the translated post (with a translated Display text but the same Custom field content value).
However, when the post as whole is sent to a translation via WPML Translation Manager, the translator will see (under WPML → Translations) the raw value of the field (Custom field content). This value should never be touched!
If they translate it directly, the value will not be recognized when the field is rendered (it will have no Display text attached) and Types will default to displaying it raw.
As you see there are some details which need usability updates and those works are in progress.
Teh document will clarify the process.
The updates depends mainly on WPML Translation management since it needs to hide the fields to be edited in certain cases.
These works will be updated in the WPML plugin, but I have no ETA's on this issue's solution.
It will be provided with a future release.
