Problem/Motivation

When exporting and importing content on a multilingual site, single_content_sync does not respect the current language context. This produces two distinct but related defects:

1. Export embeds the wrong translation for referenced/child entities.

  • The top-level entity is exported in the language it was loaded in, but every referenced or child entity (paragraphs, media, entity references, link targets, embedded entities in text fields, taxonomy parents, menu link parents/targets, book parents) is loaded inside the field processors via $storage->load() / loadMultiple() / loadEntityByUuid(). Those loaders always return the entity in its default language.
  • So when you export an English page whose paragraphs/media were originally authored in French, the export embeds the French copy of every child entity even though the parent node is English.

2. Import writes into the wrong translation and aborts on unknown languages.

  • The import form forces all content into a single target language (langcode is rewritten recursively), so there is no way to import a file that contains all of its translations.
  • On import, base values and custom field values are written into whatever translation Drupal loaded by default, instead of the translation indicated by the content. This clobbers an existing translation and leaves the target translation incomplete.
  • If the exported content references a translation whose language is not configured on the target site, addTranslation() throws Invalid translation language (xx) specified deep inside the recursion. Because referenced entities are imported before the parent is saved, this aborts the entire import and leaves nothing persisted.

Steps to reproduce

Export Steps:

  1. On a multilingual site, create a node in English that references paragraphs/media originally created in French (French as their default language).
  2. Export the English node.
  3. Observe that the exported YAML embeds the French copy of the referenced paragraphs/media.

Import Steps:

  1. Export a content in English language
  2. On a multilingual site having en and fr languages, if you want to import in fr language only, than no language select field is available on content import form.
  3. Import a content file that contains translations in a language that is not enabled on the target site — the whole import fails with Invalid translation language (xx) specified.

Proposed resolution

Export side:

  1. switch every entity entering the exporter, and every child entity loaded inside the base-field/field processors, to the translation matching the current language context via EntityRepository::getTranslationFromContext():
  • ContentExporter::doExportToArray() — normalize the incoming entity.
  • Field processors: EntityReference, Link, TextField.
  • Base-field processors: Node (menu link, book bid/pid/parents), TaxonomyTerm (parent), MenuLinkContent (parent + link target).

  • ContentSyncHelper::getDefaultLanguageEntity() — return the context translation.

Import side:

  • When importing content via single content sync (the form at /admin/content/import), there is a new option to select the language the imported content is created into.
  • Add an "All languages (import all translations)" option to the import form, alongside the per-language options, so the importer can preserve every translation in the file instead of forcing one target language.
  • In ContentImporter::doImport(), only rewrite langcodes when targeting a single specific language; when "all" is selected, let the native translations loop handle multi-translation
  • When the entity exists, switch to (or add) the translation indicated by the content before writing values, instead of mutating the loaded translation.
  • Gracefully skip translations whose language is not configured on the target site: report a user-facing error and continue, so the languages that do exist still import (and referenced entities stay valid) instead of aborting the whole operation.

Remaining tasks

User interface changes

A new language select field is added on content import form at /admin/content/import
import-form

Command icon Show commands

Start 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:

Comments

kuldeepbarot created an issue. See original summary.

kuldeepbarot’s picture

StatusFileSize
new7.39 KB
kuldeepbarot’s picture

Title: Allow import in a different language from the language in which the content was exported » Export ignores language context and inp
Version: 1.4.13 » 1.4.15
Issue summary: View changes
Related issues: +#3498510: Allow to partially export content
StatusFileSize
new28.25 KB
new320.64 KB
kuldeepbarot’s picture

kuldeepbarot’s picture

Please ignore the patch provided in this comment as it is a partial fix for content import. PFA the updated patch which covers both export and import scenarios.

kuldeepbarot’s picture

kuldeepbarot’s picture

StatusFileSize
new28.25 KB

Please ignore the patch provided in this comment as it is a partial fix for content import. PFA the updated patch which covers both export and import scenarios.

kuldeepbarot’s picture

Title: Export ignores language context and inp » Export ignores language context and import form does not have a language select option to import patch for a particular language
hemuvyas97’s picture

StatusFileSize
new28.25 KB

Reroll of the patch using #7 for version 1.4.16

gallant_dev’s picture

#9 patch is not installing for me on D10, SCS 1.4.16.

In EntityReference.php, the hunk containing references to a var called $skip_reference_settings is failing to apply. That var doesn't appear to be defined anywhere in the code. Also, there is a continue; line shown in the unchanged code portion (not part of the patch) that isn't present in the 1.4.16 release code, nor in any of the previous releases I've searched through. These are also present in the #7 patch - which release was that patch rolled against, please?

nginex’s picture

Version: 1.4.15 » 1.4.x-dev
Assigned: Unassigned » nginex

This is very interesting idea, let me take a look and move forward with this

  • nginex committed 7421d43a on 1.4.x
    Issue #3535823 Improve exporting/importing of translations
    
nginex’s picture

Assigned: nginex » Unassigned
Status: Active » Fixed

Done:

- Exports resolve referenced entities in the owning translation’s language.
- Imports offer individual languages and “All languages.”
- Base and custom fields update the correct translation.
- Unavailable translations report errors without aborting valid imports.
- ZIP batches retain the selected language.
- Covered by tests

I did not use existing patch because it was not enough to fully complete what is described.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.