Unable to translate list allowed values & other field settings.

I'm sorry but I don't quite understand the ask. Any field configuration like this is considered an interface translation as I think you are asking for so that the label in dropdown is displayed to the content author in their chosen language. The translation strings would need to be handled in Drupal's language system. Those same strings should be rendered in the translated language when viewed on a page. I don't think this is any different then if you were to setup key|label pairs in a core select field with how that works?

I think this actually could be a bug in that the default value in the settings form is not wrapped in t() so you are unable to see it as a string that can be translated in interface translation. Can you confirm thats what you are seeing please? I can fix that with an easy patch.

Hi, I am referring not only to the default value but in general to the list values. I explain in more details:

• create a new custom field with a text "subfield"
• now edit the custom field for a specific content type: in the edit tab set it to translatable
• then select the type of the subfield and choose "select list" or "radios"
• then create some key/value options in the settings

Now I expect to be able to translates those keys and values into other languages but I can't in the "Translate content fields" tab neither going to the configuration/regional/content-language menu.

Have I been more clear now?
thanks a lot for your prompt feedbacks :)

Giuse

The key/value options are considered config and therefore not directly available to translate that way. Similarly if you had a core list field with key/value options defined in the settings, there is no way to translate those directly in the configuration page (at least not that i'm aware of). Configuration settings like that are managed through the interface translations string management. Drupal will detect untranslated strings and you can set the values through that page. Feel free to try it with a standard core field and you should see same challenge.

When defining a standard "list (text)" field, you set the labels/values options and labels ARE directly translatable in the "translate content fields".
In custom_field module, defining the sub-field just as text and setting it to be a list, makes the labels (keys in custom_field module) not translatable. This is the issue I wanted to raise.

Oh, i see what you mean now. Looks like this interface doesn't detect sub-field settings. I'm honestly not sure how to get it to be compatible.

Maybe I'm saying something stupid since I am not a Drupal programmer, but would it be possible to define the text list fields as lists at the beginning of the process instead of later as "formatter" so that Drupal intercept the labels as translatable?
just my 1 cent :)

I know what the issue is now and discovered a simple fix in the way the schema is defined. I will create a patch for it and new release that addresses this asap! Thanks for bringing this to my attention as it is an important fix for multi-lingual support.

Patch to test.

Please test apply patch and revisit translate content fields and you should see the new option to translate label.

I applied the patch (changed the type "string" into label) and now a for for translation does appear in "translate content fields" but with 3 problems:
-) I think the naming should be changed: current "keys" are what are written into the DB so maybe they should be called "values", while current "values" are the labels that appear in the front end and are translatable so probably those should be called "labels"
-) the translation is too deeply nested: custom field settings > settings > custom field > settings > settings > allowed values list > allowed values list > value
-) some texts are not translatable: the label of the subfield, the help text of the subfield, the empty option string of the subfield
I am available for further testing of this very useful module.
cheers

Giuse

Thanks for the feedback. The deep nesting is something I can't change due to the structure of the field settings form but I can add additional properties as you suggested for translation. I'll supplement with another patch when I get to a point of I think having it complete. Sometime over the weekend likely should be doable. I just need to test it out locally for the various widget types.

New patch to try.

Yes, the new version fully works!
For naming alignment, in the main edit form (not the translate one), "key/value" should be replaced with "value/label".
Are you going to make a rc5 release?
cheers

Giuse

Merging to dev. Includes fixes for consistent labeling recommendations.