[OPEN-ILS-DEV] Localization of OpenILS

[Dan Scott]

On 07/11/2007, Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> wrote:
> In short:
>
> OpenILS, as it current is, is US-centric and needs a bunch of changes to make
> it useful outside of the USA and Canada.

Well, it needed/still needs some changes to be used in Canada to start
with as well. So that's not a huge surprise. We're still taking baby
steps here. The current catalogue was designed with Georgia users in
mind, with the intention of supporting language switching between
English and Spanish purely for users who live in Georgia. Supporting
translations is one thing; supporting localization and
internationalization is another, but progress is being made on these
fronts too.

> Longer story:
>
> I am currently translating, as much as I am able to given the fact I no longer
> work at a library and library-specific lingo is not my forté, the opac.dtd
> into Dutch (for the Netherlands).
>
> During the editing I found a lot of specific references that readily assume
> either a USA or Canada way of dealing with data, especially when it comes to
> addresses, or telephone numbers (county or phone number in XXX-YYY-ZZZZ format
> for starters).
>
> Take for example a typical (fictive) Dutch address:
>
> Jan Hoogslag
> Jan van Beckerstraat 28a
> 9452 XJ Sappermeer
>
> Telephone numbers according to: XX-YYYYYYYY or XXX-YYYYYYY or XXXX-YYYYYY
>
> and a fictive Japanese address:
>
> 〒283-0024                       (postal code)
> 山形県天童市久野本2-54-105       (prefecture, city, street + number)
> 田中一廣                    (last name, first name)
>
> telephone numbers according to: XXX-YYY-ZZZZ or XXXX-YY-ZZZZ or XXXX-YYY-ZZZZ

Yes - even for US vs. Canada there are differences between the regex
used to validate a zip code vs. a postal code. I've posted an example
of a small change that would be used in the staff client to accomplish
this.

More challenging, I think, will be the possibility of needing more and
different patron ID fields for different locales -- as you allude to
below.

> Also using my knowledge of various other countries around me as well as my
> East Asian knowledge I can point out that if the goal is indeed to get users
> outside of the USA and Canada proper i18n and L10N needs to become a goal. I
> think this will probably also have repercussions for the database schema and
> other parts of the system.

Agreed, although I would suggest that the current system accommodates
country-by-country specialization reasonably well. For example, it
would be possible to patch the system to support Japanese norms for
telephone numbers, addresses, etc, and to present that interface in
different languages. However, at present it would be very difficult to
run a system that supported patrons with addresses from different
countries -- say, if the Hague were to run Evergreen, much more
extensive changes would be required. "Proper i18n and l10n" as you say
:)

Also, at present I don't think there's a well-defined way to keep
country-specific schema changes in sync with the development trunk
code changes.

"Other parts of the system" will include things like currency / number
/ date / time formatting, which has to be handled at run-time.

> This is also leaving aside the duplication of various translation terms. Using
> a system based on message catalogs would avoid the kind of duplication that
> now goes on in the system using dtds.

By "message catalogs" do you mean maintaining the translations in
gettext PO format? As I've mentioned in-channel, I would like to move
towards that for exactly this reason (as well as the wealth of
translation infrastructure that would help support translation) and
recently installed babel (http://babel.edgewall.org) in the hopes of
being able to extend some of the supported file formats. Also, the
staff client does use a  reimplementation (for flexibility) of XUL's
string bundles, called "message catalogs", that will enable switching
on the fly.

The challenge that I face at this point is a lack of resources in
accomplishing this goal. Well, that, and spreading my efforts across a
few too many tasks. More hands (especially with big, knowledgeable
brains like yours behind them) would certainly help!

> Just my € 0,02.

You € 0,02 is worth a lot - thanks for the feedback.

-- 
Dan Scott
Laurentian University