Core managed packages can have extension packages created for them that add functionality. We are considering that approach to support multiple languages so that the translation work can be on a delayed release cycle compared to the core package. Any one else doing this?

But the components for one language e.g. translations/ja.translation-meta.xml are already bundled in the core package and that has been released. Eventually these components might be deletable, but progress on the platform delete component capability has been slow.

I assume that components already in the core package cannot also be added to an extension package? Or is there a "last install wins" convention?

(Trying to figure out if we are stuck with the one language having to stay bundled in the core package.)


A colleague suggested that perhaps a different namespace would allow duplicate files and perhaps it would. But in e.g. ja.translation-meta.xml the label e.g. No_Email_Template_Found:


might be implicitly namespace qualified when inside a managed package. If it is the extension could not set a value for it and if it isn't we are back to having a duplicate name for something...

My next step here is to create some extension packages to discover what the constraints are. Results described in my answer.

  • 5
    I suspect you will find you cannot successfully install the package with the duplicate into the org with the core package already installed (assuming same namespace, which would be the case for 2GP "extensions"). We know that this is the case for any Apex classes, for example (even when they are not marked NamespaceAccessible, names must be unique across all packages in the namespace to allow co-installation).
    – Phil W
    Jan 18, 2022 at 11:45

1 Answer 1


I've gone ahead and done these tests:

  • I created a 2GP extension package project using the same namespace as the core package containing a duplicate translations/ja.translation-meta.xml component with one changed label (key unchanged, value changed) in it. In this development environment, the extension package version of the label appeared in the app.
  • I then created a beta package of the extension package and installed the core package and then the extension package in a new scratch org. In this environment, the core package version of the label appeared in the app.

So for this one component type:

  • No errors are reported related to the component being present in both packages.
  • At runtime, which one wins once the packages are installed is either indeterminate or perhaps always the core package one.

For this limited case, my conclusion is that duplicating the same component does not reliably allow the extension to override the core. And as the duplication is not reported, a bit of care is needed to avoid it.

One more test to do early next week of the case where a different label is added in the extension package i.e. new key as well as changed value.


Thanks to a colleague's powerful google-fu, this statement (from the Component Behavior in Packages documentation) makes it clear that extension packages cannot supply translations for labels in a base package:

If you’re designing a package extension, you can include translations for the extension components but not translations for components in the base package.

You must log in to answer this question.

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