<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>LibLime Developers' Blog - Latest Comments in Library jargon, or translating Koha from English to English</title><link>http://liblimedevelopers.disqus.com/</link><description>The LibLime Developers’ Blog is a place for LibLime’s programmers and analysts to briefly tear themselves away from specs and code and talk about free and open-source library software including Koha.</description><language>en</language><lastBuildDate>Mon, 14 Apr 2008 17:56:01 -0000</lastBuildDate><item><title>Re: Library jargon, or translating Koha from English to English</title><link>http://blogs.liblime.com/developers/2008/04/13/library-jargon-or-translating-koha-from-english-to-english/#comment-1567054</link><description>Galen, you summarised my point exactly. &lt;br&gt;&lt;br&gt;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. &lt;br&gt;&lt;br&gt;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. &lt;br&gt;&lt;br&gt;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. &lt;br&gt;&lt;br&gt;All over something that is such a small change. &lt;br&gt;&lt;br&gt;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. &lt;br&gt;&lt;br&gt;I see this as a point of difference that Koha can offer.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Russel</dc:creator><pubDate>Mon, 14 Apr 2008 17:56:01 -0000</pubDate></item><item><title>Re: Library jargon, or translating Koha from English to English</title><link>http://blogs.liblime.com/developers/2008/04/13/library-jargon-or-translating-koha-from-english-to-english/#comment-1567053</link><description>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:&lt;br&gt;&lt;br&gt;en-NZ-l-small_public-i-opac-t-prog-v-3000000&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;&lt;br&gt;For more details on RFC4646 and it's use, I'd recommend: &lt;a href="http://www.w3.org/International/articles/language-tags/" rel="nofollow"&gt;http://www.w3.org/International/articles/langua...&lt;/a&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Joshua Ferraro</dc:creator><pubDate>Mon, 14 Apr 2008 13:30:20 -0000</pubDate></item><item><title>Re: Library jargon, or translating Koha from English to English</title><link>http://blogs.liblime.com/developers/2008/04/13/library-jargon-or-translating-koha-from-english-to-english/#comment-1567052</link><description>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.&lt;br&gt;&lt;br&gt;The common terminology could be a least common denominator English, more and less understandable by English speakers throughout the world:&lt;br&gt;&lt;br&gt;&lt;a href="http://en.wikipedia.org/wiki/International_English" rel="nofollow"&gt;http://en.wikipedia.org/wiki/International_English&lt;/a&gt;&lt;br&gt;&lt;br&gt;The library terminology, as suggested, could come from an authoritative reference:&lt;br&gt;&lt;br&gt;&lt;a href="http://lu.com/odlis/" rel="nofollow"&gt;http://lu.com/odlis/&lt;/a&gt;&lt;br&gt;&lt;br&gt;So master (developers) interface could be named: en-odlis.&lt;br&gt;&lt;br&gt;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.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Frédéric</dc:creator><pubDate>Mon, 14 Apr 2008 04:25:26 -0000</pubDate></item></channel></rss>