The aim of this article is to provide the steps necessary to add support for a new locale in Adaptive Forms in AEM. This is based on a recently implemented real-world use case using AEM 6.5.12.
There is often a need for an Adaptive Form to support new locales that are not available out of the box in AEM Forms. We are going to see 2 examples of adding support for Malay and Singaporean Tamil languages.
Steps to add the support for the two languages
We are going to add support for Malay which has an ISO code of “ms” and Tamil from Singapore which together with the country code is “ta_SG”. The steps to add the support are as follows:
Create a node called languages of nt:unstructured type under /etc if it does not already exist and add the default and the new languages to be supported in a multi-string property called languages as per the below screenshot
ta-sg and ms have been added in the above languages property
2. In the above screenshot we have added ta-sg (Tamil Singapore) and ms (Malay) in addition to the already existing languages.
3. Browse to http://<host>:<port>/system/console/configMgr and open the configuration called Guide Localization Service to add the new languages to be supported as par below.
ta-sg and ms have been added in the above configuration
4. The next steps are to add client libraries for each of the locales for Adaptive Forms and XFA. Create a nt:folder node called languageguidesupport under /etc/clientlibs if not already existing.
5. Once languageguidesupport folder is created, one needs to create cq:ClientLibraryFolder for each new language to be supported. Please refer screenshot below for steps 4 and 5. Please also note the naming convention where both language and country codes have been provided e.g. ta_sg and only language code has been provided e.g. ms.
locale specific clientlibs created for AF and XFA
The clientlib <locale>af should have 2 multi-string properties:
a) categories having a value of guides.I18N.ms
b) dependencies having values xfaforms.3rdparty, xfaforms.I18N.ms and guides.common
The clientlib <locale>xfa should have a single multi-string property:
a) categories having a value of xfaforms.I18N.ms
The above steps (a) and (b) have to be repeated for ta_sg as well.
Please note the locale in all the above properties. In the case of both language and country, the value of the locale in the above property will be of the form languageCountry e.g. frCA, taSG, etc. with no ‘-’ or ‘_’ between the language and country codes.
6. The following folder hierarchy should be present under the <locale>af and <locale>xfa nodes for each locale
folder hierarchy for each new locale
Adaptive Form e.g. msaf or ta_sgaf
The file js.txt can be copied from /libs/fd/af/runtime/clientlibs/I18N/en/js.txt
XFA e.g. msxfa or ta_sgxfa
The file I18N.js can be copied from /libs/fd/xfaforms/clientlibs/I18N/pt_BR/I18N.js and updated as par the locale.
7. Once all the above 6 steps have been taken care of, the final step is to restart the AEM instance so that the newly added locales are available at the time of translating the Adaptive Form.
Steps to translate the form
The form can be translated to the required languages by following the below steps
Browse to https://experienceleague.adobe.com/docs/experience-manager-65/forms/adaptive-forms-advanced-authoring/using-aem-translation-workflow-to-localize-adaptive-forms.html?lang=en and follow the steps.
You should be able to see the newly added locale at the time of adding the dictionary
ms and ta are visible in the dropdown
3. Once the translation project is created, the job has to be executed following the normal AEM process of translation. Post successful translation, locale specific nodes should be automatically created under assets node in the adaptive form.
locale specific nodes created for ms, ta-sg and zh-cn post executing the translation job
Please note that default machine translation provider may not support translation for some of the languages in which case we will browse to the AEM translator at http://<host>:<port>/libs/cq/i18n/translator.html and translate manually by either exporting and importing XLIFF files and providing to human translators or making the changes on the translator UI itself.
We will have to select the dictionary node in the translator UI and then update the content for each language as par the below screenshot. Once done, the form needs to be published by following normal AEM replication mechanism.
translated content to be authored or XLIFF to be exported or imported to be provided to a human translator
Viewing the translated form
Once the translation has been completed, you will observe that unlike site translation where a separate language node gets created in the site hierarchy, nothing of this sort happens in case of Forms translation. You can invoke the translated form through the Preview mode and URL that looks like https://<host>/content/forms/af/survey.ms.html or https://<host>/content/forms/af/survey.ta-sg.html. Please note the locale in the selector.
Another way to view the translated form is to invoke the URL https://<host>/content/forms/af/survey.html?afAcceptLang=ms or https://<host>/content/forms/af/survey.html?afAcceptLang=ta-sg. This URL is not cacheable.
An important point to note is that the translated content will not be viewable in the Edit mode of the form.