Paris Pre-conference (Internationalization)

Following is summary of the brain-storming session on future directions for Sakai Internationalization

• Add a "gobbly-gook" locale for testing – this can be used to verify coverage of a tool's localization. This locale could be enabled on test servers, but not in production.

• Email Templating could provide a solution to SAK-13209 (Email notification doesn't respect user locale) by getting rid of hard-coded english email text. They must fall back to a default locale if translation isn't available. BOF on Tuesday at 13:30.

• We need to lower barriers for translation. One suggestion is to provide a community translation server, using the open-source Eclipse Babel Project (http://www.eclipse.org/babel/). There will be a presentation on Eclipse Babel on Tuesday at 10:00.
  • Perhaps we can team up with other open-source projects (e.g.JA-Sig, Kuali, etc) to build a community translation server for higher ed.
  • Perhaps Sakai Foundation can help with contacts, etc for finding funding (grant) support

• We need to differentiate between JIRA bugs and enhancements, with a higher priority on fixing bugs. Internationalization should be mandatory part of QA Process. Suggested prioritization:
  • Blockers. This issues are producing errors to users in production systems
  • Priority issues. Issues related to a minimun quality standard on i18n (for example if a tool is not using ResourceLoader). This are the things of requirements that all the tools should have before go to production
  • Issues. All the i18n things that have to done in the platform but are pending.
  • New features to add and improve the platforms. Like the html editor in some languajes or the language for a site preference.

• We will soon have a QA server in Japan to consistently test a UTF-8 locale.

• It's good to test on servers in different time zones (+/- GMT) – since we have QA servers across the world, we should encourage QA testing on more than one server to help catch date-related problems.

• We will soon have a QA server with both email and UTF-8 enabled at IU – we should try to get more QA servers to support UTF-8

• Different translation workflows at different institutions: Japan/Nagoya has one translator while Spain/Valencia employs graduate students to help.

• We should look into automated code reviews for common localization errors (e.g. hard-coded strings)

• Several problems with the Sakai rWiki were discussed, written up, and after the meeting, a workaround was provided.

Paris Conference (Internationalization)

The Paris Conference Internationalization session continued the discussion on many of the topics discussed at the pre-conference (above). Additionally:

• We need to find a way to resolve conflicts between translations when there is no clear institution lead with translating a particular language (e.g. Dutch).

• Lowering barriers for translation (e.g. Translation Server) is a big overall issue. Existing tool functionality could be leveraged, e.g. SourceForge ResourceProperties Editor, Eclipse Babel, Smolny PropertyTransferer, http://pootle.sympa.org/.

• SAK-8007 (Sorting/Displaying of names) is an issue across many locales/institutions

• SAK-8908 (Tool titles and Page titles should be displayed in user's preferred language/locale) should have development resources and resolution soon.

• The need to expand adoption of Sakai in Europe is closely tied to Internationalization issues. Frank Benneker's BOF set the stage for a European focus on Sakai may provide resources for internationalization.