In current implementation (mostly commented out in this patch)
uses heuristic to guess which strings need decoding from utf-8
to binary representation and doesn't support utf-8 characters
in templates and has problems with utf-8 data from database.
With this changes, Koha perl code always uses utf-8 encoding
correctly. All incomming data from database is allready
correctly marked as utf-8, and decoding of utf8 is required
only from Zebra and XSLT transfers which don't set utf-8 flag
correctly.
For output, standard perl :encoding(utf8) handler is used
so it also removes various "wide character" warnings as side-effect.
Test scenario:
1. make sure that you have utf-8 characters in your biblio
records, patrons, categories etc.
2. try to search records on intranet and opac which contain
utf-8 characters
3. install language which has utf-8 characters, e.g. uk-UA
dpavlin@koha-dev:/srv/koha/misc/translator(bug_6554) $
PERL5LIB=/srv/koha/ perl translate install uk-UA
4. switch language to uk-UA and verify that templates
display correctly
5. test search and Z39.50 search and verify that caracters
are correct
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I followed the test plan, adding utf-8 characters to library names,
patron categories, titles, and authorized values. I tried the uk-UA
translation and everything looked good.
When performing Z39.50 searches for titles containing utf-8 characters I
got results which were still occasionally contaminated with dummy
characters [?] but I assume this is Z39.50's fault not the patch's.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Already signed, add mine.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
In several places, C4::ItemType module is used to retrieve item types
and their description. If the description text contains non-ASCII
characters, those characters are not properly displayed.
This bug can be seen in:
- 4xx plugin of a UNIMARC DB
- Home > Admin > Item circulation alerts
- others?...
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
- Fixes display probems in circulation alerts and 4xx UNIMARC plugin
- display in other places looks ok with and without patch
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
- C4::Letters:EnqueueLetter() is aware of new fields in message_queue table
- C4::Circulation::SendCirculationAlert() actually works
- C4::Category cleanup
- C4::ItemType cleanup
- C4::Message is a new module.
It presents yet another way to interact with the message_queue.
You can now take messages that have already been queued and modify
their contents before they're sent out.
Signed-off-by: Daniel Sweeney <daniel.sweeney@liblime.com>
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
* C4::Category
- patron categories as objects
- an all() method to return all the categories as a list
* C4::ItemType
- itemtypes as objects
- an all() method to return all the item types as a list
* C4::ItemCirculationAlertPreference
- wrapper around the item_circulation_alert_preference table
- create() and delete() methods for easy manipulation of the preferences
- I regret giving it such a long name.
- The item_type column should've been named itemtype to make it
more similar to pre-existing tables. Oh well.
(C4::Category and C4::ItemType were made so that I wouldn't have to
write SQL inside my CGI scripts.
Their main purpose is to provide an easy way to get a list of
patron categories and item types.
Do not be fooled by the amount of POD.
There's actually very little code in these modules.)
Signed-off-by: Daniel Sweeney <daniel.sweeney@liblime.com>
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
