Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

Export i18n to xliff doesn't include source string

Avatar

Level 1

We are developing a web site in the apps tree and have a few dozen custom components that authors can use.  Most of them have an i18n folder with the English (en) version of strings used in the components.  The component code easily uses those strings and all is working fine.  However, now we want to translate the strings.  Our translation department requires an XML file in the XLIFF format to translate the strings.  The AEM Translator tool has a way to export the strings and it appears to work, except when you look at the exported file, it is using a sequential number for the string identifier and using the string identifier (the value of "sling:key") as the English source string.  It seems like it should be using the string value (the "sling:message" value) as the English source.

For example, we have a string with the ID "fbTextareaExceeded", with the English string "You have exceeded the maximum field limit of 4,000 characters.".  When exported, we get the following entry in the XLIFF file:

<trans-unit id="11">
    <source xml:lang="en"><![CDATA[fbTextareaExceeded]]></source>
    <target xml:lang="es"><![CDATA[]]></target>
</trans-unit>

which is useless for translation since they can't see the English text they're translating from.  What I think it should be is:

<trans-unit id="fbTextareaExceeded">
    <source xml:lang="en"><![CDATA[You have exceeded the maximum field limit of 4,000 characters.]]></source>
    <target xml:lang="es"><![CDATA[]]></target>
</trans-unit>

It appears that AEM expects the i18n identifier (the "sling:key") to always be the English string text, which isn't viable from a developer maintenance perspective since that English text may change over time, but we'd want the key to stay the same.  Note that we followed examples from several AEM sources that show using programmatic names as the identifier, including foundation components like /libs/foundation/components/search.

Are we missing something, or is this a bug in AEM Translator?

0 Replies