2

I'm working on a second-generation managed package where some LWC need to be translated into German. The translations are done using Custom Labels. I added labels and translations folders into the project before creating a new beta version. The folders contain Custom Labels in CustomLabels.labels-meta.xml and actual translations in de.translation-meta.xml accordingly. I use sf package version create --package "App Name" --code-coverage --wait 10 -v dev-hub-alias --installation-key-bypass to create a new beta version and get this error:

Version create.... Create version status: Error

(1) de: Not available for deploy for this organization

When I removed the translations folder - the new version was created successfully.

Has anyone faced this issue? It does seem to me that the problem is in the temporary org's settings which gets created when a new beta version is generated. This org is handled by SF in the background solely for the package creation purposes and it's impossible to get access to it. When we deploy translations to any org, the Translation Workbench settings must be enabled which can not be done for the temporary org. Here is the sfdx-project.json I use:

  "packageDirectories": [
    {
      "path": "force-app",
      "default": true,
      "package": "App Name",
      "versionName": "ver 1.5",
      "versionNumber": "1.5.0.NEXT",
      "versionDescription": "",
      "ancestorId": "HIGHEST"
    }
  ],
  "namespace": "test_namespase150",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "58.0",
  "packageAliases": {
.................
    "First [email protected]": "04t07000000DCsOAVQ",
    "First [email protected]": "04t07000000DCtWADI",
    "First [email protected]": "04tJ6000000Y0efIPC"
  }
}

Is there anything to be added into this file just like this would've been done for project-scratch-def.json ?:

"settings": {
   "languageSettings": {
     "enableTranslationWorkbench": true
   }
}
1
  • 2
    We have pretty much exactly the same setup, including the settings.languageSettings.enableTranslationWorkbench value in our scratch-def.json, and have no problem with this. We use "Partner Developer" edition for the scratch orgs, but I don't think that makes any difference. We do explicitly define the "definitionFile": "config/scratch-def.json" in our package's packageDirectories entry in the sfdx-project.json.
    – Phil W
    Commented Aug 14 at 15:55

1 Answer 1

1

There is a reason for the package version create command to have the --definition-file parameter available:

Path to a definition file similar to scratch org definition file that contains the list of features and org preferences that the metadata of the package version depends on.

When you issue the package version command, what happens behind the scenes is the creation of a disposable org in which your metadata is then pushed, compiled/checked and then frozen for distribution (hence why you get the package id for installation at the end). The key here is that at some point an environment (an org) is created, this implies that the org created must have the same settings as your development environment and contain whatever is necessary for your package to function, including the available settings.

Because your package now relies on the Translation Workbench being enabled, you must change your build pipeline to use the command specifying the definition file then.

1
  • 2
    Or add the definition file in sfdx-project.json as I suggested, which makes more sense to me.
    – Phil W
    Commented Aug 14 at 16:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .