« Making the MARC21 specification usable via XML
From libraries to Skynet »

Library jargon, or translating Koha from English to English

As Andrew S. Tanenbaum said, “the nice thing about standards is that there are so many of them to choose from.” Good old non-standardized library jargon provides an even richer field of variation. Do libraries serve members, patrons, clients, or customers? Is a patron placing a hold request or a reservation? When the item arrives and the patron checks it out, do we call the transaction a loan, a checkout, or an issue? Can the library issue an issue to patron? How many synonyms have I missed so far?

Koha’s base HTML templates use “English”; translations to other languages are generated by extracting strings from the templates and giving them to the translators. The files containing translated strings are then used to create a set of HTML templates in the desired language.

I put “English” in scare quotes because while nominally the language of coding is (I think) the New Zealand variant of the Queen’s English, in practice it is a mixture of NZ English, UK English, US English, and so forth. That already opens the door to potentially desirable localizations — after all, one really ought to put one’s “colour” and “flavor” in the right sociogeolinguistic buckets.

Which brings us back to library jargon — a “reservation” in one country is another’s “hold request”. An academic library’s “recall request” is a public library’s “you’ve gotta be kidding!”. A bright idea! Let’s convene an international committee to standardize English-language library jargon! I’m holding my breath with anticipation …

…

Still holding — but why not expand the scope of the committee and handle French library jargon?

…

*thunk*

later

OK, so that didn’t work. For now, it looks like a better solution is to embrace the differences and set up en-NZ, en-US, en-GB, etc. as defined translations for Koha, per some recent traffic on the koha-devel list. Localization ultimately doesn’t apply to just language and country; think of en-US-academic_library, en-US-small_public, etc.

This entry was posted on Sunday, April 13th, 2008 at 11:11 pm by Galen Charlton and is filed under Koha. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Viewing 3 Comments

    • ^
    • v
    There is a 'master' English interface from which each localized version derives from. This English is both a common terminology and a specialized (library) terminology, preferably chosen to facilitate translation.

    The common terminology could be a least common denominator English, more and less understandable by English speakers throughout the world:

    http://en.wikipedia.org/wiki/International_English

    The library terminology, as suggested, could come from an authoritative reference:

    http://lu.com/odlis/

    So master (developers) interface could be named: en-odlis.

    In the first place, terms are chosen by developers who are not necessary neither good English speaker (en-IT) nor librarians at all. So a quality control process should involve English technical redactors and librarians.
    • ^
    • v
    And in fact, something like en-US-small_public is within the capability of the RFC4646 conventions we use in Koha. Part of the reason I chose RFC4646 to represent language codes during the langtag redesign is that it supports 'extensions'. So you could have something like:

    en-NZ-l-small_public-i-opac-t-prog-v-3000000

    The first two subtags are valid in the subtag registry, but the rest of them are context-specific extensions ... in this case, specific to Koha itself. The l- prefix might refer to library type, the i- prefix is 'Interface' (opac or staff), the t- prefix refers to the template used, and the v- prefix to the version string.


    For more details on RFC4646 and it's use, I'd recommend: http://www.w3.org/International/articles/langua...
    • ^
    • v
    Galen, you summarised my point exactly.

    One of the great things about the Koha project is that we have such an easy to use translation tool available. I completely agree that there should be a standardised version that the developers are working on, so that they all at least use the same term for development. But this does not need to be the language that is presented to the end user.

    In my new job, I do quite a bit of user testing. It is really interesting to watch people get hung up on words. For some people, it puts them into a complete tail spin and makes them very frustrated with the system.

    When you implement a new library system, in place of an existing one (or any system for that matter), you have to overcome the fact that even though they didn't like the old system, they were used to it and understood it. Little things like using different terms than what they are used to, gives them the excuse to start not liking the new system.

    All over something that is such a small change.

    So seeing as we have such an easy to use system (Kartouche), I would think that if someone wants to put their hand up to maintain a translation to the language used in their region, then why not? They just need to be aware that whenever there is a change, they will need to update their translation.

    I see this as a point of difference that Koha can offer.

Trackbacks

blog comments powered by Disqus