Child pages
  • Internationalization and Localization in Sakai OAE
Skip to end of metadata
Go to start of metadata

Proposed Sakai OAE Internationalization Goals

  • Improve visibility of I18N problems and solutions with Sakai 3 UI developer community
  • Encapsulation of all user text (other than content) within the user interface
  • Support for unicode and right-to-left languages
  • Support for (dynamic) user language/locale preferences
  • Support for user timezone preferences
  • Support for localized dates, times, and numbers (input and output)
  • Support for localized mixing of static & dynamic content (perhaps migrate all widgets to
  • Support for localized person names
  • Support for coordinated language/locale preferences between Sakai 2 and Sakai 3 hybrid installations
  • Support for run-time translation updates
  • Support for an easy-to-use, centralized translation server (perhaps
  • Validation of localization of widgets
  • Support for global translations that can be leveraged by multiple widgets (such that translations are not duplicated amongst widgets)

Notes from Sakai 2011 OAE Internationalization BOF are available at

Existing Best Practices for Sakai OAE Internationalization (2010)

These best practices are subject to change, but represent the current localization/internationalization implementation details for Sakai 3.

Kernel Separation & User Interface Encapsulation

The kernel should never pass any user text to the user interface (other than content). All user interface text should be encapsulated within the user interface, where it can be consistently localized.

Current Widget Localization

  • /dev/_bundle contains global properties available to all widgets
  • /devwidgets/<widget-name>/bundles contains local properties for specific widget

Widget Configuration

  • Supported locales must be defined in /dev/_configuration/languages.json
  • Supported locales must be defined in widgets.js (for each individual widget):

"createsite": {
"description":"Create site",
"name":"Create Site",
"i18n": {
"default": "/devwidgets/createsite/bundles/default.json",
"en_US": "/devwidgets/createsite/bundles/en_US.json",
"zh_CN": "/devwidgets/createsite/bundles/zh_CN.json"

  • Each bundles directory should have a default properties file, coupled with additional localized translation properties files (e.g. en_US.json, zh_CN.json, ...)
  • Each widget's (json) properties file must contain the same and description defined in the widgets.js configuration file:

"name": "INSERT SAME NAME FROM widgets.js",
"description": "INSERT SAME DESC FROM widgets.js",
"property": "value",

  • Translations should be in UTF-8 (no need for ascii-encoded unicode)
  • Localized properties encoded within HTML using a "_MSG" prefix and "_" suffix.
    For example, <font color="red">_MSGproperty_</font> would be replaced with the property value defined by "property":"value", from the default.json (or language/locale specific json properties file).
  • If string includes variables, add them in the *.properties file
    For example, template = "_MSG_KEY", and in *.properties = "__MSG_KEY_ $variable"
  • No labels

1 Comment

  1. Sakai OAE Q1 does not support Chinese very well: although the interface could be easily changed to Chinese by changing Language option in preferences, any contents in Chinese, such as page name, group name, and page content, become unreadable once saved. I just want to bring this issue up and would like to help test Chinese support for future Sakai OAE releases.