...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...

Thanks,

MurrayAltheim

%%(font-size:80%;border-top:1px solid #888888;padding-top:1em;margin-top:2em)
; [#1] ''Codes for the Representation of Names of Languages'', \\ US Library of Congress (registration authority for ISO 639) : [http://www.loc.gov/standards/iso639-2/langcodes.html]
; [#2] ''Language Tags and Locale Identifiers for the World Wide Web'', \\ W3C Working Draft 19 April 2006 : [http://www.w3.org/TR/2006/WD-ltli-20060419/]
; [#3] ''Tags for the Identification of Languages'', RFC 3066 : [ftp://ftp.rfc-editor.org/in-notes/bcp/bcp47.txt]
; [#4] ''Tags for Identifying Languages'', \\ Obsoletes RFC 3066 (if approved) : [http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt]
%%

Murray,

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