Can we move i18n file from /apps/<project-structure>/i18n to /content/cq:i18n/<project-structure>

[VanitaNa]

In AEM 6.5 can we move i18n file from /apps/<project-structure>/i18n to /content/cq:i18n/<project-structure> and will it be supported in cloud?

[rks1108]

In AEM 6.5, it is possible to move your i18n files (dictionaries) from /apps//i18n to /content/cq:i18n/. Here’s what you need to know for both on-premise and cloud environments:

---

On-Premise AEM 6.5:

• You can maintain i18n dictionaries either under /apps//i18n or /content/cq:i18n/ according to your requirements.
• The /apps location is best for code-managed (Git, deployment) i18n files as it matches the traditional overlay and search hierarchy.
• The /content/cq:i18n location is preferable if you require runtime translation or dictionary editing through the AEM UI, as the /apps folder will be immutable in Cloud Service.

---

AEM as a Cloud Service:

• In Cloud Service, the /apps and /libs are immutable and cannot be changed at runtime. Thus, if you want runtime translation (for example, using the Translator tool for business users to manage translations in the UI), you must use /content/cq:i18n.
• The Sling resource bundle hierarchy always prioritizes /apps over /content, so there must not be identical dictionaries in both locations: if both exist, only /apps will be used for rendering.
• If you plan to migrate to Cloud Service or want to align your code with cloud best practices, it's strongly recommended to move your i18n dictionaries (and especially any language copies) out of /apps and into /content/cq:i18n.

---

Quoting Adobe’s Experience League:

• “/apps [is the] default location for dictionaries with component string translations ... but no runtime editing or translation of dictionaries possible, as /apps is immutable in AEM as a Cloud Service environments”
• “/content/cq:i18n [is an] alternative location for i18n dictionaries if runtime translation of dictionaries is required ... default location where runtime dictionary translation will create language copies.”
• “If a dictionary language copy ... already exists in /apps, and the goal is to make it translatable at runtime in AEM as a Cloud Service, then ... the dictionary language copy in /apps has to either be moved to /content/cq:i18n, or to be deleted in /apps and automatically recreated in /content/cq:i18n.”

Source:

• Internationalizing UI Strings 2/3

[VanitaNa]

Hey, I'm using this folder structure under /content/cq:i18n/rcg-structure/i18n/components but still not able to render i18n values on the pages. I am using this api for getting the i18n value. Can you please help me here?

I18n i18n = new I18n(request.getResourceBundle(pageLocale));

[AmitVishwakarma]

Hi @VanitaNa ,

Based on your folder structure  /content/cq:i18n/rcg-structure/i18n/components the problem seems to be with the hierarchy. That extra i18n folder in the path is likely causing the resource bundle to not be picked up, which is why the translations aren’t rendering.

When AEM resolves i18n strings using request.getResourceBundle(locale), it expects the dictionaries to be located directly under:

/content/cq:i18n/<project>/<dictionary>

So in your case, it should be something like:

/content/cq:i18n/rcg-structure/components/en.json

If there’s an extra level like /i18n/components/, AEM won’t treat it as a valid dictionary path, and it silently fails no errors, just missing translations.
Also, if you're working on AEM as a Cloud Service or planning to migrate, this structure is even more important since /apps is immutable in Cloud, only /content/cq:i18n works for runtime translations.

So try this:

/content/cq:i18n/rcg-structure/components/en.json
​

And double-check the keys using /system/console/jcrresolver or in the logs. In my case, just fixing the folder structure solved everything.

Hope this helps.

Regards,
Amit

[VanitaNa]

Hey @AmitVishwakarma  Thank you for your response.
I have added /content/cq:i18n path to org.apache.sling.i18n.impl.JcrResourceBundleProvider in author it started working. My question is now how can i replicate this configuration. Do i need to log in to each publisher and add this path?

[SantoshSai]

Hi @VanitaNa,

You do not need to manually log in to each publisher to configure the org.apache.sling.i18n.impl.JcrResourceBundleProvider with the additional /content/cq:i18n path.

You should include this configuration in your project codebase so it can be automatically deployed to Author and Publish environments.

Step-by-step:

1. Create/Update the OSGi config in your codebase under:

/apps/<your-project>/config.publish/com.day.cq.i18n.impl.JcrResourceBundleProvider~yourproject.cfg.json

Or using the new OSGi annotation-based format:

/apps/<your-project>/config.publish/org.apache.sling.i18n.impl.JcrResourceBundleProvider.cfg.json

2. Sample config file content:

{
"locale.default": "en",
"preload.bundles": false,
"invalidation.delay": 5000,
"included.paths": [
"/libs",
"/apps",
"/content/forms/af",
"/content/dam/formsanddocuments",
"/content/cq:i18n"
],
"excluded.paths": [
"/var/eventing"
]
}

Replace /apps/myproject/i18n with your actual path.

3. Create corresponding config.author/ directory too (if needed), or config (for common settings across both).

Hope that helps!