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:
What is the best approach to this?
Solved! Go to Solution.
Views
Replies
Total Likes
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
Views
Replies
Total Likes
*bump*
This is still an issue for us.
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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:
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!
Views
Replies
Total Likes
*bump*
Thoughts on the previous comment?
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
Views
Likes
Replies