Evergreen internationalization chat
Posted on Fri 17 November 2006 in Libraries
I managed to corner Mike Rylander after Brad Lajeunesse waved his hands in surrender and offered Mike up as a sacrifice to my questions about Evergreen's support for internationalization. If you're travelling to Canada to tout a piece of (or multiple components of) software, you can be sure that somebody in the crowd is going to be interested in knowing how capable that software is of supporting a bilingual community. As Laurentian University is a bilingual institution, I took it upon myself to be "that guy" and grill Mike a bit on that topic. The good news is that he survived the grilling, and didn't earn the nickname "pork chop"; the better news is that it sounds like Evergreen hits most of the internationalization requirements on the head.
OPAC interface can be multilingual; Georgia has a large Spanish community and PINES is in the process of translating the OPAC interface into Spanish
Sorting results alphabetically (for browsing by author / title) is problematic, however:
- PostgreSQL doesn't have a good locale implementation for collating sequences
- Probably not as much of an issue for French / English as it would be for Finnish
Search currently ignores diacritics (e == é == è), but this setting can be changed in TSearch2
Subject heading equivalency is possible for the simple use case of "when I search for History--United States--19th century, also show me records with Histoire--Les Etats Unis--19e annee" (or whatever the real LCSH/RVM equivalence would be)
- This possibility is based on authority records containing both sets of headings -- we can probably rely on / or possibly participate in the EU project to generate equivalence for LCSH, RVM, and German subject headings to seed this data
Staff client is mostly multilingual-ready (hasn't been a priority requirement for PINES):
- Most strings are contained in XML files, but there are still pockets of hardcoded strings
- Switching the locale would immediately load the new strings in the staff client interface
- "JavaScript doesn't have a good sprintf() implementation" -- check to see whether this suggests that token order can't be rearranged. LibX seems to manage to be able to do this.
Forgot to ask about boolean operators (e.g. AND / ET, OR / OU)