When using a text/number field configured as select/checkbox/radio values, I found no translation possible. Is it a feature request?
Change custom_field.schema.yml for the allowed_values mapping of value from type 'string' to type 'label'. This simple change will enable the field setting in the translate content fields for full translation support.
Patch in process.
Settings for allowed values will be available in 'Translate content fields' section.
Change to schema definition (value type becomes 'label'):
allowed_values:
type: sequence
label: 'Options'
sequence:
type: mapping
label: 'Option'
mapping:
key:
type: string
label: 'Key'
value:
type: label
label: 'Value'
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | 3398154-17.patch | 2.74 KB | apmsooner |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
apmsooner commentedI'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?
Comment #3
apmsooner commentedI 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.
Comment #4
giuse69 commentedHi, I am referring not only to the default value but in general to the list values. I explain in more details:
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
Comment #5
apmsooner commentedThe 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.
Comment #6
giuse69 commentedWhen 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 later setting it to be a list, makes the labels (keys in custom_field module) not translatable. This is the issue I wanted to raise.
Comment #7
apmsooner commentedOh, 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.
Comment #8
giuse69 commentedMaybe 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 :)
Comment #9
apmsooner commentedI 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.
Comment #10
apmsooner commentedComment #12
apmsooner commentedPatch to test.
Comment #13
apmsooner commentedPlease test apply patch and revisit translate content fields and you should see the new option to translate label.
Comment #14
giuse69 commentedI 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
Comment #15
apmsooner commentedThanks 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.
Comment #16
apmsooner commentedComment #17
apmsooner commentedNew patch to try.
Comment #18
apmsooner commentedComment #19
giuse69 commentedYes, 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
Comment #21
apmsooner commentedMerging to dev. Includes fixes for consistent labeling recommendations.
Comment #22
apmsooner commented