...thought I'd throw this one out since we've opened the doors on 2.4.1 to new ideas.

  • Internationalization (aka internationalisation) is the processing of generalizing software so that it can be localized (aka localised). This usually involves taking hard-coded strings and turning them into references into a separate source that is identified with a specific natural language. Multiple sources permit multiple natural languages. For example, in Java (the programming language in which JSPWiki is written), there are internationalization (i18n) and localization (l10n) features based around used of a "ResourceBundle", such that if a user's individual localization is known and the ResourceBundle is available for that natural language, those portions of JSPWiki that have been internationalized can then be delivered in the language of the user. This involves changes to (a) the JSPWiki source code; (b) the JSP page templates; and (c) the page content itself.

(You'll sometimes see internationalization abbreviated as "i18n", which is "i" + 18 characters + "n". Similarly, localization becomes "l10n".)

I've got a requirement to be able to handle multiple languages, and it would seem that we might want to be able to, while maintaining complete backwards compatibility with the existing APIs, add in methods in appropriate places that can specify a language using the ISO standard language codes (probably ISO 639-1, the two digit codes, though we could go for the more complicated ISO 639-2 3 digit codes, but I don't see the benefit [1]). The W3C has very recently released a new language tag draft [2] which points to the IETF Best Common Practice (BCP) document at [3]. These all point canonically to the IETF Internet-Draft "Tags for Identifying Languages" [4], which provides the way in which the various language and country tags can be combined.

And yes, this all gets very complicated very fast. But one benefit to this is that it's all handled in these specifications -- the only thing we'd need to do in JSPWiki is add a String parameter that permits the specification of a language, and if the resource isn't available in that language the default (current) behaviour applies.

In looking briefly through the JSPWiki API I know that WikiPageProvider would need internationalization (i18n), but what others would as well? If someone can provide me with any others I'll include them in my API proposal. If everybody is against this idea I'll drop it, just let me know. It would be one of those hopefully transparent APIs, where the default behaviour remains *unless* the resource exists in the specified language, in which case it is returned.

I am considering that the metadata API will need i18n as well.

And yes, a wiki page is brewing...



[#1] Codes for the Representation of Names of Languages,
US Library of Congress (registration authority for ISO 639)
[#2] Language Tags and Locale Identifiers for the World Wide Web,
W3C Working Draft 19 April 2006
[#3] Tags for the Identification of Languages, RFC 3066
[#4] Tags for Identifying Languages,
Obsoletes RFC 3066 (if approved)


Thanks for your suggestions...I am doing a Wiki Beta with one of the Quest Software Communities with JSPWiki. They are specifically asking for exactly what you are proposing.

Brian Nettles

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-3) was last changed on 26-Feb-2008 23:16 by