Translation Handling for Custom Dropdown Metadata in AEM Assets

[Ravi_Joshi]

Hi There,

We have a requirement where several custom dropdown fields have been added to the metadata schema of our assets (DITA files).

During the translation process, AEM currently picks up the dropdown key value (the stored value) instead of the display label. This key is then sent for translation and applied to the translated language copy. As a result, the translated copy fails to load the corresponding dropdown option correctly in its properties.

Additionally, all dropdown labels and options remain in English after translation. We would like to explore whether there is an OOTB approach in AEM to automatically localize or translate these dropdown labels across language copies.

Thanks,

Ravi Joshi

[Karishma_begumSh]

Hi @Ravi_Joshi 

AEM saves dropdown keys, not labels, in metadata. During translation, these keys (not the visible labels) are sent and applied — so translated copies can’t map dropdowns correctly.

AEM doesn’t translate dropdown labels automatically.
Labels remain in English because they’re defined in the metadata schema, not translatable content.

Solutions

1. Use i18n Dictionaries (Recommended, OOTB)
2. Store dropdown labels as i18n keys (e.g., status_inprogress).
3. Add translations in /apps/your-project/i18n/<locale>/translation.json.
4. UI automatically shows localized labels per language copy.
5. Custom Translation Handler
6. Map translated labels back to keys after translation (custom code).
7. Localized Metadata Schemas
8. Create schema copies per locale with translated labels (harder to maintain).

 Use i18n dictionaries for dropdown label localization; keep stored keys language-neutral.

Hope this helpful:)

Regards,

Karishma.

[Ravi_Joshi]

Hi @Karishma_begumSh ,

We’re looking to translate only the dropdown values in DAM metadata forms based on the language node under which the asset resides, rather than the current behavior where i18n follows the AEM user preference (which affects the entire instance UI).

Requirement:

• When editing an asset under a specific language root (e.g., /content/dam/…/en vs /…/fr), the dropdown values (options) should render in that language, independent of the user’s UI locale.

Questions:

1. Is there an OOTB configuration to bind i18n resolution to the asset’s language root for schema form dropdowns (DAM Admin) instead of the user preference?
2. If not, is there a recommended pattern to scope i18n to the asset context for form field rendering OOTB or any custom solution?

Let me know your thoughts on the above questions.

Thanks,

Ravi Joshi

[ManviSharma]

Hello @Ravi_Joshi ,

AEM stores the dropdown key (value) in metadata, not the display label. During translation, this key gets exported, causing mismatches in the translated copies as the dropdown cannot resolve the correct option.

OOTB, AEM doesn’t automatically translate or localize dropdown labels in metadata schemas. The recommended approach is to use AEM Tags instead of static dropdowns, as tags support localized titles natively and display correctly across language copies.

Alternatively, you can implement a custom translation workflow step to map dropdown keys to labels before export and back to keys after import.

[Ravi_Joshi]

Hi @ManviSharma ,

We have explored the tags approach, but is there a way to restrict it to single selection? By default, it always allows multiple selections, and we couldn’t find any configuration to make it single-select.

The reason we need this is that, based on the selection of one field, we want to dynamically load another field with a corresponding set of tags.

Thanks,

Ravi Joshi

[kautuk_sahni]

@Ravi_Joshi Just checking in! Were you able to get this resolved? If you found your own solution, sharing the details would be a big help to others who might face the same issue later on. And if one of the replies here helped, whether it fully solved the problem or simply pointed you in the right direction, marking it as accepted makes it much easier for future readers to find. Thanks again for helping close the loop and contributing to the community!

[Ravi_Joshi · Accepted solution]

@kautuk_sahni ,My apologies for the delayed response on this thread. Based on the suggestions provided by fellow community members, we evaluated both approaches and finalized the following solution.

Solution Approach

1. We use CQ Tags for metadata fields wherever localization or translation is required.

2. For use cases where selectable options are needed without translation, we use dropdown fields.

Limitations of This Approach

• Out-of-the-box, dependencies cannot be established between CQ Tags and dropdown fields.

• Dropdown values are not included in translation workflows, as they are not resolved based on the current locale-specific asset nodes.