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

[Cerninakova Eva]

Ones more again many thanks for the tip how to fix the problem. We have
applied the fix to Jabok Library catalog and the problem with character
encoding is solved for now :-).

When it comes to Zotero, would like to add one more note about incorrect
Zotero document type (as I have discovered  some Evergreen libraries  have
the problem as well and  I thought it might be worth mentioning):

Some time ago  we noticed, that Zotero did not detect correct type of the
document in our Evergreen catalog.  Especially for the "book type" the
document type was not recognized (and saved in Zotero)  as "book" but as
universal type „document“. This also  meant that Zotero icon in the catalog
in  address bar showed  „document“ not „book“. Because the document type
was correct sometimes and sometimes not, we try to explored the problem
deeper.
We came to conclusion that the solution lies in coded values in field 008.
>From "Zotero point of view" it is very  important to fill in the value for
„Nature of contents“ (positions 24-27). We also found that for book type
also positions 29 (Conference publication), 30 (Festschrift ) or 34
(Biography)  may affect the display of type of document: if position 24-27
are empty, and  some of above mentioned position o 008 field have value
provided, the type of document is displayed as book.
I am aware the matter is probably more complex and our conclusion might not
be comprehensive  but I hope even this lot might be useful for someone.

Eva








---
Mgr. Eva Cerniňáková
cernin at jabok.cz
Tel. +420 211 222 409

Knihovna Jabok
http:/knihovna.jabok.cuni.cz <http://knihovna.jabok.cz>
Tel.  +420 211 222 410

Jabok - Vyšší odborná škola sociálně pedagogická a teologická
Salmovská 8, 120 00 Praha 2


2015-04-09 20:14 GMT+02:00 Linda Jansova <skolkova at chello.cz>:

>  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> 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>
>> 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 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/20150413/5be8f5ac/attachment.html>