AEM语言数据源缺所需语言，咨询非覆写方案及覆写可行性

Great question—let’s break down your options clearly, since modifying /libs is always a last resort for AEM developers.

Is overriding /apps/wcm/core/resources/languages a viable solution? #

Short answer: Yes, it’s technically viable, but you need to follow AEM best practices to minimize upgrade risks:

• Instead of replacing the entire /libs node structure, only add the missing language nodes under /apps/wcm/core/resources/languages. Each language node needs:
  • A jcr:title property (the display name users will see in the dialog)
  • A language property (the standard language code, e.g., fr-CA for Canadian French)
• Ensure you inherit or replicate the rep:policy permissions from /libs/wcm/core/resources/languages to your /apps counterpart. This ensures the language-manager-service and translation-config-service can still read the language list properly.
• Keep in mind: When upgrading AEM, Adobe might update the /libs language list, so you’ll need to reconcile any changes with your /apps override post-upgrade.

Better alternatives to avoid overriding /libs #

If you want to stick to AEM’s best practice of avoiding /libs overrides, these options are more sustainable:

1. Build a custom datasource component #

Instead of using the OOTB cq/gui/components/common/datasources/languages, create a custom datasource that combines the default language list with your custom entries. Here’s how:

• Create a Sling Servlet or Sling Model that:
  1. Uses the resource resolver to fetch the default languages from /libs/wcm/core/resources/languages
  2. Adds your missing language entries (e.g., {"value": "xx-XX", "text": "Custom Language"}) to the list
  3. Returns the combined list as JSON (the expected format for Touch UI datasources)
• Update your Touch UI dialog’s select field to point to your custom datasource path (e.g., /apps/my-project/datasources/custom-languages)

This approach keeps OOTB functionality intact, avoids /libs overrides, and makes it easy to maintain custom languages across AEM upgrades.

2. Leverage Language Manager configurations (limited use cases) #

While most docs focus on MSM and translation workflows, the Language Manager’s OSGi configuration (com.day.cq.wcm.core.impl.LanguageManagerImpl) has a supportedLanguages parameter in some AEM versions. However, this is often tied to site-specific language mappings rather than the global dialog datasource. It’s worth checking your AEM version’s OSGi console to see if this works for your use case, but the custom datasource is still more reliable for dialog fields.

3. Site-specific language lists (if applicable) #

If your dialog is tied to a specific site managed via MSM, you can configure site-specific languages in the site’s configuration (under /content/[your-site]/jcr:content/settings/wcm). Then, you can build a datasource that pulls languages from the current site’s configuration instead of the global OOTB list. This is ideal if different sites need different language sets.

内容的提问来源于stack exchange，提问作者toniedzwiedz