Same here*: when I search for a (key)word in Greek, using the Search the
catalog prompt in the admin interface, I apparently get all the items with
some info or another entered in Greek. Furthermore, if I search for a single
Greek character, ξ for example, I get even more results: N result(s)
Hi Stephan,
in order to search non latin scripts with Koha correctly you need to make sure
that you are using ICU with Zebra. Then the search should work nicely. Some
notes on how to activate ICU indexing can be found on the wiki - it should also
work for Ukrainian:
Please see the attached image
on exactly what I mean.
Attachments are rejected by the list so you'll have to paste the text
of the error. Since the error message probably doesn't give many
details, it would be even better to look in Koha's error log for more
information. Please include your
the error is
can't call method 'raw' on undefined value at koha-path/C4/search.pm in
line 459
version 3.8.2
On Mon, Jan 6, 2014 at 4:40 PM, Owen Leonard oleon...@myacpl.org wrote:
Please see the attached image
on exactly what I mean.
Attachments are rejected by the list so you'll have to
Hi Katrin,
thank’s a lot! This solved my problem. Apparently, the only thing that was
necessary was to switch to yaz-icu and to modify zebradb/etc/default.idx
accordingly. I did not create a transliteration table.
Thank you very much again!
Stephan
Am 06.01.2014 um 11:10 schrieb Fischer,
On Mon, Jan 6, 2014 at 9:49 AM, Uğur Bulgan ugurbul...@sdu.edu.tr wrote:
Problem solved
Since we made upgrade, a new authorized value named SAGLAMA was defined.
Then I checked frameworks. Subfield e is mapped to SAGLAMAauthorized
value in BOOKS framework bu not in DEFAULT framework. I mapped
Greetings and happy new year
We're experimenting with 3.14.1 and a new colour scheme for the OPAC in our
test site.
The colour scheme seems to have applied just fine. The problem is with
bootstrap. With the bootstrap theme enabled we end up with unsightly grey
blocks with white text for tags
That link might be iframe src=
https://docs.google.com/a/efdss.org/file/d/0B0ag4Jlx4aGmbEhjbTVOLUo2RmRpc2NlZ2tycVg5akZOc3N3/preview;
width=640 height=480/iframe
On Mon, Jan 6, 2014 at 6:20 PM, Elaine Bradtke e...@efdss.org wrote:
Greetings and happy new year
We're experimenting with 3.14.1
I'm seeing some rather odd indexing problems with incremental indexing
and Koha 3.12.05.
I have everything set up with Zebra 2.0.56 and Yaz 5.0.9. Full indexing
works fine and incremental indexing logs the fact that changes are seen
and should be applied. And I've had incremental indexing
Hi Elaine,
On Mon, Jan 6, 2014 at 10:51 AM, Elaine Bradtke e...@efdss.org wrote:
That link might be iframe src=
https://docs.google.com/a/efdss.org/file/d/0B0ag4Jlx4aGmbEhjbTVOLUo2RmRpc2NlZ2tycVg5akZOc3N3/preview;
width=640 height=480/iframe
Could you post the additional CSS that you're using
Tom Hanstra schreef op ma 06-01-2014 om 13:35 [-0500]:
Has anyone seen such indexing problems before? What can I be
checking
to track this problem down and address it?
What do your logs say? In particular, is the cron job for indexing
actually running, and are emails from cron (which will
Galen, this is the CSS to change the colours, But, the grey boxes are
there even when I use the default Koha colour scheme.
https://drive.google.com/file/d/0B0ag4Jlx4aGmazByRmdSMzZBRFU/edit?usp=sharing
a
{
color: #e36f1e;
font-weight: bold;
text-decoration: none;
}
Hi,
On Mon, Jan 6, 2014 at 2:39 PM, Elaine Bradtke e...@efdss.org wrote:
Galen, this is the CSS to change the colours, But, the grey boxes are there
even when I use the default Koha colour scheme.
https://drive.google.com/file/d/0B0ag4Jlx4aGmazByRmdSMzZBRFU/edit?usp=sharing
The opac.css that
Right you are. Thanks for the pointer. I thought the stylesheet was the
default, but my technical half has been tinkering when I wasn't looking.
I reset it to opac.css and the grey blocks have vanished!
Thanks.
On Mon, Jan 6, 2014 at 10:53 PM, Galen Charlton g...@esilibrary.com wrote:
Hi,
14 matches
Mail list logo
