>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3581212. --> Reported by: [jrockowitz](https://www.drupal.org/user/371407) Related to !1 >>> <h2 id="problem-motivation">Problem/Motivation</h2> <p> The module advertises multilingual CSV support, but the <code>langcode</code> column is not actually honored.</p> <p> Current behavior:</p> <ul> <li>CSV export includes a <code>langcode</code> column based on the current interface language.</li> <li>Export still reads labels/descriptions/help text from the base configuration instead of translated config overrides.</li> <li>CSV import requires a <code>langcode</code> column, but the importers ignore it and write directly to base config entities.</li> <li> <p>As a result, importing translated rows overwrites the default-language configuration instead of updating the targeted translation.</p> <p>This affects:</p> </li> <li>Bundle labels/descriptions/help text on the Entities tab</li> <li>Field labels/descriptions on the Fields tab</li> <li> <p>Potentially field group rows and other config-backed field metadata handled by the module</p> <h2 id="steps-to-reproduce">Steps to reproduce</h2> </li> <li> <p>Install and enable <code>entity_labels</code>.</p> </li> <li>Enable Drupal multilingual support and configuration translation support.</li> <li>Add a second language, for example <code>fr</code>.</li> <li>Create or edit a bundle such as the <code>article</code> content type and add translated values for its label/description/help text.</li> <li>Add a configurable field with translated label/description values.</li> <li>Switch the interface language to the secondary language.</li> <li>Export Entity/Field Labels CSV.</li> <li>Observe that the CSV row <code>langcode</code> reflects the secondary language, but exported values come from base config.</li> <li>Edit the CSV and import rows using the secondary-language <code>langcode</code>.</li> <li> <p>Observe that the default config is changed instead of the translation override for that language.</p> <h2 id="proposed-resolution">Proposed resolution</h2> <p>Make multilingual CSV behavior consistent with the <code>langcode</code> column:</p> </li> <li> <p>Export should read translated config values for the selected language when translation overrides exist.</p> </li> <li>Import should write to config translation overrides when <code>langcode</code> is not the default language.</li> <li>Default-language rows should continue to update base config directly.</li> <li> <p>Add kernel test coverage for translated bundle labels and translated field labels/descriptions.</p> <h2 id="remaining-tasks">Remaining tasks</h2> </li> <li> <p>Reproduce with a failing automated test.</p> </li> <li>Update entity export to read translated bundle config.</li> <li>Update field export to read translated field config.</li> <li>Update entity import to honor <code>langcode</code>.</li> <li>Update field import to honor <code>langcode</code>.</li> <li>Add kernel tests for default-language and non-default-language imports/exports.</li> <li> <p>Verify optional integrations such as <code>field_group</code> still behave correctly.</p> <h2 id="user-interface-changes">User interface changes</h2> <p>None.</p> <h2 id="api-changes">API changes</h2> <p>None intended.</p> <h2 id="data-model-changes">Data model changes</h2> <p>None.</p> <h2 id="release-notes-snippet">Release notes snippet</h2> <p>Fixes multilingual CSV import/export so the <code>langcode</code> column targets translated configuration instead of always using base config.</p> <h2 id="implementation-targets">Implementation Targets</h2> <p>Base the eventual fix on these verified code paths:</p> </li> <li> <p>web/modules/sandbox/entity_labels/src/EntityLabelsEntityImporter.php</p> </li> <li>web/modules/sandbox/entity_labels/src/EntityLabelsFieldImporter.php</li> <li>web/modules/sandbox/entity_labels/src/EntityLabelsEntityExporter.php</li> <li> <p>web/modules/sandbox/entity_labels/src/EntityLabelsFieldExporter.php</p> <p>The core bug to cite in follow-up comments:</p> </li> <li> <p>Importers validate langcode but never read it.</p> </li> <li> <p>Exporters populate langcode from current language but do not load translated config values.</p> <h2 id="after-you-create-the-issue">After You Create The Issue</h2> <p>Once Drupal.org gives you the new issue number <nid>, I can use:</nid></p> <p>drupalorg issue:branch <nid></nid></p> <p>If you want the full GitLab issue-fork workflow after that, the next commands will be:</p> <p>drupalorg issue:setup-remote <nid><br> drupalorg issue:get-fork <nid> --format=llm</nid></nid></p> <h2 id="assumptions">Assumptions</h2> </li> <li> <p>Scope chosen: full import + export multilingual bug, not importer-only.</p> </li> <li>We will use the standard Drupal issue summary template and GitLab issue branch workflow.</li> <li>No API or schema changes are needed; this is a behavior fix plus tests.</li> </ul>