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.