Top 6 Translation Features in AEM 6.2
There are few out-of-the-box Translation features in AEM which are used for overall translation management and specifically for translation connector implementation. The base foundation of these features were already laid down with the release of AEM 6.1 however the enhancements in AEM 6.2 have made the implementation and the entire translation process management easier.
Outlined below are few most relevant features
1. Language Copy Management
In AEM 6.1 one had to manually create the language copy and then proceed with end-to-end execution of translation process, thus resulting in an additional execution step. But with AEM 6.2, in the ‘Warning dialog box’ there is an option to ‘Create Language Copy’ by simply clicking on a button. This dialog box doesn’t open if the Language Copy of the content already exists.
2. Accept or Reject Workflow
The feature to accept or reject the content has been introduced to manage the translated content on AEM. This option is available only when the content required to be translated is in ‘Ready for Review’ status. On rejection, addition of comment is also available which can be used to state the reason of rejection. But the project cannot be restarted or the content cannot be sent for translation again, if all the content is ‘Rejected’. Generally the review part is handled by translation services providers, but in case an additional review is required, then this feature would be of a great use.
3. i18n Translations
i18n dictionaries, a translation feature has been introduced in AEM 6.2, where the dictionary automatically queues up into the translation job and which can be sent for translation. Any explicit dictionaries can be added by clicking on ‘Add i18N-Dictionary’ option under the ‘Translation Job’. This would help in translating all the content present under dictionaries which is referenced all over the site, in one go.
4. Traslation Rule Editor File
The most critical requirement for any translation connector to work is to configure correct translation rules file. This file predominantly controls what all properties in a component should be sent for translation and hence this should be set up correctly. Currently this file needs to be populated by either developer or administrator who has good knowledge of components, their properties and business requirements in terms of what needs to be translated and what needs to be ignored. Because of the complexity of generating rules file, an enhanced management console to populate this file is going to be released with AEM 6.3.
5. Multiple Language Management
The project creation process doesn’t provide an option to translate or manage multiple language directly using the project console but different languages can be managed using References tab under Sites section. Internally translation API is capable of handling a single language only. Hence, for multiple languages, multiple projects are created under Project folders, with project names corresponding to target language codes.
6. Translation API
There have been enhancements in translation API for providing the support for XLIFF/XML conversions which helps developer in exporting the correct source file to translator and importing the translated file from the translator. Package com.adobe.granite.translation contains all the relevant classes being used for translation process implementation.
The XLIFF API provides support for converting translation-object-XML to XLIFF, and vice-versa.
The TranslationObject has also been enhanced to support retrieving Translation Object XML/XLIFF input stream. Plus you can get the page preview of Translation Object by creating Zip file containing HTML and its references.
Following methods support these enhancements:
InputStream getTranslationObjectXLIFFInputStream(String xliffVersion)
A high level idea on the usage of these functions is provided in the Bootstrap Framework. The exact flow of translation API and product issues present in XML to XLIFF conversion will be further explained in upcoming blogs.
Hi, is it possible to use a wildcard for a property name to translate all properties?
Till 6.2 it isn’t possible to use a wildcard. The xml expects a definite format and wildcard isn’t supported. I haven’t tested this yet on 6.3.
thank you so much for comprising the top features in such a comprehensive fashion. I am working at the University and need our website in different languages (using AEM is prerequisite to this project). I was wondering in what format I need to give the content files to the translators? Do these files have to be in XLIFF format or can they also simply be a pure content file (thus text), that can easily be imported back to the AEM?
Thank you so much for your help.
XLIFF is the most commonly used file format which is given to the translators for content translation. You can definitely build a solution which converts XLIFF to other formats like text, XML etc. but to import the content back to AEM, XML/XLIFF would be good to have formats. Otherwise, the content would need to be imported into AEM’s content repository by custom code. You can refer to my another blog on translation connector for more details.