Continue work on i18n

[anonymous]

At the end of 2008, some work has been done on i18n. There is a sample you can look at (kauri-i18n-sample), and also some docs.

Since development is still ongoing, this issue currently serves as a reminder list of what's still todo. When we reach an initial stable state, we can close this issue and make separate issues for the remaining things.

Here's the list:

• the bundle restservice should have good caching in order to be production-ready, currently it always generates the JSON on the fly. Partly, this could be handled by a generic REST-service-level caching component.
• nice to have's for the bundle restservice:
  • currently all bundles are accessible over the REST-service, we should have some way to restrict what is publicly accessible
  • also support an XML representation next to the json representation
  • let mixed content survive in the json (by using strings containing html). Currently only the character content will survive.
• number and date formatting:
  • the server defaults should be configurable. E.g. what is the default date/time/... format, what is a "short date", a "long date", ... Currently this is very hardcoded.
  • the locale settings cookie could be extended with default date/time/datetime pattern, decimal dot and decimal separator symbols. Currently the formatting is determined by the locale selection, which hence influences both the language and the formatting.
• resource bundles should reload on changes (when in source mode), currently requires a Kauri restart
• resource bundles should by customizable by deployer-users. Idea is to have some directory into which they can drop "language packs" (basically, normal kauri bundles with KAURI-INF/i18n). Nice to have: support direct editing on extracted file layout, with immediate pick up of changes.
• during startup, set i18nmanager on current thread so that it is available to components which need to access i18n during startup.
• add some helpful debug-logs to find out if correct locale is being used: in locale-assignment, in template i18n() function
• client-side aspect:
  • snippet to define a kauri.i18n javascript object containing the locale settings
  • forms integration
• need to think about the threadlocal state and template execution attributes (as it is currently done, one wouldn't have been able to add the i18n themselves without touching the kauri codebase)
• 'i18n settings form snippet':
  • should be internationalized itself
  • loads slow, need to find out why (the selection lists: slow on server or client side? loading of fonts for foreign locale names?)
  • after selecting locale, show sample date and number formatting, after selecting timezone, show current time in that timezone
  • form should allow to remove the cookie and go back to the default
• Documentation
• Sample
  • add link to rest-service that returns the aggregated bundle or a specific language in JSON format

The best thing to tackle first is the client-side stuff, just so that we can check everything fits together as intended.

[mpo]

note: the issue for building the client-side translation support is #81

[mpo]

linked to #272 as well.