Hello! LibLime Developers' Blog is using DISQUS, a powerful comment system, to manage its comments. Learn more.
Community Page
- blogs.liblime.com/developers Jump to website »
-
Subscribe -
Community
-
Top Commenters
-
Popular Threads
-
Recent Comments
- Sounds like fun. Have you been to a BarCamp before?
- ...and who are the guys and gals who get blamed from nearly everything from the Internet being down to the coffee maker not working to someone stealing the Any Key. :-) If it doesn't work we...
- Regarding your suggestion of having publishers provide metadata in machine-readable form, here is what I wrote in 1999: "Finally, not to forget cataloguers, whose meticulous task is essential...
- Fernando, I had not seen your project before: it is very interesting and exciting. It looks as if we have adopted some of the same techniques (not to mention, javascript framework). I will read...
- Frederic, Thank you for your comment; I think these are good suggestions. In fact I think Biblios should allow callbacks at all important events in the record life cycle: on retrieval from z3950...
LibLime Developers' Blog
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.
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 p
... Continue reading »
1 year ago
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.
1 year ago
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...
1 year ago
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.