How to implement translations i18n on AEM 6.5 SPA (React) Application

Question

Hello All,

We are building SPA site using react framework. We want to leverage Adobe Granite i18n dictionary for translations.

The issue is since SPA will be out side of AEM first before building it as AEM clientlib, we are getting compilation errors while referring to Granite i18n api (as Granite reference is not available to react during compilation)

As an option we are planning to expose dictionary as REST service (servlet) to React application (ui.frontend). Because of this approach there will be huge load on the page when the json grows more.

Instead is there any other way to avoid these compilation errors in react and use client side Granite i18n api in SPA?

Or do we have to follow any different way of implementing i18n for SPA website in AEM 6.5?

Any pointers would be of great help. Please advise. Thank you.

Pawan-Gupta · Accepted Answer

Why don't you consider creating your data dictionary inside /etc area and access it through client side because you will not be enforced for security of accessing resources if creates under /apps (similar pattern we are following in those specific use cases)

There are OOTB AEM Client Side HTTP call API to access such resources

as an example:

var pagePath = CQ.WCM.getPagePath();

//page locale can be received other way also, its just an example
var pageResponse = CQ.utils.HTTP.get(pagePath + '/jcr:content.1.json');
eval('var pageData=' + pageResponse.responseText);
var pageLocale = pageData['jcr:language'];

if (Granite.I18n) {
Granite.I18n.setLocale(pageLocale);
Granite.I18n.setUrlPrefix("/etc/yourprojectpath/i18n/");
Granite.I18n.setUrlSuffix(".1.json");
propName ="keyname";
propValue = Granite.I18n.get(keyNames[i])['sling:message'];
}

earlier the library path located at /etc/clientlibs/granite/utils but later it replaced with /libs/clientlibs/granite/utils and showing as deprecated but not sure its hanging from long time.

Please check and explore this category " granite.utils" as we have customized and created our own based on need.

but yeah, its another way of looking at solving dictionary issue if you dont want to take server route everytime.

(you can call your library directly through path rather depending on category as needed, depend on use case again)

hope it helps!!

Sign up

Login with SSO

Login to the community

Login with SSO