Hello everyone,
and best wishes for the New Year,
The Koha community is proud to announce the release
of Koha 22.11.13:
https://koha-community.org/koha-22-11-13-released/
Debian packages are coming...
Best,
Frédéric Demians
___
Koha-devel mailing list
I concur with Julian observations. A configuration selection per
library-item_type-category will be too much or not enough depending on the
context. We will end up with another table containing zillions of records for
trivial things. Tomas, have you considered a hierarchical configuration data
fied of course. I'd be curious to know how Julian creates his release
notes, automatically or by hand, or a mix.
Kind regards,
--
Frédéric DEMIANS
http://www.tamil.fr/fdemians
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.k
> I just discovered a few issues in get_bugs.pl:
I have an alternative script doing the same tasks. I don't know if I can / how
I can push it on the release tools repo.
It fixes few issues. Including the generation of the release team paragraph,
which should be the same depending on current
The various Koha translations could also be placed under the umbrella
of this "Data Sharing" project. Rather than embedding translation
files (.po files) into Koha base code, they could be available online
and retrieved from Koha "Data Sharing" server (KDSS), and then
installed on the fly when
> The idea was to manage po files using git subtree:
> http://lists.koha-community.org/pipermail/koha-devel/2015-March/041293.html
See that also:
https://wiki.koha-community.org/wiki/Git_Splitting_and_Shrinking
Do we really need a Git repo for translation files since the authoring
of translated
What I have in mind is a mechanism which would allow Koha users to go in
Administration, and request a specific language for their installed Koha
version. For example, I run Koha 3.22.1. I go in Admin > WUI Language. I
select a language. I see a list of .po versions for this combinaison (Koha
About sharing data, it may be an Koha-independent project, but a
linked-one also, there is the issue of the books cover images. There
are now coming from various providers (Google, Amazon, etc.). It would
be great to have an images storage server which could replace the one
integrated in Koha
Hi,
Same as others, Julian & Liz, and as said in the subject.
Season Greetings to all of you.
Frédéric
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website :
> Anyway, I’m just wondering what we should do about this. Frédéric is in the
> process of contacting the module maintainer, but I’m predicting that the
> maintainer won’t respond.
No response yet, since december 4th.
One more option: We can also fork the module into Koha namespace:
> Another scary one is opac/oai.pl, although that's actually created packages
> in the pl script which I think is actually worse in a way.
Even if I am on Philippe Blouin side on this discusion (overengineering has
its drawbacks), concerning Koha OAI server, it has been done in one unique .pl
Thanks Paul for raising this.
I'd like to have more informations. For example:
* arguments in favor of Moo ?
Taking a look at Moo, its main advantages are speed and compatibility with
Moose.
https://metacpan.org/pod/Moo#MOO-AND-MOOSE
is the argument the overhead is cancelled by Plack
an equivalent to rebuild_zebra.pl -z with:
koha-index --select queue --verbose
Kind regards,
--
Frédéric DEMIANS
http://www.tamil.fr/fdemians
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin
I had to edit by hand, because
etc/zebdradb/xml/koha-indexdefs-to-zebra.xsl does only support
substring in handle-one-index-control-field template. It is good
for MARC21, but not for UNIMARC : in MARC21, indexing substrings is
needed for controled field (001-009, with no subfields) But in
So I first try to write directly a right xsl file, and if it works,
it means my intuition about koha-indexdefs-to-zebra.xsl is good and
that it needs to be updated (and I don't know how to do that)
You have 3 files:
1. xsl/koha-indexdefs-to-zebra.xsl
2.
=995 \\$fECP024543D$kH4 28072$rCours
=995 \\$fECP024543D$kH4 28072$rCours
homebranch and holdingbranch fields are missing in your items.
You barcodes are duplicated. An item can't be created if its barcode is
already used in an existing item.
BTW, this kind of question isn't related to the
Try to switch OpacSuppression system preference. You must not to
hide items marked as suppressed from OPAC.
I've tried and keep the same problem. The professional search works
very well but not the opac. Maybe there's something wrong on the
record.abs?
In your Zebra log file, do you still
although, i should also mention that while OpenLibrary may not be
actively adding new cover images ...there are still 13 million?
*existing* cover-images at OL, that will hopefully remain available
for us to use - until we sort a work-around :)
A work-around like siphoning OL cover images,
Patch proposed:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9580
___
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/
I've played with this idea of a cover images centralized cache of URLs.
I have a mock-up. Anybody interested in testing, commenting?
Client side (Koha), two syspref enable the service. URL are fetched from
the cache, via JSONP, just Google Books:
I think caching is something that Amazon (and probably others) rules
out explicitly. The point of that service is to gain hits, sales and
user info, not providing a nice source to harvest for your own
server.
It's not about caching thumbnails themselves, but URLs to them. There is
no interest
It seems that Amazon provides some services to find ASIN from any
ISBN but it's not clear for me how to use it. Has anyone already try
them ?
http://docs.aws.amazon.com/AWSECommerceService/latest/DG/EX_LookupbyISBN.html
Currently, Amazon books cover are retrieved simplistically, with a HTML
This discussion assumes that AWS is still usable by libraries. My
understanding of the latest terms of AWS is that your application
must have as its primary purpose the sale of material from Amazon.
That's one of the reasons other Amazon API features were removed from
Koha.
I agree. This is
The enhancement I want to see is allowing a mix of sources. It's on
bugzilla but I can't remember the number.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7187
My thoughts on designing such a system:
- On a Koha community server (or cluster of servers, or Koha library
server), a
In my opinion we can use this problem to create a new git tree wtih
only .po files.
Already discussed here:
http://wiki.koha-community.org/wiki/Git_Splitting_and_Shrinking
Now, it may be time for action.
Kind regards,
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html
at the process here:
http://wiki.koha-community.org/wiki/Category:RFCs
Kind regards,
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo
As of right now, 3.6.x is in string freeze for 3.6.10, which will be
released on October 23.
Translation files for 3.6.x have been updated on
http://translate.koha-community.org.
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html
___
Koha
For translators: Koha coming 3.8.6 version new and edited strings have
been updated on:
http://translate.koha-community.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
worth a thousand words. You bet.
But is it still true in a multi-lingual environment? Couldn't it be
decided to avoid images in manual, for the future, and in accordance
with the Documentation manager?
Kind regards,
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html
Frederic when time permits can you update the 3.8.x po files in pootle
please.
Pootle has just been updated with new/updated strings.
Kind regards,
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html
___
Koha-devel mailing list
Koha-devel
.
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html
___
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
Dear Translators,
You still have 7 hours before I pull your translation work for coming
Koha 3.6.7 and 3.8.3 version from http://translate.koha-community.org.
If you work off-line, I urge you to upload your .po files to the
translation platform before this limit.
Kind regards,
--
Frédéric
Dear Translators,
Koha 3.6 and 3.8 translation projects have been updated on:
http://translate.koha-community.org
with new/modified strings. You have this week to update your translation.
___
Koha-devel mailing list
3.8.x is also in string freeze for 3.8.3.
3.8 and 3.6 translation projects on http://translate.koha-community.org
will be updated with new/modified strings tomorrow morning. The
translators working off-line have still 8 hours to upload their .po
files on the translation platform.
--
Frédéric
On June 15 we will go into string freeze for 3.6.6, which will be
released on June 23. There have not been many changes, so the
translation should be pretty painless.
Koha 3.6.6 translation files have been updated on:
http://translate.koha-community.org
Kind regards,
--
Frédéric DEMIANS
http
We are almost one week out from the release of 3.8.2, which means that
on the 15th we go into string freeze before the release.
There shouldn't be a huge amount of changes from 3.8.1, but we will
soon find out once the translation manager has updated the .po files.
Koha 3.8.2 .po files have
Probably we can still wait a while and then ask the other ones if they
still want to remain listed as assignees or be moved to CC?
For me, CC is enough.
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
For translators:
I will pull your translation files from translate.koha-community.org,
Saturday 21 at 14:00 UTC. I you translate off-line, don't forget to
upload your files before that time.
Kind regards,
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html
-time info, then the XML is sent to XSLT.
We would gain a lot by caching an XML version ready to be completed with
items info. This way, we wouldn't have to deserialize/serialize
MARC::Record objects.
Kind regards,
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html
Hello,
Is there already a program for Edinburgh June 9-11 hackfest? Who will
attend? What will be discussed or done? Is some preparation/coordination
required?
Kind regards,
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html
___
Koha-devel
be adjusted.
About the application cache, we may take a look at CHI module which seem
to be standard, and allow to switch easily cache repository and cache
serializer.
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html
___
Koha-devel mailing list
a two level caching, in thread memory, and
in-memcached, but then the invalidation issue come back...
My limited thoughts...
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http
.
Then with:
git gc --aggressive --prune=now
You drop repo size to 138M.
I suggest to do some maintenance on community repository.
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http
features in applications.
* Frédéric (Demians, from Tamil) wrote a daemon for zebra indexing
(see http://git.tamil.fr/?p=Koha-Contrib-Tamil;a=summary), that
resulted in bug
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7759, that
document how to introduce this daemon for indexing
a dedicated
server
- to deal with translators demands/questions
- to manage a git repository on which pushing translation files for
Release Maintainers
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html
___
Koha-devel mailing list
Koha-devel
What should the manual say about the cron job? If it's not required
then I can say that, but I know that it's still there so I assume it
can be used and should be documented.
Take a look at:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6094
and my comment:
Translation files for Koha 3.6 are now all available on:
http://translate.koha-community.org
Dear translators, you're invited to start your (hard) work.
Thanks.
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html
___
Koha-devel mailing list
I can't find a bug related with this issue.
Bug 5579
___
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 :
Old story:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3087
http://www.mail-archive.com/koha-patches@lists.koha.org/msg01881.html
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html
___
Koha-devel mailing list
Koha-devel
translators work, improve string
extraction, improve Koha 'localizability', reduce .po files size.
For XSL files, we could (1) explicitly mark text to be translated or
(2) pick them up from an external XML file (performance warning).
Regards,
--
Frédéric DEMIANS
http://www.tamil.fr/u
.
I've just updated the Koha translation plateform:
http://translate.koha-community.org
I've done this update today because I won't be available tomorrow. From
what I can see, there isn't any new string in this update.
Regards,
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html
:
The following changes since commit 8fe46f3dc1a3250b04a0da2f6dd9335710b4e702:
Merge remote branch 'kc/new/bug_5143' into kcmaster (2010-12-20
13:24:40 +1300)
are available in the git repository at:
git://git.tamil.fr/git/koha qa_biblibre_admin
Frédéric Demians (1):
Merge branch 'master
to HEAD you have to revert to using the new syspref
editor. That's done on my branch.
--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman
Le 11/12/2010 11:55, Koustubha Kale a écrit :
1. Provide facility to upload scanned cover images linked to
biblionumber.
Where will you store them? On Koha server? on another server? on flickr?
somewhere else? Will you upload image file one by one during cataloging?
or will you load them in
One thing that may be of interest to some here is a new book on Perl
written in French
http://www.pearson.fr/livre/?GCOI=27440100979970
Merci cher ami !
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
I work with the author of XML::Simple .. and he would (and does) tell
people not to use it for anything than parsing very simple XML
structures.
Which is the case when benchmarking a simple MARCXML document parsing
switching quickly from one underlying SAX parser to the other.
So do I
misunderstand as I have to do my best to be understood.
That is what I am attempting to do and for the record, I spoke Maori
before I spoke English. Another misunderstanding :)
So thanks for trying to understand. And be ye merciful, even as your
Maori (metaphoric) Father is merciful.
And for those who want to run test by their self, here attached is my
tests comparing pure Perl parsing and various SAX parser (which need to
be installed):
XML::SAX::PurePerl
XML::LibXML::SAX::Parser
XML::SAX::Expat
XML::SAX::ExpatXS
SAX parsing is done directly, without using
Here we go
http://www.nntp.perl.org/group/perl.perl4lib/2006/05/msg2369.html
From this email, as I understand it, it seems that here is the reason
why Koha in search result deserialize MARC records from their ISO2709
representation rather than their MARCXML. If we were able to use
I am gleaning that from personal testing. That test script is very
system-dependent, unfortunately, so not meaningfully distributed.
But anyway would it be possible to provide to us sample data to do
similar testing?
--
Frédéric
___
Koha-devel
60 matches
Mail list logo
