langcode column is ignored during CSV import and export always reads base config

Problem/Motivation

The module advertises multilingual CSV support, but the langcode column is not actually honored.

Current behavior:

• CSV export includes a langcode column based on the current interface language.
• Export still reads labels/descriptions/help text from the base configuration instead of translated config overrides.
• CSV import requires a langcode column, but the importers ignore it and write directly to base config entities.

• As a result, importing translated rows overwrites the default-language configuration instead of updating the targeted translation.

  This affects:

• Bundle labels/descriptions/help text on the Entities tab
• Field labels/descriptions on the Fields tab

• Potentially field group rows and other config-backed field metadata handled by the module

  Steps to reproduce

• Install and enable entity_labels.

• Enable Drupal multilingual support and configuration translation support.
• Add a second language, for example fr.
• Create or edit a bundle such as the article content type and add translated values for its label/description/help text.
• Add a configurable field with translated label/description values.
• Switch the interface language to the secondary language.
• Export Entity/Field Labels CSV.
• Observe that the CSV row langcode reflects the secondary language, but exported values come from base config.
• Edit the CSV and import rows using the secondary-language langcode.

• Observe that the default config is changed instead of the translation override for that language.

  Proposed resolution

  Make multilingual CSV behavior consistent with the langcode column:

• Export should read translated config values for the selected language when translation overrides exist.

• Import should write to config translation overrides when langcode is not the default language.
• Default-language rows should continue to update base config directly.

• Add kernel test coverage for translated bundle labels and translated field labels/descriptions.

  Remaining tasks

• Reproduce with a failing automated test.

• Update entity export to read translated bundle config.
• Update field export to read translated field config.
• Update entity import to honor langcode.
• Update field import to honor langcode.
• Add kernel tests for default-language and non-default-language imports/exports.

• Verify optional integrations such as field_group still behave correctly.

  User interface changes

  None.

  API changes

  None intended.

  Data model changes

  None.

  Release notes snippet

  Fixes multilingual CSV import/export so the langcode column targets translated configuration instead of always using base config.

  Implementation Targets

  Base the eventual fix on these verified code paths:

• web/modules/sandbox/entity_labels/src/EntityLabelsEntityImporter.php

• web/modules/sandbox/entity_labels/src/EntityLabelsFieldImporter.php
• web/modules/sandbox/entity_labels/src/EntityLabelsEntityExporter.php

• web/modules/sandbox/entity_labels/src/EntityLabelsFieldExporter.php

  The core bug to cite in follow-up comments:

• Importers validate langcode but never read it.

• Exporters populate langcode from current language but do not load translated config values.

  After You Create The Issue

  Once Drupal.org gives you the new issue number , I can use:

  drupalorg issue:branch

  If you want the full GitLab issue-fork workflow after that, the next commands will be:

  drupalorg issue:setup-remote
  drupalorg issue:get-fork --format=llm

  Assumptions

• Scope chosen: full import + export multilingual bug, not importer-only.

• We will use the standard Drupal issue summary template and GitLab issue branch workflow.
• No API or schema changes are needed; this is a behavior fix plus tests.