This session aims to solve the problem of how client-side language strings can easily be hard coded since browsers cannot even report user locale accurately. Not only is there a need to i18n, but a greater need to tap into sakai's i18n powers. UCT work on client-side i18n wrt. Course Evaluations will be showcased. From simple alerts, validation errors and prompts sakai users can see quick responses to their interaction but there is no easy way of ensuring that these messages are internationalized. Using Entity Broker and a tool-level Entity Provider, the Course Evaluations tool currently runs an i18n javascript codebase that implements the powerful i18n standards of Sakai. This session will outline the work at: http://tinyurl.com/yhora2v
Neo4j - How KGs are shaping the future of Generative AI at AWS Summit London ...
That’s a nice UI, but have you internationalized your Javascript?
1. That’s a nice UI, but have you internationalized your JavaScript Lovemore Nalube Developer University of Cape Town 17 June 2010
2. Overview Evil ‘n’ Good code Difficulties of i18n-sing JS Why Sakai's needs are unique RESTful access to a Sakai Message bundle DEMO: Course Evaluations and the SMS Credits Transfer tool 2 11th Sakai Conference - June 15-17, 2010
3. Sample nasty code Common evil case: Good case: var response = xhr.status; alert("You have an error caused by" + response); var response = xhr.status; alert(messageLocator.getString( “ui.site.error”, response); 3 11th Sakai Conference - June 15-17, 2010
4. Difficulties of i18n-sing JS Cannot rely on browser locale Most users are unaware of the presence of this browser setting JS alone cannot get Sakai Preferences locale setting Do we have to re-create message bundles? Inconsistencies, more effort, harder to maintain navigator.language /* Mozilla */|| navigator.userLanguage /* IE */ 4 11th Sakai Conference - June 15-17, 2010
5. Why Sakai's needs are different 2 stages of language customization: User preference Server configuration Sakai’s own locale lookup is used in many tools Extend this ability to client side tools Date formats vary 5 11th Sakai Conference - June 15-17, 2010
6. Fun stuff Steps to follow 11th Sakai Conference - June 15-17, 2010 6
7. Step 1: RESTful access to a Sakai Message bundle Tool level Entity Provider creates a fixed URI for getting a message bundle In a webapp, make a provider class: ResourceLoader resourceLoader = new ResourceLoader(MESSAGES_BUNDLE_DIR); // eg. where MESSAGES_BUNDLE_DIR = "org.sakaiproject.evaluation.tool.bundle.messages"; *** NEEDS TO BE A FOLDER! return the key-value equivalents of resourceLoader.entrySet().iterator(); in (for example) HashMap 7 11th Sakai Conference - June 15-17, 2010
8. Step 2: RESTful access to a Sakai Message bundle POM modifications creates a fixed URI for getting a message bundle Depend on Entity Broker: 8 11th Sakai Conference - June 15-17, 2010
10. Step 4: RESTful access to a Sakai Message bundle Start using: var removalString = fluid.messageLocator( messageBundle )(["administrate.general.enable.response.removal"]); *** For values with variable replacers like {0} as in removeitem.removed.user.message: "Item ({0}) has been removed", // Decoding the key "removeitem.removed.user.message". //RESULT removalString = "Item (3) has been removed" var removalString = fluid.messageLocator( messageBundle )(["removeitem.removed.user.message"], 3 ); 10 11th Sakai Conference - June 15-17, 2010
11. Step 4.5: RESTful access to a Sakai Message bundle Simpler way to use: Get a language string like this: //retrieve the message strings for key messageLocator: function(key, params){ return fluid.messageLocator( messageBundle )([key], params); }, var alertError = evalTemplateUtils.messageLocator("evalsettings.email.sent.from", helpEmail.toLowerCase())); //if helpEmail.toLowerCase() = help@sakaiproject.org //prints: All emails will be sent from help@sakaiproject.org 11 11th Sakai Conference - June 15-17, 2010
12. Course Evaluations SMS Credits Transfer Demo 11th Sakai Conference - June 15-17, 2010 12