>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3548749. --> Reported by: [wim leers](https://www.drupal.org/user/99777) Related to !451 >>> <h3 id="overview">Overview</h3> <p><span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/canvas/-/work_items/3548686" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/canvas/-/work_items/3548686</a></span> added support for <code>list_float</code> and <code>list_integer</code>. It documents in detail why <code>list_string</code> cannot be supported in a similar way.</p> <p>Discussed the reasons for not supporting <code>list_string</code> with @lauriii, which he feels is very important.</p> <h3 id="proposed-resolution">Proposed resolution</h3> <p>@lauriii proposed to NOT map the actually <strong>stored string value </strong>(which would indeed cause the concerns @Wim Leers documented). But to INSTEAD use <strong>the associated human-readable label (the "key")</strong>.</p> <p>IOW: <img src="https://www.drupal.org/files/issues/2025-09-25/Screenshot%202025-09-25%20at%206.48.17%20PM.png"></p> <p>There are some challenges to overcome though on the implementation front:</p> <pre>// @todo Allow matching `list_string` to any `type: string`, by flipping around how it works: it should NOT pass the *stored* string (the "value"), but the *human-readable label* (the "key") to a `type: string`. This will require adding a new computed property to the `list_string` field type that fetches the label ("key") from its `allowed_values` setting, translated to the current \Drupal\Core\Language\LanguageInterface::TYPE_CONTENT language, despite it being a config translation.</pre><h3 id="ui-changes">User interface changes</h3>