CustomObjectTranslations and CustomFieldTranslations are not pulled correctly

[Schuchie]

Summary

The current project has 2 packages in the SFDX project json: PackageA and PackageB. Package A is marked as default package.
Package B currently contains only the object's .objectTranslation.xml. If you now retrieve the object, e.g. by right-clicking in the file (vscode), by command or Package.xml, the following error occurs. Mostly a CustomFieldTranslation is retrieved into the default, then the process is interrupted:

Steps To Reproduce:

1. Create an Object with 2-3 Fields.
2. Translate them via the CustomObjectTranslation
3. Pull the CustomObjectTranslation of the created object to PackageA

4. Remove all field translations and move only the object translation to the PackageB

5. Pull again the CustomObjectTranslations

Expected result

Retrieve all fields and update the object-translation in the folder where the object translation is already. Don't throw an error.

Actual result

One field gets pulled into the default package and following error occurs:

Metadata API request failed: Component conversion failed: Unexpected child metadata [/PackageA/main/default/objectTranslations/vDMC_ArticleList__c-de/vDMC_ArticleListNo__c.fieldTranslation-meta.xml] found for parent type [CustomObjectTranslation]

System Information

• Which shell/terminal are you using? (e.g. bash, zsh, powershell 5, powershell 7, cmd.exe, etc.)

• If you are using sfdx

{
  "cliVersion": "sfdx-cli/7.194.1",
  "architecture": "darwin-arm64",
  "nodeVersion": "node-v18.11.0",
  "osVersion": "Darwin 22.4.0",
  "shell": "zsh",
  "rootPath": "/opt/homebrew/lib/node_modules/sfdx-cli",
  "pluginVersions": [
    "@dxatscale/sfpowerscripts 20.20.3 (user)",
    "@oclif/plugin-autocomplete 2.1.6 (core)",
    "@oclif/plugin-commands 2.2.11 (core)",
    "@oclif/plugin-help 5.2.8 (core)",
    "@oclif/plugin-not-found 2.3.22 (core)",
    "@oclif/plugin-plugins 2.4.3 (core)",
    "@oclif/plugin-search 0.0.14 (core)",
    "@oclif/plugin-update 3.1.8 (core)",
    "@oclif/plugin-version 1.3.1 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.32 (core)",
    "@oclif/plugin-which 2.2.17 (core)",
    "apex 2.2.7 (core)",
    "auth 2.7.10 (core)",
    "community 2.2.8 (core)",
    "custom-metadata 2.1.9 (core)",
    "data 2.3.8 (core)",
    "info 2.6.2 (core)",
    "limits 2.3.9 (core)",
    "org 2.6.2 (core)",
    "packaging 1.16.2 (core)",
    "schema 2.3.4 (core)",
    "settings 1.4.2 (core)",
    "signups 1.4.8 (core)",
    "source 2.8.0 (core)",
    "telemetry 2.1.3 (core)",
    "templates 55.4.4 (core)",
    "trust 2.4.5 (core)",
    "user 2.3.5 (core)",
    "@salesforce/sfdx-plugin-lwc-test 1.0.1 (core)",
    "sfdmu 4.26.10 (user)",
    "sfdx-cli 7.194.1 (core)",
    "sfpowerkit 6.0.1 (user)"
  ]
}

Additional information

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
	<types>
		<members>vDMC_ArticleList__c-de</members>
		<name>CustomObjectTranslation</name>
	</types>
	<version>57.0</version>
</Package>

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[mshanemc]

Does the problem happen if you retrieve via the CLI commands?

If so, can you share the command and the output?

If not, I can transfer this issue to the VSCode extensions repo

[Schuchie]

Same error appears in the cli:

sfdx force:source:retrieve -m "CustomObjectTranslation:vDMC_ArticleList__c-de"

Output

Retrieving v57.0 metadata from user@salesforce.com.develop using the v56.0 SOAP API
ERROR running force:source:retrieve:  Metadata API request failed: Component conversion failed: Unexpected child metadata [/Users/nils/repository/salesforce/Kunde/src/PackageA-crm/main/default/objectTranslations/vDMC_ArticleList__c-de/vDMC_ArticleListNo__c.fieldTranslation-meta.xml] found for parent type [CustomObjectTranslation]

[mshanemc]

I'm not able to replicate this. We have a sample project for translations that we use for testing here: https://github.com/salesforcecli/plugin-source/tree/main/test/nuts/customTranslationProject

I sent this to a scratch org, and then retrieved it via
-x with your manifest structure (changed to our sample file names)
force source retrieve -m CustomObjectTranslation:customObject__c-es
I also tried deleting the stuff inside force-app and having it retrieve via -m and that worked fine.

based on that error message, do you already have a file called /Users/nils/repository/salesforce/Kunde/src/PackageA-crm/main/default/objectTranslations/vDMC_ArticleList__c-de/vDMC_ArticleListNo__c.fieldTranslation-meta.xml in your local project? That's what it's choking on.

If so, where did that file come from? Is there anything weird about it? ex: the <name> tag not matching the file name?
Anything look odd in the objectTranslation-meta.xml ?

[Schuchie]

I have copied your translation setup once and divided it into 2 packages. Package A is Default and Package B contains the CustomObject-Translation. Here I have deliberately removed the translation field. This must be set up on the Org then once and then my reported bug should occur when retrieving.
The error always occurs when, for example, the translations were set up 5 weeks ago and packed into the repo in package B. If now a new field and new translations are added, they have to be included in the repo. Therefore a retrieve would take place. And now it comes to the error. My guess is that SFDX erroneously pulls the newly found field translation into the default package instead of pulling it to the other object translations or an error occurs and it simply stops at the first field.

https://github.com/Schuchie/sfdx-translation-bug

[mshanemc]

OK, that's replicable. Was the working before and now it's broken, or has it ever worked?

[git2gus]

This issue has been linked to a new work item: W-13193003

[Schuchie]

@mshanemc I think sometime before it worked, but I cannot define a specific date.

[Schuchie]

@mshanemc any update on that?

[mshanemc]

nothing yet. it's replicable, but we don't have a fix for it.

[Schuchie]

Hey @mshanemc,
Is there already a date set here when a fix should come? Or when will be started with the bug?

The bug costs us an enormous amount of time, because we have to manually pull all translations every time. Normally the admin could also do this via the DevOps Center.

[Schuchie]

bump

[petter-eikeland]

We are also experiencing this bug as well when trying to pull changes when having a CustomFieldTranslation file locally

[shetzel]

@salesforce/plugin-deploy-retrieve v1.19.3 has the fix for this. You can install that plugin now and test it out, or you can wait for the CLI release candidate tomorrow, or it'll be in the production CLI in a week.

Note that the behavior of CustomObjectTranslation and CustomFieldTranslation is slightly different from other parent/child decomposed metadata types like CustomObject and CustomField. CustomFieldTranslation is defined differently as a type in the server and cannot be separated from its parent, whereas CustomField can exist separated from its parent. In practice, this means that wherever a CustomObjectTranslation exists locally, all related CustomFieldTranslations will be retrieved peer to its CustomObjectTranslation. But new CustomFields that are created in the org will be written to the default package directory and not peer to its parent CustomObject if that CustomObject is in another package directory.

[petter-eikeland]

@shetzel Seems like the fix introduced in 2.16.7 works!

[shetzel]

Thanks for the confirmation @petter-eikeland !

[Schuchie]

@shetzel looks like its fixed. Thx!

[jshackell-sfdc]

This issue is fixed in version 2.16.7 (Nov 8, 2023).