[OPEN-ILS-GENERAL] Evergreen and Zotero - encoding problems

[Linda Jansova]

Thank you once again, Dan! It is tremendously helpful for us that you 
have provided this short-term fix :-)!

Linda

On 04/09/2015 06:58 PM, Dan Scott wrote:
> So I have a short-term fix that sites can apply documented in the bug 
> at https://bugs.launchpad.net/evergreen/+bug/1442276 - but it's not 
> something that I think is the right long-term fix.
>
> Still, seems worthwhile to point it out so that sites that want to 
> make their Zotero users (and other users of SuperCat feeds) happy can 
> do so until we figure out how to fix the problem properly.
>
> Dan
>
> On Thu, Apr 9, 2015 at 5:56 AM, Linda Jansova <skolkova at chello.cz 
> <mailto:skolkova at chello.cz>> wrote:
>
>     Thank you in advance, Dan!
>
>     Linda
>
>
>     On 04/08/2015 05:29 PM, Dan Scott wrote:
>>     On Sat, Apr 4, 2015 at 8:07 AM, Linda Jansova <skolkova at chello.cz
>>     <mailto:skolkova at chello.cz>> wrote:
>>
>>         Hi,
>>
>>         Our colleagues in Jabok Library would like to promote the
>>         usage of their Evergreen OPAC as Zotero source data so that
>>         their patrons (and others of course) would be able to import
>>         individual bibliographic records to Zotero reference
>>         management system (https://www.zotero.org/).
>>
>>         When used as a Mozilla Firefox plugin, it is clear that the
>>         data are imported via unAPI
>>         (http://en.wikipedia.org/wiki/UnAPI; unfortunately the
>>         homepage at http://unapi.info/ does not seem to be working; a
>>         bit of unAPI documentation is available at
>>         http://code4lib.org/files/unapi_revision_1-14.html, though
>>         maybe it is not the latest version).
>>
>>         Everything seems to work fine with one exception and these
>>         are records with non-ASCII characters such as letters with
>>         diacritics ("č" for example). As Czech language uses plenty
>>         of these, this issue virtually prevents us from using
>>         Evergreen as Zotero data source.
>>
>>         However, I have had a look at other Evergreen catalogs
>>         (including the one from Laurentian University) and it seems
>>         to me that the problem is also present there, e.g.
>>         https://laurentian.concat.ca/eg/opac/record/104728?query=francais;qtype=keyword;locg=105;detail_record_view=1
>>         (Le francais renouvelé - the "é" character is wrongly
>>         interpreted as could be seen at the attached picture).
>>
>>         Both in Jabok library catalog and in the catalog at
>>         Laurentian I have encountered the same problem when trying to
>>         print sample records with these say "special" characters,
>>         e.g.https://laurentian.concat.ca/eg/opac/record/print/104728?query=francais;qtype=keyword;locg=105;detail_record_view=1
>>
>>         Firefox seems to interpret the character encoding as Unicode
>>         when viewing the usual (not the print) version of the bib
>>         record but when one hits the "Print" button and then - when
>>         the print version is displayed - checks the encoding, Firefox
>>         interprets it as Western. Koha users have also been trying to
>>         sort out a similar issue
>>         (https://forums.zotero.org/discussion/39395/koha-translator-encoding-problem/)
>>         - in their case the solution seems to be to modify
>>         opac-export.pl <http://opac-export.pl> to export as UTF8.
>>
>>         Any ideas how to fix the issue in Evergreen? (Jabok uses
>>         Evergreen 2.6.4.)
>>
>>         Thank you in advance for sharing any hints!
>>
>>
>>     Hi, that's an interesting problem. Zotero uses Evergreen's MODS
>>     output, and it seems that the problem crept into the conversions
>>     that use specific MODS versions; compare
>>
>>     https://laurentian.concat.ca/opac/extras/supercat/retrieve/mods/record/28391
>>
>>     to
>>
>>     https://laurentian.concat.ca/opac/extras/supercat/retrieve/mods3/record/28391
>>
>>     and you'll see that the first one works as expected, while the
>>     second one is corrupted.
>>
>>     This is an issue for us too, as you can imagine (we're a
>>     bilingual institution with an extensive French collection), so
>>     I'll be digging into this.  I recently fixed a similar problem
>>     with our Z39.50 server output, so hopefully it won't take too long.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20150409/ea5a78cf/attachment.html>