Expand my Community achievements bar.

SOLVED

Disable WCM Core I18N Dictionaries

Avatar

Former Community Member

Our platform is used by English speaking content authors to author content in all languages.

We wish to force the WCM authoring interface to use English for all out-of-the-box strings (editbars, context menus, sidekick, etc), while still using the i18n bundle for our own strings.

So far:

  • no Tried setting the user's (and group's) preferences > language to English; WCM was still localized, even after re-logging in.  Even if it worked, I imagine it would use English for our own localized strings, which is not acceptable.
  • no Considered implementing RequestLocaleResolver to set the locale to 'en' for all author requests in WCM edit mode.  Again, I imagine it would use English for our own localized strings, which is not acceptable.
  • no Considered overlaying the WCM i18n dictionary, /libs/wcm/core/i18n.  I doubt this will work unless we overlay each of the i18n files with all of the English strings.  Less than desirable.
  • no Same as the overlay approach, but instead adding a new i18n dictionary under/apps/myProject/, again including all English strings as "translations" in the other languages.  And again, less than desirable.
  • no Considered removing the WCM i18n dictionary, /libs/wcm/core/i18n.  This is, of course, discouraged.

​What is the best approach to this?

1 Accepted Solution

Avatar

Correct answer by
Level 10

Dave Hughes wrote...

*bump*

This is still an issue for us.

 


Hi Dave Hughes,

   Programmatically there would be better way & top of my head can't recall immediately. Also seeing first time such kind of requirement.    How about setting acl deny for /libs/wcm/core/i18n. so that for any non admins your requirement is meet & is upgrade safe.

Thanks,

Sham

Twitter: adobe_sham

View solution in original post

5 Replies

Avatar

Correct answer by
Level 10

Dave Hughes wrote...

*bump*

This is still an issue for us.

 


Hi Dave Hughes,

   Programmatically there would be better way & top of my head can't recall immediately. Also seeing first time such kind of requirement.    How about setting acl deny for /libs/wcm/core/i18n. so that for any non admins your requirement is meet & is upgrade safe.

Thanks,

Sham

Twitter: adobe_sham

Avatar

Former Community Member

Thanks Sham, that was exactly the type of suggestion that I was hoping for.

I've ACL denied everyone (jcr:all) on these dictionary nodes:

  • /libs/granite/i18n
  • /libs/wcm/core/i18n
  • /libs/mac/i18n

When I use the translator tool as a non-admin Administrator user, I am unable to load those dictionaries.  This is expected, as per the ACL rules.  When a page is loaded and the dictionary is retrieved, however, the WCM editor strings are still being included.  See dictionary json (search for "Edit:"; the goal is to eliminate that translation).

Is the issue that I have missed some dictionaries?  Is it possible for i18n dictionaries to exist but not appear in the Translator Tool's dictionary list?  If so, is there anyway to find ALL dictionaries?

Thanks again!

Avatar

Level 2

We faced the similar requirement to fetch I18n values at client side using Granite.i18n Library

This is what I did.

1) Created a custom servlet which returns JSON response similar to ResourceBundleExportServlet

2) Loaded the bundle using basename and locale parameter - ResourceBundle resourceBundle = req.getResourceBundle(basename, pageLocale);

3) Added 'sling:basename="basename_constant"' in language specific i18n xml file which resides in /apps/project-name/i18n folder. In my case, I am setting the value of locale itself ex: "zh_cn"

4) In clientlibs javascript file setting Granite.I18n.setUrlPrefix("/bin/custom/i18n/dict."); to fetch from custom servlet URL.