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 <skolk...@chello.cz <mailto:skolk...@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 <skolk...@chello.cz
    <mailto:skolk...@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.



Reply via email to