- Koha-devel - lists.koha-community.org

IRC meeting reminder: 3 April 2013 at 10:00 UTC
by Galen Charlton 02 Apr '13

02 Apr '13

Hi, The next general IRC meeting is happening tomorrow, 3 April 2013, at 10:00 UTC: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+IRC+General+M… Here is the agenda: http://wiki.koha-community.org/wiki/General_IRC_meeting,_3_April_2013 Of particular note: the elections for roles for 3.14 will take place at this meeting. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

1 0

Some bugs to sign off
by Chris Cormack 02 Apr '13

02 Apr '13

Hi All We are down to 29 bugs (not features or enhancements) in the needs sign off queue. I am continuing to try and get that as close to 0 as possible before the 3.12 release, but there are some I simply can't sign off on because they were authored by people at Catalyst. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6506 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4862 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8200 They all are pretty easy to test. Chris

1 0

Re: [Koha-devel] Koha SIP Server error message
by Scott Kushner 01 Apr '13

01 Apr '13

Mark Actually, I should have added more information. It does, in fact, halt the SIP server and disconnect from the mysql server, so I suspect that it's a bug. thanks for replying. Scott ________________________________ From: Mark Tompsett [mtompset(a)hotmail.com] Sent: Friday, March 29, 2013 11:20 PM To: Scott Kushner Subject: Re: [Koha-devel] Koha SIP Server error message Greetings, I don’t use SIP, but many of the uninitialized variable type errors in other parts of Koha did not affect processing. I suspect this is the same kind of thing. I was told this is not an error but a warning. After all, and error would prevent what you are attempting from actually working. A warning merely indicates less than perfect code which functions. I’m assuming you read the warning message in the error log files and didn’t actually have your SIP check-in failing. As for it’s annoying nature, you are always welcome to submit a patch to fix it. GPML, Mark Tompsett

2 3

Feedback from french translation team about transifex
by Paul Poulain 31 Mar '13

31 Mar '13

Hello translators, During the hackfest in Marseille, 2 people worked on transifex with french translations. Their opinion is that we *must* leave pootle in favour of transifex. Both tools shouldn't be compared in terms of usability, features, speed of use,... What's the next step ? How could we reach an agreement on using this tool instead of pootle ? It seems a transifex server can be setup from github or we could decide to use transifex.com directly, (which is free of charge for OpenSource projects) My opinion here is that we could stard with transifex.com, as we can always download all translations, we can easily deal with any evil change, but I'm open to others arguments (and I don't apply to manage all the translation things, so our translation manager has an important opinion ;-) ) -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper

6 5

OpacNav and OpacNavRight width should be the same?
by Quoc Uy 31 Mar '13

31 Mar '13

I'm trying to add some customization into OpacNav and OpacNavRight. I saw that OpacNav and OpacNavRight don't have the same width. So i think, should we change css in Koha's source? In my view, if they have the same width, the site looks more symmetrical. Best regards! Nguyen Quoc Uy Admin http://dreamlib.vn & http://vietnamlib.net Phone: +79525768182

2 1

March 2013 Koha Community Newsletter has been published
by Daniel Grobani 30 Mar '13

30 Mar '13

Hi, The March 2013 edition of the Koha Community Newsletter has been posted to http://koha-community.org/koha-community-newsletter-march-2013/. Cheers, Daniel Grobani Koha Community Newsletter Editor

1 0

Koha SIP Server error message
by Scott Kushner 29 Mar '13

29 Mar '13

Hi, Would anyone know why I keep getting this error message when trying to do a checkin through SIP? "Use of uninitialized value $var in hash element at /root/kohaclone/C4/Context.pm line 1026, <STDIN> chunk 2." Is it a bug? It's very annoying. Thanks Scott Kushner Middletown Library

1 0

Re: [Koha-devel] Feedback from french translation team about transifex
by BWS Johnson 29 Mar '13

29 Mar '13

Salvete! Bearing in mind that I personally would like to see Pootle as implemented die a terrible, rotten, no good death, I think finding a replacement requires a lot of scrutiny. While it's promising that Transifex looks good so far, I'd love to know how the experience has played out for non Latin languages. Do we know how Arabic, Chinese, Marathi, Russian, and any others might have played out? Also, I realise that Community hosting is a resource hassle, but I'm a wee bit paranoid about having these tools completely out of our hands. Cheers, Brooke

1 0

any right to left specialists around ?
by Gaetan Boisson 29 Mar '13

29 Mar '13

Dear all, a pretty long call for help, but please read on if you know anything about handling right to left scripts, or if you're just interested in it. I am working on a project in Iraqi Kurdistan on behalf of BibLibre and have been reading quite a lot on the various problems typically encountered with text that flows from right to left, and especially when mingling text that flow in opposite directions in the same display. To sum it up briefly, and as far as i understood, displaying the data should be fine whenever there is only one run of text in an element. Things get tricky when your run of text ends with a neutral character (a character that doesn't have an inherent direction in which it should be read, such as a punctuation mark) or when you have different directional runs one after another (Imagine the arabic title of a book called "Learn HTML4 in 24 lessons", where "HTML4" and "24" would be written in the latin alphabet for instance. Also, reading about all this, i learnt that arabic is written from right to left, except for numbers which are written from left to right). In those cases, the "bidi algorythm" (the thing in charge of displaying bi-directionnal text properly) will find itself in an unclear situation and can make the wrong choices. This results in things like (What you will see below here seems to depend on what you use. I can tell you it's not displaying well in thunderbird 17.0.4 on Ubuntu) : تعلم HTML4 فى 24 درسا The words are the right ones, but their order is messed up. To an arabic reading person what we have here doesn't make sense, it's like "in 24 lessons HTML4 Learn". What happens here is that we have 3 directional runs (not 5 : فى 24 درسا is just one run from left to right, with the numbers being read from left to right as they should, but it's still the same run. Yes my mind is crying too ;) ) تعلم HTML4 فى 24 درسا This is the order in which they display in my thunderbird, and they should display in the reverse order. (I have saved a record with this title in Koha and the display *is* messed up in a ltr interface, it's fine if the interface is in arabic.) It seems thunderbird is messing things up because it is ordering them according to its context, which is left to right. But if you copy and paste the full line in a more simple text editor such as Gedit, you will get the right order, unless you start typing things in the latin alphabet at the start of the line (which will be on the right side). Then you will have a messed up order, aligned on the left. Now, when we will migrate the data for this project i would like to take all measures to make sure things will be understandable in all possible contexts. That is whether the interface is displaying in a left to right or right to left language should not matter. There are unicode invisible characters that can be used to say "this whole stretch is left to right" (or the opposite), or even some characters which cannot be seen but which are "strongly typed" rtl or ltr and can be inserted at the right place to clarify the context and fix things. What i am tempted to do is to enclose all strings in those characters during the migration, according to the language used (an information i can find elsewhere in my data). Or just add the "clarifying" character at the end (or beginning ?) of the string. I guess it would be a good idea then to do this in all cases, that is not just for rtl languages in the data, but for both. (Even though chances are english books will have much less mixed scripts in their metadata than their arabic counterparts. This just seem like a justified equal treatment.) Is that the right way to proceed ? One last thing is that when cataloguing new documents, i guess the librarians should pay attention to this. Should we then train them to use these characters at the appropriate places ? If you have experience with this and can provide some advice as to the solutions usually put in place, i'd be extremely grateful if you could share it. I intend to get a good look at that and put some effort into fixing a few things on the way. ;) Thanks, If you read all this just out of interest, go to the W3C pages on bidi text, they are extremely informative and well written : http://www.w3.org/International/tutorials/bidi-xhtml/ -- Gaetan Boisson Chef de projet bibliothécaire BibLibre 06 52 42 51 29 108 avenue Breteuil 13006 Marseille gaetan.boisson(a)biblibre.com

5 7

3.14 Naming module maintainers
by Fridolyn SOMERS 29 Mar '13

29 Mar '13

Hie, I whould like to candidate as "Patrons" module maintainer. I know this module quite well and I think I can handle its bug volume. Regards, -- Fridolyn SOMERS Biblibre - Pôle Support fridolyn.somers(a)biblibre.com <mailto:fridolyn.somers@biblibre.com>

1 0