Re: [Koha-devel] FW: Where is the BIG RED WARNING button?
I really understand Jonathan's point here. He's probably become the one contributor with the best overall vision of the project now. I really like the idea of using the dashboard more and making it better. I also think Jonathan might need something more proactive, the dashboard requires the contributors to look at it and decide for themselves, but everyone is really busy, and we all get to make our own choices regarding priorities. Two ideas i would suggest (sorry if it's redundant or has been said before): - why not have a "mission critical" meeting from time to time for this kind of issues? With the goal of defining precisely who will do what on a given issue? - would a small team of designated people help? A sort of Koha Kommando Jonathan can rely on when stumbling on something like this? It would need to be used carefully obviously, but i think just calling for help on the mailing list, irc or the dashboard dilutes the feeling of emergency, because no one is explicitly in charge. Maybe we (BibLibre), and other import support companies like Bywater and others can commit to having one person that is part of the emergency team? (note that I'm writing all this without having mentioned it to anyone at BibLibre...) https://youtu.be/_MVonyVSQoM Would that help? Le 11/08/2017 à 15:40, Marc Véron a écrit : Sorry for the empty message... What I wanted to say: +1 for improving the dashboard (I always check the dashboard first, then the Bug tracker, then the list of bugs to sign off, then my open bugs...) Maybe the Dashboard could contain the links to the newest bugs / changed bugs from the Bug trackers start page: Bugs reported in the last 24 hours | last 7 days Bugs changed in the last 24 hours | last 7 days Marc Am 11.08.2017 um 15:34 schrieb Marc Véron: Am 11.08.2017 um 11:55 schrieb Marcel de Rooy: +1 for improving the dashboard Instead of listing the oldest bugs, which may not be that interesting, we should list the critical ones on top. The need to click on that line should be removed. See them rightaway. Maybe we can put these oldies somewhere down on the page in order to not forget them? ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/ ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/ ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Gaetan Boisson Chef de projet bibliothécaire BibLibre +33(0)6 52 42 51 29 108 rue Breteuil 13006 Marseille gaetan.bois...@biblibre.com ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] Interlibrary loans module
I've added you to the topics in the google doc, you can pick a time when you want to talk about this. can only make it in the afternoons, tuesday to friday. Would tuesday afternoon work for you? Le 15/03/2017 à 10:11, Alex Sassmannshausen a écrit : Hi Gaetan, Yes, for sure — I would be more than happy to present this at the hackfest! Alex Gaetan Boisson writes: Hi Alex, Would you consider presenting this work at the hackfest? I'd be very interested! Cheers, Le 22/02/2017 à 07:52, Alex Sassmannshausen a écrit : Hugo Agud writes: Hi Alex Wow! it sounds great.. I will try to do my best with this bug ;) Fabulous! Let me know if you need a pointer. Alex Kindest Regards Hugo 2017-02-21 11:57 GMT+01:00 Alex Sassmannshausen <alex.sassmannshau...@gmail.com>: Hello Kohites! Andrew and I have just finished a second major revision of our proposed interlibrary loans module for Koha. The code and bug can be found at [https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7317]. We believe the code has now reached the maturity it requires for wider engagement, and, more importantly, it's now reached the maturity that it should be easy to get it up and running relatively easily in your development environments. Unfortunately we cannot deploy the module using sandboxes because backends are implemented as separate code projects. And we would *love* your comments thoughts and concerns about the module if you are interested in ILL! The final comment on the bug contains basic documentation for the Module as a whole, and also some installation instructions. But for reference, I've attached the same document to this email too. Below you will find some further high-level background and a roadmap of what we would like to achieve. For now, if you're interested in this module: • have a look at the bug, and get involved in the discussion! • try to set up the module in your dev environment. It should work easily on dev boxes and dev installs that track master. • let us know if you face any issues! • start a conversation with us if you might be interested in creating a backend for your country's / organization's ILL workflows. Finally, if you don't have access to a development environment, but you would be interested in becoming involved in this project, get in touch and we might be able to provide you with access to a testing environment! Best regards, Alex Sassmannshausen PTFS Europe 1 High-level background ═══ The ILLModule aims to provide a core framework against which different ILL workflows can be implemented within Koha. It achieves this by using 2 new tables as data store, and by using an extensible backend system to create 'connectors' to ILL providers. The data store consists of the illrequests and the illrequestattributes tables. The former is a traditional table that stores essential values associated with an ILL request. The later is a key/value store, linked to a row in the former. This store can be used to store arbitrary data provided by a backend. The backends implement highly customizable workflows for several core steps in the ILL management process. At the same time, each backend can extend the core steps (called defined as the `core_status_graph` in Koha/Illrequest.pm) with their own additional steps (defined as the `status_graph` in a backend's Base.pm). Each of these steps, both core and extensions, in turn can define any number of 'stages' required to complete each individual step. Each step has access to a template include file, which can dispatch on 'stage'. This is mirrored by each step having a sub in a backend's Base.pm, which once again can dispatch on 'stage'. The subs in Base.pm have access to the full data store provided by the ILLModule; similarly the template includes have full access to Koha template features, including access to custom JS blocks through which, for instance, external APIs can be called. The main aim of this Koha module was to provide a core that is comprehensive enough to store core data to only have to implement ILL once in Koha, whilst being extensible enough so that virtually any ILL workflow can be implemented against this core. We believe we have achieved this. I'd be very interested to hear from you if you believe you have a workflow that cannot be captured by this (obviously, third party tools that do not provide API access will be virtually impossible to seamlessly integrate into Koha). 2 Roadmap ═ The roadmap starts from the current release of code on the bugzilla issue. • Publication of mature beta level code (21 February 2017) ⁃ public testing ⁃ public discussion ⁃ dogfooding • Augment core functionality (~ June 2017) ⁃ add advanced configuration o
Re: [Koha-devel] Interlibrary loans module
ur own backend' tutorial?) • Provide consistent error handling ⁃ standard means through which a backend can 'throw' an error. ⁃ replace uses of die with this standard route • Integration into Koha core in Koha 17.11 ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Gaetan Boisson Chef de projet bibliothécaire BibLibre +33(0)6 52 42 51 29 108 rue Breteuil 13006 Marseille gaetan.bois...@biblibre.com ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] proper sorting order and search for Swedish characters and ISBN search
Digging this back up as we finally found a solution. And by "we" i mean Fridolin Somers, whose knowledge of ICU, zebra and indexing never ceases to amaze me! Setting the ICU locale to sv-SE was not enough it seems, because this still transliterated å, ä, ö, Å, Ä and Ö to a, o, A and O. We just had to add a rule to exclude them from the transliteration: Meh, sounds easy enough now! Hopefully this will come in handy to someone. Le 12/01/2017 à 02:51, David Cook a écrit : Considering the folk at IndexData are Danish, perhaps they could provide some insight more directly. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -Original Message- From: koha-devel-boun...@lists.koha-community.org [mailto:koha-devel- boun...@lists.koha-community.org] On Behalf Of Colin Campbell Sent: Friday, 25 November 2016 3:32 AM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] proper sorting order and search for Swedish characters and ISBN search On Fri, Nov 04, 2016 at 05:20:03PM +0100, Gaetan Boisson wrote: Hello, I have been trying several things to try to sort this out, and haven't found a way (yet) that would avoid ugly compromises. The issue is: in Swedish ä, ö and å are separate letters. Not variants of a and o. This means that searching for å shouldn't bring up a. When sorting, they belong to the very end of the alphabet, after z, not along a and o. In ICU, setting the locale parameter to "sv" (swedish) should do this. I cant seem to get this to work in yaz-icu but there are tests in the yaz code base for passing locale to strings. However I'm not sure how to correctly specify this for yaz the documentation is way too sketchy. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 800 756 6803 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Gaetan Boisson Chef de projet bibliothécaire BibLibre +33(0)6 52 42 51 29 108 rue Breteuil 13006 Marseille gaetan.bois...@biblibre.com ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] about using XSLT for display of holdings (952)
I would be in favor of the detail display bein made with XSLT for items. That would of course be much more flexible, and would allow us to have custom fields easily (i.e. to display whatever ends up in more_subfields_xml as we please). I think there are historical reasons (the template based display needs to work and took care of this with the table), and the fact that items are not stored in the marcxml anylonger might be a reason too, althought maybe something puts them back in the marcxml when doing the xslt processing. (And you get them in the marcxml when saving the record, even though the item level fields are not in biblioitems.marcxml.) Le 08/02/2016 02:10, David Cook a écrit : Hmm, it's a good question I think. I imagine part of it might be a speed thing, or coincidence? I know Fridolyn was planning on trimming the number of items added as 952s to the Zebra records, so in that case the database would have the true reflection of holdings while the MARCXML would only have a snapshot. Overall, not sure. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -Original Message- From: koha-devel-boun...@lists.koha-community.org [mailto:koha-devel- boun...@lists.koha-community.org] On Behalf Of Indranil Das Gupta Sent: Sunday, 7 February 2016 8:43 AM To: koha-devel@lists.koha-community.org Subject: [Koha-devel] about using XSLT for display of holdings (952) Hi, At the risk of asking something very stupid, I was wondering why we utilize XSLT only for the biblio record and not for the holdings data in say opac- details.pl thanks in advance -- Indranil Das Gupta Phone : +91-98300-20971 Blog: http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha- community.org/ bugs : http://bugs.koha-community.org/ ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Gaetan Boisson Chef de projet bibliothécaire BibLibre 06 52 42 51 29 108 avenue Breteuil 13006 Marseille gaetan.bois...@biblibre.com ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-devel] koha and mod perl
Hello all, we have kept working on mod perl, and have reached a state that seems fairly stable to us for now. I know the community is working towards plack support, so this could be regarded as a temporary trick, but since most of us use Apache anyway to serve Koha, i think it's a trick worth having a look at. While we haven't managed to get plack in a state stable enough that we felt we could set it up in production for one of our libraries, we feel like we are close enough with mod perl and will likely try this very soon. So if you are feeling brave and want to give it a ride, you can head to http://intranet-demo.biblibre.com/ (login/pwd test/test, this is reset every night) and http://demo.biblibre.com/ to see how much faster it feels. We'll keep you posted once we've tried it in a real production environment ! -- Gaetan Boisson Chef de projet bibliothécaire BibLibre 06 52 42 51 29 108 avenue Breteuil 13006 Marseille gaetan.bois...@biblibre.com ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-devel] Koha and mod perl
Hello all, has anyone set up mod perl on a koha instance? And if so, are there any bugs or issues doing this? It seems we tried it some time ago, and this page says there are issues, but doesn't give more details: http://wiki.koha-community.org/wiki/Koha_Tuning We have been testing it today and i haven't seen serious issues so far. From the wiki it seems the latest tests were made 4 years ago, so it's possible things have changed in Koha and mod_perl. It's something worth trying at any rate, because the mod perl documentation claims 400% to 2000% performance boosts. It definitely feels *much* faster on our test instance right now. -- Gaetan Boisson Chef de projet bibliothécaire BibLibre 06 52 42 51 29 108 avenue Breteuil 13006 Marseille gaetan.bois...@biblibre.com ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] plack in production
So, we applied Dobrica's patch on bug 13815, and this solved pretty much all of our problems. We'll be doing some more testing, but it turns out it was very much encoding related. (I guess Robin's catalog is in english language and didn't have this issue.) I realize there's one thing i didn't mention in my message: we are testing plack for the staff interface, i am much more confident for the opac indeed. (So much so that we didn't even test the opac! I guess we should...) Another thing i didn't mention in my original email is that we found bad .po files can cause plack to crash: if your translated string doesn't have the same number of %s as the original, this will result in a badly formated template, which will crash plack. (e.g. an if tag that is never closed.) Somehow this doesn't induce a crash when plack is not enabled. I had always thought that if the %s count for a string was wrong, the translation engine would leave the original string. It seems it's more complicated than this. Anyway, we'll be doing more tests and i'll keep you posted about our findings! Le 20/04/2015 00:12, Robin Sheat a écrit : Gaetan Boisson schreef op do 26-03-2015 om 16:17 [+0100]: we have been talking about plack quite a lot in the last hackfest, and i must say i am not that comfortable with the technical aspects and hardly understand what the issues are, but... I apparently missed this message when it was first posted. Anyway, we have a plack system in production. I'd link you to it, but it's closed and so it'll do you no good. It is really speedy though. In this case it's needed because this library sends out monthly newsletters to its members who then all descend on the OPAC en masse, which in the pre-plack days would make it OOM or at least just give up responding. However with plack, it serves the responses fast enough that it can handle the high load with a lot more success. The script I use to convert a package install to use plack is here: http://git.catalyst.net.nz/gw?p=koha-plack.git One of these days I'll probably make a branch of Koha that includes plack support by default in the packages, or make a package that provides the appropriate diverts to switch everything on that machine to plack, I haven't decided which way to go yet. We do have a few minor issues, but nothing as severe as what you're talking about. The main problem is that user separation makes memory allocation tricky as you need to pre-allocate per koha instance, which is a bit much. At the same time, we don't want to risk giving the process read access to every koha-conf.xml as that's dangerous. We do have a solution for this (it's weird, but it'll do), I just haven't had a chance to tie it in. ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Gaetan Boisson Chef de projet bibliothécaire BibLibre 06 52 42 51 29 108 avenue Breteuil 13006 Marseille gaetan.bois...@biblibre.com ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] plack in production
Hello, we have tested plack a little further. We have achieved much more stability but are still encountering very serious bugs, before filing a report for each of them, i would like to ask here whether it does sound like something that is happening because of plack, and whether this has been identified before : - A vast majority of records are giving a The record you requested does not exist message when trying to display the detailed record, even though the record does seem to exist in the database, and i was even able to check out items linked to said record. - trying to place a reservation and a document from a result list results in an error, maybe unsurprisingly given the above : Can't call method field on an undefined value at /home/koha/src/C4/Items.pm line 1625. at /usr/share/perl/5.18/CGI/Carp.pm line 378 - i noticed a delay between changing circulation rules and seeing them applied when checking out items (the rule was saying i could borrow 13 items, i brought it down to 2, but was then able to checkout 3 items without getting a notice. Shortly after i was getting proper notices telling me i was exceeding the quota) - There were numerous encoding problems with non ascii characters, this might be linked to Bug 13815 - plack loose CGI qw(-utf8) flag creating incorrect utf-8 encoding everywhere; but this was not just patrons. Cataloging frameworks, authorised values, fund names were all affected. - exporting data from cgi-bin/koha/tools/export.pl also lead to a crash, which seems to be linked to UTF-8 issue too: :11: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0x80 0x3C 0x2F 0x73 subfield code=p5.40�/subfield ^ at /home/koha/src/tools/export.pl line 683 Let me know what seems geniunely new and plack related to you and i will file the bugs. Thanks! Le 26/03/2015 16:17, Gaetan Boisson a écrit : Hello all, we have been talking about plack quite a lot in the last hackfest, and i must say i am not that comfortable with the technical aspects and hardly understand what the issues are, but... I tried it with the help of our sysops a couple days ago, and i must say koha does feel *really* fast with plack enabled. If you havent yet, you should try. It really made me realize why this should be a priority for us to get it to work. Now, it turns out it really doesn't work for us. It keeps crashing every few minutes. We haven't had time to investigate any further, but before pouring more time in this i wanted to know whether anyone was using it seriously (including for the staff interface), and what your conclusions are. Importantly, i would also like to know more about the recommended configuration, and the areas we should have a close look at in our set up. Thanks for your advice! -- Gaetan Boisson Chef de projet bibliothécaire BibLibre 06 52 42 51 29 108 avenue Breteuil 13006 Marseille gaetan.bois...@biblibre.com ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-devel] plack in production
Hello all, we have been talking about plack quite a lot in the last hackfest, and i must say i am not that comfortable with the technical aspects and hardly understand what the issues are, but... I tried it with the help of our sysops a couple days ago, and i must say koha does feel *really* fast with plack enabled. If you havent yet, you should try. It really made me realize why this should be a priority for us to get it to work. Now, it turns out it really doesn't work for us. It keeps crashing every few minutes. We haven't had time to investigate any further, but before pouring more time in this i wanted to know whether anyone was using it seriously (including for the staff interface), and what your conclusions are. Importantly, i would also like to know more about the recommended configuration, and the areas we should have a close look at in our set up. Thanks for your advice! -- Gaetan Boisson Chef de projet bibliothécaire BibLibre 06 52 42 51 29 108 avenue Breteuil 13006 Marseille gaetan.bois...@biblibre.com ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-devel] biblio records causing previous transaction didn't reach commit in zebra
Hello all, we are migrating some csv data to marc21 and a small percentage of the resulting records are giving this error in zebra when we try indexing them. I have been looking at them toroughly and am failing to see what could possibly cause this, especially when i compare them to records that did work. I'm enclosing a couple here in case you want to have a look and might have an idea... It is for a Kurdish university so you'll find a lot of unusual characters in there, but we have these in records that work out too. The U+200 characters are here to set the context properly for the script direction. They are superfluous quite often, but they also don't hurt and are present in data that gets indexed properly. Thanks for your input ! -- Gaetan Boisson Chef de projet bibliothécaire BibLibre 06 52 42 51 29 108 avenue Breteuil 13006 Marseille gaetan.bois...@biblibre.com 001 Description: Binary data 002 Description: Binary data 003 Description: Binary data ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] any right to left specialists around ?
Thanks !
Karam i was secretly hoping you would jump in ;)
One more question ? Do you have records in your catalog that mix
both directionnalities ? Could you give me some examples ?
Thanks a lot !
Le 28/03/2013 21:40, Karam Qubsi a
crit:
It's great job !
Thanks for your efforts guys .
On Thu, Mar 28, 2013 at 1:29 PM, Jared Camins-Esakov jcam...@cpbibliography.com
wrote:
Karam,
5- in some cases we may editmanually the
.tt files like in browsing for patrons we
have a b c ... but the Arabs patrons my have
names in Arabiccharactersso we have to
add :... and not remove tha a b c ..
some libraries in Arab worlds use the abc
...
Koha 3.12 includes a feature that allows you to
set which letters are included in the patron name
browse without editing the templates. Take a look
at the "alphabet" syspref:http://manual.koha-community.org/3.12/en/administration.html#l18nprefs
Regards,
Jared
--
Jared Camins-Esakov
Bibliographer, C P Bibliography
Services, LLC
(phone) +1 (917)
727-3445
(e-mail) jcam...@cpbibliography.com
(web) http://www.cpbibliography.com/
--
Karam Qubsi
Email: karamqu...@gmail.com
Skype : karam.qubsi
: +963 991
264 020
Viber
:+963 991 264 020
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
--
Gaetan Boisson
Chef de projet bibliothcaire
BibLibre
06 52 42 51 29
108 avenue Breteuil 13006 Marseille
gaetan.bois...@biblibre.com
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-devel] any right to left specialists around ?
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.bois...@biblibre.com ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] Default search options in the OPAC
I like this idea :) It would also allow people to search on new indexes they might have defined in said obsure files. Some libraries have asked us for this in the past. Le lundi 08 octobre 2012 à 09:52 +0200, Magnus Enger a écrit : On 18 September 2012 15:58, Owen Leonard oleon...@myacpl.org wrote: We've now got two patches pending which seek to add more options to the default OPAC search, the masthead search bar which currently includes options for Library catalog, title, author, subject, ISBN, series, and call number: Add Phrase Searching to OPAC Search http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8778 Add accesssion [barcode] number to the drop down list in OPAC Search http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8302 I'll say right out that I'm opposed to these changes, but I want to bring it up here on the list so we can discuss. I agree that the simple search should be simple. But we could probably spend a lot of time arguing about how simple is simple enough. Seems to me that it would be better to find a way to make this easily configurable. I'd like to suggest a simple solution: In the template, we could have select id=masthead_search class=left name=idx [% OPACSearchOptions %] /select Then we could have a syspref called OPACSearchOptions (or something), with this initial content: option value=Library catalog/option option value=tiTitle/option option value=auAuthor/option option value=suSubject/option option value=nbISBN/option option value=seSeries/option option value=callnumCall number/option This would keep current behaviour, but make it easy to add or remove or re-arrange the option elements. And we could explain in the docs or on the wiki how the values here relate to indexes defined in more or less obscure config files. Yes, it would require fiddling with HTML and Zebra (or Solr) indexes to change it. No, it would not be GUI and pretty. But it would be so simple, even I could submit a patch for it. Thoughts? Best regards, Magnus libriotech.no ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Gaetan Boisson Chef de projet bibliothécaire BibLibre 06 52 42 51 29 108 avenue Breteuil 13006 Marseille gaetan.bois...@biblibre.com ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Re: [Koha-devel] Problems with suggestions
I completely agree that this is confusing, and it took my a while to figure out that when you reach this screen the filter is not empty. (The site is picked in acquisition information), actually if you play a little with the filter, then click clear, you go back to a setting where you only see suggestions made for the site you are connected to. Like Robin suggested, i think adding a sentence like By default you will only see suggestions made at the site you are connected to. Use the filter to change this behaviour. would solve the problem without resorting to fancy developments, unicorns and poneys. Just my 2 cents ;) Le lundi 24 septembre 2012 à 18:24 +1200, Robin Sheat a écrit : We have had a few queries about suggestions not working correctly in 3.8, that seem to be the result of this: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7300#c6 can we decide the path to solving this? Making suggestions hidden by default is distinctly a regression for many libraries. On the other hand, filtering by branch is a genuinely useful thing, as is the ability to filter by default. My suggestion (to avoid a syspref) is that it has big, obvious words saying it's filtered and a button to show all, and it remembers the last state that user had (filtered or not) to show them next time. But I don't have any funding in line for this, so it'd really be up to whoever had the time to implement it. (It also maybe exposed a weakness in the patch signoff workflow, as it didn't really get any external review before going in, but that's another conversation perhaps.) ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Gaetan Boisson Chef de projet bibliothécaire BibLibre 06 52 42 51 29 108 avenue Breteuil 13006 Marseille gaetan.bois...@biblibre.com ___ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
