Since this translator is just a copy of the Rice modifications of the SIRSI translator, it would be best to just modify the Rice translator to support both catalogs. And if this translator can be expected to work out-of-the-box for more sites than USC and Rice, the right action to take at this point is to find ways to identify such SIRSI installations and run this modified version on all of them.
Are you using a particular version or module for SIRSI that requires these changes? We'd like to stay away from single-library modifications when a single translator would work, since the former is a maintenance nightmare.
Thanks for working on this-- I look forward to getting this out!
> -- > You received this message because you are subscribed to the Google Groups "zotero-dev" group. > To post to this group, send email to zotero-dev@googlegroups.com. > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/zotero-dev?hl=en.
Yes, I think this translator should work for Sirsi installations that
use the eLibrary OPAC templates. The problem is that I don't think
there is a way to specifically identify eLibrary installations vs.
earlier Sirsi templates (that use translator Library Catalog
(SIRSI).js) just by the URL. If we assign a lower priority number to
the eLibrary translator and item metadata is not found, does Zotero
fall back to the next higher priority number translator that matches?
In that case, the same regex target can be used for both translators.
Or do you have other suggestions?
--Joyce
On Jan 4, 1:21 pm, Avram Lyon <ajl...@gmail.com> wrote:
> Since this translator is just a copy of the Rice modifications of the
> SIRSI translator, it would be best to just modify the Rice translator
> to support both catalogs. And if this translator can be expected to
> work out-of-the-box for more sites than USC and Rice, the right action
> to take at this point is to find ways to identify such SIRSI
> installations and run this modified version on all of them.
> Are you using a particular version or module for SIRSI that requires
> these changes? We'd like to stay away from single-library
> modifications when a single translator would work, since the former is
> a maintenance nightmare.
> Thanks for working on this-- I look forward to getting this out!
> Avram
> On Wed, Jan 4, 2012 at 11:25 AM, jouchida <jouch...@gmail.com> wrote:
> > Hi, we'd like to submit this translator for the USC Libraries catalog.
> > --
> > You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> > To post to this group, send email to zotero-dev@googlegroups.com.
> > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
Obviously working through the target regexp for the URL is preferable
(i.e. less resource intensive), but if that's not possible yes,
starting with the eLibrary-Sirsi and falling back to regular Sirsi
should work as long as the detect function for eLibrary-Sirsi will
return false for regular Sirsi catalogs. It needs to fail at the
detect level, though, not during the actual import.
Are we reasonably sure that's the case? Does someone have a couple of
examples of old fashioned SIRSI?
Sebastian
On Jan 6, 12:46 pm, jouchida <jouch...@gmail.com> wrote:
> Yes, I think this translator should work for Sirsi installations that
> use the eLibrary OPAC templates. The problem is that I don't think
> there is a way to specifically identify eLibrary installations vs.
> earlier Sirsi templates (that use translator Library Catalog
> (SIRSI).js) just by the URL. If we assign a lower priority number to
> the eLibrary translator and item metadata is not found, does Zotero
> fall back to the next higher priority number translator that matches?
> In that case, the same regex target can be used for both translators.
> Or do you have other suggestions?
> --Joyce
> On Jan 4, 1:21 pm, Avram Lyon <ajl...@gmail.com> wrote:
> > Joyce,
> > Since this translator is just a copy of the Rice modifications of the
> > SIRSI translator, it would be best to just modify the Rice translator
> > to support both catalogs. And if this translator can be expected to
> > work out-of-the-box for more sites than USC and Rice, the right action
> > to take at this point is to find ways to identify such SIRSI
> > installations and run this modified version on all of them.
> > Are you using a particular version or module for SIRSI that requires
> > these changes? We'd like to stay away from single-library
> > modifications when a single translator would work, since the former is
> > a maintenance nightmare.
> > Thanks for working on this-- I look forward to getting this out!
> > Avram
> > On Wed, Jan 4, 2012 at 11:25 AM, jouchida <jouch...@gmail.com> wrote:
> > > Hi, we'd like to submit this translator for the USC Libraries catalog.
> > > --
> > > You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> > > To post to this group, send email to zotero-dev@googlegroups.com.
> > > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com.
> > > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
On Sat, Jan 7, 2012 at 9:23 AM, adamsmith <bst...@gmx.de> wrote: > Obviously working through the target regexp for the URL is preferable > (i.e. less resource intensive), but if that's not possible yes, > starting with the eLibrary-Sirsi and falling back to regular Sirsi > should work as long as the detect function for eLibrary-Sirsi will > return false for regular Sirsi catalogs. It needs to fail at the > detect level, though, not during the actual import.
I'd be happy to see this as a fallback during detection. Just try to make the eLibrary-Sirsi detectWeb return false as quickly as possible for non-eLibrary installs.
Joyce, would you feel comfortable taking this on and doing a little testing on eLibrary and non-eLibrary sites?
> Are we reasonably sure that's the case? Does someone have a couple of > examples of old fashioned SIRSI? > Sebastian
> On Jan 6, 12:46 pm, jouchida <jouch...@gmail.com> wrote: >> Hi Avram,
>> Yes, I think this translator should work for Sirsi installations that >> use the eLibrary OPAC templates. The problem is that I don't think >> there is a way to specifically identify eLibrary installations vs. >> earlier Sirsi templates (that use translator Library Catalog >> (SIRSI).js) just by the URL. If we assign a lower priority number to >> the eLibrary translator and item metadata is not found, does Zotero >> fall back to the next higher priority number translator that matches? >> In that case, the same regex target can be used for both translators. >> Or do you have other suggestions?
>> --Joyce
>> On Jan 4, 1:21 pm, Avram Lyon <ajl...@gmail.com> wrote:
>> > Joyce,
>> > Since this translator is just a copy of the Rice modifications of the >> > SIRSI translator, it would be best to just modify the Rice translator >> > to support both catalogs. And if this translator can be expected to >> > work out-of-the-box for more sites than USC and Rice, the right action >> > to take at this point is to find ways to identify such SIRSI >> > installations and run this modified version on all of them.
>> > Are you using a particular version or module for SIRSI that requires >> > these changes? We'd like to stay away from single-library >> > modifications when a single translator would work, since the former is >> > a maintenance nightmare.
>> > Thanks for working on this-- I look forward to getting this out!
>> > Avram
>> > On Wed, Jan 4, 2012 at 11:25 AM, jouchida <jouch...@gmail.com> wrote: >> > > Hi, we'd like to submit this translator for the USC Libraries catalog.
>> > > -- >> > > You received this message because you are subscribed to the Google Groups "zotero-dev" group. >> > > To post to this group, send email to zotero-dev@googlegroups.com. >> > > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com. >> > > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "zotero-dev" group. > To post to this group, send email to zotero-dev@googlegroups.com. > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/zotero-dev?hl=en.
The code is essentially the same as Rice University's translator (so I
kept the creator the same), but I've genericized the regex, the
priority code, and some branded values within the javascript. I didn't
edit the detectWeb code, it seemed to already be working fine. I've
tested on Sirsi sites (as listed under Unicorn on this page:
http://www.librarytechnology.org/arl.pl) and confirmed that both pre-
eLibrary and eLibrary sites are zotero-enabled, with some exceptions
due perhaps to template customizations by the institution. eLibrary
sites that are not currently zotero-enabled become zotero-enabled when
this translator is installed locally.
Also, the 2 existing eLibrary translators for Rice U. & IRIS seem to
take precedence over this translator, which is fine since I don't want
to mess with their connectors.
Anyway, as far as I can tell, this should work for Sirsi eLibrary
catalogs and not break other Sirsi connectors. Let me know if there
are any issues. I'm a zotero newbie so I might have missed something.
--Joyce
On Jan 7, 7:11 pm, Avram Lyon <ajl...@gmail.com> wrote:
> On Sat, Jan 7, 2012 at 9:23 AM, adamsmith <bst...@gmx.de> wrote:
> > Obviously working through the target regexp for the URL is preferable
> > (i.e. less resource intensive), but if that's not possible yes,
> > starting with the eLibrary-Sirsi and falling back to regular Sirsi
> > should work as long as the detect function for eLibrary-Sirsi will
> > return false for regular Sirsi catalogs. It needs to fail at the
> > detect level, though, not during the actual import.
> I'd be happy to see this as a fallback during detection. Just try to
> make the eLibrary-Sirsi detectWeb return false as quickly as possible
> for non-eLibrary installs.
> Joyce, would you feel comfortable taking this on and doing a little
> testing on eLibrary and non-eLibrary sites?
> Avram
> > Are we reasonably sure that's the case? Does someone have a couple of
> > examples of old fashioned SIRSI?
> > Sebastian
> > On Jan 6, 12:46 pm, jouchida <jouch...@gmail.com> wrote:
> >> Hi Avram,
> >> Yes, I think this translator should work for Sirsi installations that
> >> use the eLibrary OPAC templates. The problem is that I don't think
> >> there is a way to specifically identify eLibrary installations vs.
> >> earlier Sirsi templates (that use translator Library Catalog
> >> (SIRSI).js) just by the URL. If we assign a lower priority number to
> >> the eLibrary translator and item metadata is not found, does Zotero
> >> fall back to the next higher priority number translator that matches?
> >> In that case, the same regex target can be used for both translators.
> >> Or do you have other suggestions?
> >> --Joyce
> >> On Jan 4, 1:21 pm, Avram Lyon <ajl...@gmail.com> wrote:
> >> > Joyce,
> >> > Since this translator is just a copy of the Rice modifications of the
> >> > SIRSI translator, it would be best to just modify the Rice translator
> >> > to support both catalogs. And if this translator can be expected to
> >> > work out-of-the-box for more sites than USC and Rice, the right action
> >> > to take at this point is to find ways to identify such SIRSI
> >> > installations and run this modified version on all of them.
> >> > Are you using a particular version or module for SIRSI that requires
> >> > these changes? We'd like to stay away from single-library
> >> > modifications when a single translator would work, since the former is
> >> > a maintenance nightmare.
> >> > Thanks for working on this-- I look forward to getting this out!
> >> > Avram
> >> > On Wed, Jan 4, 2012 at 11:25 AM, jouchida <jouch...@gmail.com> wrote:
> >> > > Hi, we'd like to submit this translator for the USC Libraries catalog.
> >> > > --
> >> > > You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> >> > > To post to this group, send email to zotero-dev@googlegroups.com.
> >> > > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com.
> >> > > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
> > --
> > You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> > To post to this group, send email to zotero-dev@googlegroups.com.
> > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
I want to clean up the code some before rolling this out, in part to ease future troubleshooting and in part to make it possible to add support for other e-Library installs that it doesn't currently support. I would be very interested in making the translator continue using MARC data, since our current approach of using natural language labels in the interface will break down very quickly internationally.
Can you, your local SirsiDynix specialists, or anyone else on the list say whether there's a way to get MARC data through the OPAC without going to Display Options --> unformatted display --> Full Record?
Doing this through scraping alone isn't going to cut it, I'm afraid.
I can redirect my question to code4lib if need be.
> The code is essentially the same as Rice University's translator (so I > kept the creator the same), but I've genericized the regex, the > priority code, and some branded values within the javascript. I didn't > edit the detectWeb code, it seemed to already be working fine. I've > tested on Sirsi sites (as listed under Unicorn on this page: > http://www.librarytechnology.org/arl.pl) and confirmed that both pre- > eLibrary and eLibrary sites are zotero-enabled, with some exceptions > due perhaps to template customizations by the institution. eLibrary > sites that are not currently zotero-enabled become zotero-enabled when > this translator is installed locally.
> Also, the 2 existing eLibrary translators for Rice U. & IRIS seem to > take precedence over this translator, which is fine since I don't want > to mess with their connectors.
> Anyway, as far as I can tell, this should work for Sirsi eLibrary > catalogs and not break other Sirsi connectors. Let me know if there > are any issues. I'm a zotero newbie so I might have missed something.
> --Joyce
> On Jan 7, 7:11 pm, Avram Lyon <ajl...@gmail.com> wrote: >> On Sat, Jan 7, 2012 at 9:23 AM, adamsmith <bst...@gmx.de> wrote: >> > Obviously working through the target regexp for the URL is preferable >> > (i.e. less resource intensive), but if that's not possible yes, >> > starting with the eLibrary-Sirsi and falling back to regular Sirsi >> > should work as long as the detect function for eLibrary-Sirsi will >> > return false for regular Sirsi catalogs. It needs to fail at the >> > detect level, though, not during the actual import.
>> I'd be happy to see this as a fallback during detection. Just try to >> make the eLibrary-Sirsi detectWeb return false as quickly as possible >> for non-eLibrary installs.
>> Joyce, would you feel comfortable taking this on and doing a little >> testing on eLibrary and non-eLibrary sites?
>> Avram
>> > Are we reasonably sure that's the case? Does someone have a couple of >> > examples of old fashioned SIRSI? >> > Sebastian
>> > On Jan 6, 12:46 pm, jouchida <jouch...@gmail.com> wrote: >> >> Hi Avram,
>> >> Yes, I think this translator should work for Sirsi installations that >> >> use the eLibrary OPAC templates. The problem is that I don't think >> >> there is a way to specifically identify eLibrary installations vs. >> >> earlier Sirsi templates (that use translator Library Catalog >> >> (SIRSI).js) just by the URL. If we assign a lower priority number to >> >> the eLibrary translator and item metadata is not found, does Zotero >> >> fall back to the next higher priority number translator that matches? >> >> In that case, the same regex target can be used for both translators. >> >> Or do you have other suggestions?
>> >> --Joyce
>> >> On Jan 4, 1:21 pm, Avram Lyon <ajl...@gmail.com> wrote:
>> >> > Joyce,
>> >> > Since this translator is just a copy of the Rice modifications of the >> >> > SIRSI translator, it would be best to just modify the Rice translator >> >> > to support both catalogs. And if this translator can be expected to >> >> > work out-of-the-box for more sites than USC and Rice, the right action >> >> > to take at this point is to find ways to identify such SIRSI >> >> > installations and run this modified version on all of them.
>> >> > Are you using a particular version or module for SIRSI that requires >> >> > these changes? We'd like to stay away from single-library >> >> > modifications when a single translator would work, since the former is >> >> > a maintenance nightmare.
>> >> > Thanks for working on this-- I look forward to getting this out!
>> >> > Avram
>> >> > On Wed, Jan 4, 2012 at 11:25 AM, jouchida <jouch...@gmail.com> wrote: >> >> > > Hi, we'd like to submit this translator for the USC Libraries catalog.
>> >> > > -- >> >> > > You received this message because you are subscribed to the Google Groups "zotero-dev" group. >> >> > > To post to this group, send email to zotero-dev@googlegroups.com. >> >> > > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com. >> >> > > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
>> > -- >> > You received this message because you are subscribed to the Google Groups "zotero-dev" group. >> > To post to this group, send email to zotero-dev@googlegroups.com. >> > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com. >> > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "zotero-dev" group. > To post to this group, send email to zotero-dev@googlegroups.com. > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/zotero-dev?hl=en.
As far as I and my colleagues know, that is the only way to get MARC
data through the OPAC: Display Options --> unformatted display -->
All. I think All is more complete than Full.
--Joyce
On Jan 11, 9:41 pm, Avram Lyon <ajl...@gmail.com> wrote:
> I want to clean up the code some before rolling this out, in part to
> ease future troubleshooting and in part to make it possible to add
> support for other e-Library installs that it doesn't currently
> support. I would be very interested in making the translator continue
> using MARC data, since our current approach of using natural language
> labels in the interface will break down very quickly internationally.
> Can you, your local SirsiDynix specialists, or anyone else on the list
> say whether there's a way to get MARC data through the OPAC without
> going to Display Options --> unformatted display --> Full Record?
> Doing this through scraping alone isn't going to cut it, I'm afraid.
> I can redirect my question to code4lib if need be.
> Avram
> On Wed, Jan 11, 2012 at 5:57 PM, jouchida <jouch...@gmail.com> wrote:
> > Hi,
> > The code is essentially the same as Rice University's translator (so I
> > kept the creator the same), but I've genericized the regex, the
> > priority code, and some branded values within the javascript. I didn't
> > edit the detectWeb code, it seemed to already be working fine. I've
> > tested on Sirsi sites (as listed under Unicorn on this page:
> >http://www.librarytechnology.org/arl.pl) and confirmed that both pre-
> > eLibrary and eLibrary sites are zotero-enabled, with some exceptions
> > due perhaps to template customizations by the institution. eLibrary
> > sites that are not currently zotero-enabled become zotero-enabled when
> > this translator is installed locally.
> > Also, the 2 existing eLibrary translators for Rice U. & IRIS seem to
> > take precedence over this translator, which is fine since I don't want
> > to mess with their connectors.
> > Anyway, as far as I can tell, this should work for Sirsi eLibrary
> > catalogs and not break other Sirsi connectors. Let me know if there
> > are any issues. I'm a zotero newbie so I might have missed something.
> > --Joyce
> > On Jan 7, 7:11 pm, Avram Lyon <ajl...@gmail.com> wrote:
> >> On Sat, Jan 7, 2012 at 9:23 AM, adamsmith <bst...@gmx.de> wrote:
> >> > Obviously working through the target regexp for the URL is preferable
> >> > (i.e. less resource intensive), but if that's not possible yes,
> >> > starting with the eLibrary-Sirsi and falling back to regular Sirsi
> >> > should work as long as the detect function for eLibrary-Sirsi will
> >> > return false for regular Sirsi catalogs. It needs to fail at the
> >> > detect level, though, not during the actual import.
> >> I'd be happy to see this as a fallback during detection. Just try to
> >> make the eLibrary-Sirsi detectWeb return false as quickly as possible
> >> for non-eLibrary installs.
> >> Joyce, would you feel comfortable taking this on and doing a little
> >> testing on eLibrary and non-eLibrary sites?
> >> Avram
> >> > Are we reasonably sure that's the case? Does someone have a couple of
> >> > examples of old fashioned SIRSI?
> >> > Sebastian
> >> > On Jan 6, 12:46 pm, jouchida <jouch...@gmail.com> wrote:
> >> >> Hi Avram,
> >> >> Yes, I think this translator should work for Sirsi installations that
> >> >> use the eLibrary OPAC templates. The problem is that I don't think
> >> >> there is a way to specifically identify eLibrary installations vs.
> >> >> earlier Sirsi templates (that use translator Library Catalog
> >> >> (SIRSI).js) just by the URL. If we assign a lower priority number to
> >> >> the eLibrary translator and item metadata is not found, does Zotero
> >> >> fall back to the next higher priority number translator that matches?
> >> >> In that case, the same regex target can be used for both translators.
> >> >> Or do you have other suggestions?
> >> >> --Joyce
> >> >> On Jan 4, 1:21 pm, Avram Lyon <ajl...@gmail.com> wrote:
> >> >> > Joyce,
> >> >> > Since this translator is just a copy of the Rice modifications of the
> >> >> > SIRSI translator, it would be best to just modify the Rice translator
> >> >> > to support both catalogs. And if this translator can be expected to
> >> >> > work out-of-the-box for more sites than USC and Rice, the right action
> >> >> > to take at this point is to find ways to identify such SIRSI
> >> >> > installations and run this modified version on all of them.
> >> >> > Are you using a particular version or module for SIRSI that requires
> >> >> > these changes? We'd like to stay away from single-library
> >> >> > modifications when a single translator would work, since the former is
> >> >> > a maintenance nightmare.
> >> >> > Thanks for working on this-- I look forward to getting this out!
> >> >> > Avram
> >> >> > On Wed, Jan 4, 2012 at 11:25 AM, jouchida <jouch...@gmail.com> wrote:
> >> >> > > Hi, we'd like to submit this translator for the USC Libraries catalog.
> >> >> > > --
> >> >> > > You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> >> >> > > To post to this group, send email to zotero-dev@googlegroups.com.
> >> >> > > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com.
> >> >> > > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
> >> > --
> >> > You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> >> > To post to this group, send email to zotero-dev@googlegroups.com.
> >> > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com.
> >> > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
> > --
> > You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> > To post to this group, send email to zotero-dev@googlegroups.com.
> > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
I wonder if any progress has been made on this translator. We have
received many patron inquiries about Zotero-compatibility since we
upgraded to eLibrary, and we've been offering our translator as a
local download.
Re MARC data: looking at the original Zotero translator for Sirsi
(Library Catalog (SIRSI).js), there is an import function that uses
some URL to get MARC data. I will follow up with Sirsi support and try
to get more specific details about it.
Thanks for your help,
Joyce
On Jan 12, 10:49 am, jouchida <jouch...@gmail.com> wrote:
> As far as I and my colleagues know, that is the only way to get MARC
> data through the OPAC: Display Options --> unformatted display -->
> All. I think All is more complete than Full.
> --Joyce
> On Jan 11, 9:41 pm, Avram Lyon <ajl...@gmail.com> wrote:
> > Joyce,
> > I want to clean up the code some before rolling this out, in part to
> > ease future troubleshooting and in part to make it possible to add
> > support for other e-Library installs that it doesn't currently
> > support. I would be very interested in making the translator continue
> > using MARC data, since our current approach of using natural language
> > labels in the interface will break down very quickly internationally.
> > Can you, your local SirsiDynix specialists, or anyone else on the list
> > say whether there's a way to get MARC data through the OPAC without
> > going to Display Options --> unformatted display --> Full Record?
> > Doing this through scraping alone isn't going to cut it, I'm afraid.
> > I can redirect my question to code4lib if need be.
> > Avram
> > On Wed, Jan 11, 2012 at 5:57 PM, jouchida <jouch...@gmail.com> wrote:
> > > Hi,
> > > The code is essentially the same as Rice University's translator (so I
> > > kept the creator the same), but I've genericized the regex, the
> > > priority code, and some branded values within the javascript. I didn't
> > > edit the detectWeb code, it seemed to already be working fine. I've
> > > tested on Sirsi sites (as listed under Unicorn on this page:
> > >http://www.librarytechnology.org/arl.pl) and confirmed that both pre-
> > > eLibrary and eLibrary sites are zotero-enabled, with some exceptions
> > > due perhaps to template customizations by the institution. eLibrary
> > > sites that are not currently zotero-enabled become zotero-enabled when
> > > this translator is installed locally.
> > > Also, the 2 existing eLibrary translators for Rice U. & IRIS seem to
> > > take precedence over this translator, which is fine since I don't want
> > > to mess with their connectors.
> > > Anyway, as far as I can tell, this should work for Sirsi eLibrary
> > > catalogs and not break other Sirsi connectors. Let me know if there
> > > are any issues. I'm a zotero newbie so I might have missed something.
> > > --Joyce
> > > On Jan 7, 7:11 pm, Avram Lyon <ajl...@gmail.com> wrote:
> > >> On Sat, Jan 7, 2012 at 9:23 AM, adamsmith <bst...@gmx.de> wrote:
> > >> > Obviously working through the target regexp for the URL is preferable
> > >> > (i.e. less resource intensive), but if that's not possible yes,
> > >> > starting with the eLibrary-Sirsi and falling back to regular Sirsi
> > >> > should work as long as the detect function for eLibrary-Sirsi will
> > >> > return false for regular Sirsi catalogs. It needs to fail at the
> > >> > detect level, though, not during the actual import.
> > >> I'd be happy to see this as a fallback during detection. Just try to
> > >> make the eLibrary-Sirsi detectWeb return false as quickly as possible
> > >> for non-eLibrary installs.
> > >> Joyce, would you feel comfortable taking this on and doing a little
> > >> testing on eLibrary and non-eLibrary sites?
> > >> Avram
> > >> > Are we reasonably sure that's the case? Does someone have a couple of
> > >> > examples of old fashioned SIRSI?
> > >> > Sebastian
> > >> > On Jan 6, 12:46 pm, jouchida <jouch...@gmail.com> wrote:
> > >> >> Hi Avram,
> > >> >> Yes, I think this translator should work for Sirsi installations that
> > >> >> use the eLibrary OPAC templates. The problem is that I don't think
> > >> >> there is a way to specifically identify eLibrary installations vs.
> > >> >> earlier Sirsi templates (that use translator Library Catalog
> > >> >> (SIRSI).js) just by the URL. If we assign a lower priority number to
> > >> >> the eLibrary translator and item metadata is not found, does Zotero
> > >> >> fall back to the next higher priority number translator that matches?
> > >> >> In that case, the same regex target can be used for both translators.
> > >> >> Or do you have other suggestions?
> > >> >> --Joyce
> > >> >> On Jan 4, 1:21 pm, Avram Lyon <ajl...@gmail.com> wrote:
> > >> >> > Joyce,
> > >> >> > Since this translator is just a copy of the Rice modifications of the
> > >> >> > SIRSI translator, it would be best to just modify the Rice translator
> > >> >> > to support both catalogs. And if this translator can be expected to
> > >> >> > work out-of-the-box for more sites than USC and Rice, the right action
> > >> >> > to take at this point is to find ways to identify such SIRSI
> > >> >> > installations and run this modified version on all of them.
> > >> >> > Are you using a particular version or module for SIRSI that requires
> > >> >> > these changes? We'd like to stay away from single-library
> > >> >> > modifications when a single translator would work, since the former is
> > >> >> > a maintenance nightmare.
> > >> >> > Thanks for working on this-- I look forward to getting this out!
> > >> >> > Avram
> > >> >> > On Wed, Jan 4, 2012 at 11:25 AM, jouchida <jouch...@gmail.com> wrote:
> > >> >> > > Hi, we'd like to submit this translator for the USC Libraries catalog.
> > >> >> > > --
> > >> >> > > You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> > >> >> > > To post to this group, send email to zotero-dev@googlegroups.com.
> > >> >> > > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com.
> > >> >> > > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
> > >> > --
> > >> > You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> > >> > To post to this group, send email to zotero-dev@googlegroups.com.
> > >> > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com.
> > >> > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
> > > --
> > > You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> > > To post to this group, send email to zotero-dev@googlegroups.com.
> > > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com.
> > > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
> I wonder if any progress has been made on this translator. We have
> received many patron inquiries about Zotero-compatibility since we
> upgraded to eLibrary, and we've been offering our translator as a
> local download.
> Re MARC data: looking at the original Zotero translator for Sirsi
> (Library Catalog (SIRSI).js), there is an import function that uses
> some URL to get MARC data. I will follow up with Sirsi support and try
> to get more specific details about it.
> Thanks for your help,
> Joyce
> On Jan 12, 10:49 am, jouchida <jouch...@gmail.com> wrote:
> > As far as I and my colleagues know, that is the only way to get MARC
> > data through the OPAC: Display Options --> unformatted display -->
> > All. I think All is more complete than Full.
> > --Joyce
> > On Jan 11, 9:41 pm, Avram Lyon <ajl...@gmail.com> wrote:
> > > Joyce,
> > > I want to clean up the code some before rolling this out, in part to
> > > ease future troubleshooting and in part to make it possible to add
> > > support for other e-Library installs that it doesn't currently
> > > support. I would be very interested in making the translator continue
> > > using MARC data, since our current approach of using natural language
> > > labels in the interface will break down very quickly internationally.
> > > Can you, your local SirsiDynix specialists, or anyone else on the list
> > > say whether there's a way to get MARC data through the OPAC without
> > > going to Display Options --> unformatted display --> Full Record?
> > > Doing this through scraping alone isn't going to cut it, I'm afraid.
> > > I can redirect my question to code4lib if need be.
> > > Avram
> > > On Wed, Jan 11, 2012 at 5:57 PM, jouchida <jouch...@gmail.com> wrote:
> > > > Hi,
> > > > The code is essentially the same as Rice University's translator (so I
> > > > kept the creator the same), but I've genericized the regex, the
> > > > priority code, and some branded values within the javascript. I didn't
> > > > edit the detectWeb code, it seemed to already be working fine. I've
> > > > tested on Sirsi sites (as listed under Unicorn on this page:
> > > >http://www.librarytechnology.org/arl.pl) and confirmed that both pre-
> > > > eLibrary and eLibrary sites are zotero-enabled, with some exceptions
> > > > due perhaps to template customizations by the institution. eLibrary
> > > > sites that are not currently zotero-enabled become zotero-enabled when
> > > > this translator is installed locally.
> > > > Also, the 2 existing eLibrary translators for Rice U. & IRIS seem to
> > > > take precedence over this translator, which is fine since I don't want
> > > > to mess with their connectors.
> > > > Anyway, as far as I can tell, this should work for Sirsi eLibrary
> > > > catalogs and not break other Sirsi connectors. Let me know if there
> > > > are any issues. I'm a zotero newbie so I might have missed something.
> > > > --Joyce
> > > > On Jan 7, 7:11 pm, Avram Lyon <ajl...@gmail.com> wrote:
> > > >> On Sat, Jan 7, 2012 at 9:23 AM, adamsmith <bst...@gmx.de> wrote:
> > > >> > Obviously working through the target regexp for the URL is preferable
> > > >> > (i.e. less resource intensive), but if that's not possible yes,
> > > >> > starting with the eLibrary-Sirsi and falling back to regular Sirsi
> > > >> > should work as long as the detect function for eLibrary-Sirsi will
> > > >> > return false for regular Sirsi catalogs. It needs to fail at the
> > > >> > detect level, though, not during the actual import.
> > > >> I'd be happy to see this as a fallback during detection. Just try to
> > > >> make the eLibrary-Sirsi detectWeb return false as quickly as possible
> > > >> for non-eLibrary installs.
> > > >> Joyce, would you feel comfortable taking this on and doing a little
> > > >> testing on eLibrary and non-eLibrary sites?
> > > >> Avram
> > > >> > Are we reasonably sure that's the case? Does someone have a couple of
> > > >> > examples of old fashioned SIRSI?
> > > >> > Sebastian
> > > >> > On Jan 6, 12:46 pm, jouchida <jouch...@gmail.com> wrote:
> > > >> >> Hi Avram,
> > > >> >> Yes, I think this translator should work for Sirsi installations that
> > > >> >> use the eLibrary OPAC templates. The problem is that I don't think
> > > >> >> there is a way to specifically identify eLibrary installations vs.
> > > >> >> earlier Sirsi templates (that use translator Library Catalog
> > > >> >> (SIRSI).js) just by the URL. If we assign a lower priority number to
> > > >> >> the eLibrary translator and item metadata is not found, does Zotero
> > > >> >> fall back to the next higher priority number translator that matches?
> > > >> >> In that case, the same regex target can be used for both translators.
> > > >> >> Or do you have other suggestions?
> > > >> >> --Joyce
> > > >> >> On Jan 4, 1:21 pm, Avram Lyon <ajl...@gmail.com> wrote:
> > > >> >> > Joyce,
> > > >> >> > Since this translator is just a copy of the Rice modifications of the
> > > >> >> > SIRSI translator, it would be best to just modify the Rice translator
> > > >> >> > to support both catalogs. And if this translator can be expected to
> > > >> >> > work out-of-the-box for more sites than USC and Rice, the right action
> > > >> >> > to take at this point is to find ways to identify such SIRSI
> > > >> >> > installations and run this modified version on all of them.
> > > >> >> > Are you using a particular version or module for SIRSI that requires
> > > >> >> > these changes? We'd like to stay away from single-library
> > > >> >> > modifications when a single translator would work, since the former is
> > > >> >> > a maintenance nightmare.
> > > >> >> > Thanks for working on this-- I look forward to getting this out!
> > > >> >> > Avram
> > > >> >> > On Wed, Jan 4, 2012 at 11:25 AM, jouchida <jouch...@gmail.com> wrote:
> > > >> >> > > Hi, we'd like to submit this translator for the USC Libraries catalog.
> > > >> >> > > --
> > > >> >> > > You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> > > >> >> > > To post to this group, send email to zotero-dev@googlegroups.com.
> > > >> >> > > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com.
> > > >> >> > > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
> > > >> > --
> > > >> > You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> > > >> > To post to this group, send email to zotero-dev@googlegroups.com.
> > > >> > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com.
> > > >> > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
> > > > --
> > > > You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> > > > To post to this group, send email to zotero-dev@googlegroups.com.
> > > > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com.
> > > > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
On Thu, Jan 26, 2012 at 12:02 PM, jouchida <jouch...@gmail.com> wrote: > Never mind my last comment on MARC data -- it's not an import > function, and the same code exists in the updated translator.
> On Jan 26, 11:24 am, jouchida <jouch...@gmail.com> wrote: >> Hi,
>> I wonder if any progress has been made on this translator. We have >> received many patron inquiries about Zotero-compatibility since we >> upgraded to eLibrary, and we've been offering our translator as a >> local download.
>> Re MARC data: looking at the original Zotero translator for Sirsi >> (Library Catalog (SIRSI).js), there is an import function that uses >> some URL to get MARC data. I will follow up with Sirsi support and try >> to get more specific details about it.
>> Thanks for your help, >> Joyce
>> On Jan 12, 10:49 am, jouchida <jouch...@gmail.com> wrote:
>> > As far as I and my colleagues know, that is the only way to get MARC >> > data through the OPAC: Display Options --> unformatted display --> >> > All. I think All is more complete than Full.
>> > --Joyce
>> > On Jan 11, 9:41 pm, Avram Lyon <ajl...@gmail.com> wrote:
>> > > Joyce,
>> > > I want to clean up the code some before rolling this out, in part to >> > > ease future troubleshooting and in part to make it possible to add >> > > support for other e-Library installs that it doesn't currently >> > > support. I would be very interested in making the translator continue >> > > using MARC data, since our current approach of using natural language >> > > labels in the interface will break down very quickly internationally.
>> > > Can you, your local SirsiDynix specialists, or anyone else on the list >> > > say whether there's a way to get MARC data through the OPAC without >> > > going to Display Options --> unformatted display --> Full Record?
>> > > Doing this through scraping alone isn't going to cut it, I'm afraid.
>> > > I can redirect my question to code4lib if need be.
>> > > Avram
>> > > On Wed, Jan 11, 2012 at 5:57 PM, jouchida <jouch...@gmail.com> wrote: >> > > > Hi,
>> > > > The code is essentially the same as Rice University's translator (so I >> > > > kept the creator the same), but I've genericized the regex, the >> > > > priority code, and some branded values within the javascript. I didn't >> > > > edit the detectWeb code, it seemed to already be working fine. I've >> > > > tested on Sirsi sites (as listed under Unicorn on this page: >> > > >http://www.librarytechnology.org/arl.pl) and confirmed that both pre- >> > > > eLibrary and eLibrary sites are zotero-enabled, with some exceptions >> > > > due perhaps to template customizations by the institution. eLibrary >> > > > sites that are not currently zotero-enabled become zotero-enabled when >> > > > this translator is installed locally.
>> > > > Also, the 2 existing eLibrary translators for Rice U. & IRIS seem to >> > > > take precedence over this translator, which is fine since I don't want >> > > > to mess with their connectors.
>> > > > Anyway, as far as I can tell, this should work for Sirsi eLibrary >> > > > catalogs and not break other Sirsi connectors. Let me know if there >> > > > are any issues. I'm a zotero newbie so I might have missed something.
>> > > > --Joyce
>> > > > On Jan 7, 7:11 pm, Avram Lyon <ajl...@gmail.com> wrote: >> > > >> On Sat, Jan 7, 2012 at 9:23 AM, adamsmith <bst...@gmx.de> wrote: >> > > >> > Obviously working through the target regexp for the URL is preferable >> > > >> > (i.e. less resource intensive), but if that's not possible yes, >> > > >> > starting with the eLibrary-Sirsi and falling back to regular Sirsi >> > > >> > should work as long as the detect function for eLibrary-Sirsi will >> > > >> > return false for regular Sirsi catalogs. It needs to fail at the >> > > >> > detect level, though, not during the actual import.
>> > > >> I'd be happy to see this as a fallback during detection. Just try to >> > > >> make the eLibrary-Sirsi detectWeb return false as quickly as possible >> > > >> for non-eLibrary installs.
>> > > >> Joyce, would you feel comfortable taking this on and doing a little >> > > >> testing on eLibrary and non-eLibrary sites?
>> > > >> Avram
>> > > >> > Are we reasonably sure that's the case? Does someone have a couple of >> > > >> > examples of old fashioned SIRSI? >> > > >> > Sebastian
>> > > >> > On Jan 6, 12:46 pm, jouchida <jouch...@gmail.com> wrote: >> > > >> >> Hi Avram,
>> > > >> >> Yes, I think this translator should work for Sirsi installations that >> > > >> >> use the eLibrary OPAC templates. The problem is that I don't think >> > > >> >> there is a way to specifically identify eLibrary installations vs. >> > > >> >> earlier Sirsi templates (that use translator Library Catalog >> > > >> >> (SIRSI).js) just by the URL. If we assign a lower priority number to >> > > >> >> the eLibrary translator and item metadata is not found, does Zotero >> > > >> >> fall back to the next higher priority number translator that matches? >> > > >> >> In that case, the same regex target can be used for both translators. >> > > >> >> Or do you have other suggestions?
>> > > >> >> --Joyce
>> > > >> >> On Jan 4, 1:21 pm, Avram Lyon <ajl...@gmail.com> wrote:
>> > > >> >> > Joyce,
>> > > >> >> > Since this translator is just a copy of the Rice modifications of the >> > > >> >> > SIRSI translator, it would be best to just modify the Rice translator >> > > >> >> > to support both catalogs. And if this translator can be expected to >> > > >> >> > work out-of-the-box for more sites than USC and Rice, the right action >> > > >> >> > to take at this point is to find ways to identify such SIRSI >> > > >> >> > installations and run this modified version on all of them.
>> > > >> >> > Are you using a particular version or module for SIRSI that requires >> > > >> >> > these changes? We'd like to stay away from single-library >> > > >> >> > modifications when a single translator would work, since the former is >> > > >> >> > a maintenance nightmare.
>> > > >> >> > Thanks for working on this-- I look forward to getting this out!
>> > > >> >> > Avram
>> > > >> >> > On Wed, Jan 4, 2012 at 11:25 AM, jouchida <jouch...@gmail.com> wrote: >> > > >> >> > > Hi, we'd like to submit this translator for the USC Libraries catalog.
>> > > >> >> > > -- >> > > >> >> > > You received this message because you are subscribed to the Google Groups "zotero-dev" group. >> > > >> >> > > To post to this group, send email to zotero-dev@googlegroups.com. >> > > >> >> > > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com. >> > > >> >> > > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
>> > > >> > -- >> > > >> > You received this message because you are subscribed to the Google Groups "zotero-dev" group. >> > > >> > To post to this group, send email to zotero-dev@googlegroups.com. >> > > >> > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com. >> > > >> > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
>> > > > -- >> > > > You received this message because you are subscribed to the Google Groups "zotero-dev" group. >> > > > To post to this group, send email to zotero-dev@googlegroups.com. >> > > > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com. >> > > > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "zotero-dev" group. > To post to this group, send email to zotero-dev@googlegroups.com. > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/zotero-dev?hl=en.
> Pushed general eLibrary, tested on PSU, Rice, USC. Doesn't run on
> Rutgers, so I kept the separate IRIS translator for now.
> Sorry for the delay and thanks for your hard work on this one!
> Avram
> On Thu, Jan 26, 2012 at 12:02 PM, jouchida <jouch...@gmail.com> wrote:
> > Never mind my last comment on MARC data -- it's not an import
> > function, and the same code exists in the updated translator.
> > On Jan 26, 11:24 am, jouchida <jouch...@gmail.com> wrote:
> >> Hi,
> >> I wonder if any progress has been made on this translator. We have
> >> received many patron inquiries about Zotero-compatibility since we
> >> upgraded to eLibrary, and we've been offering our translator as a
> >> local download.
> >> Re MARC data: looking at the original Zotero translator for Sirsi
> >> (Library Catalog (SIRSI).js), there is an import function that uses
> >> some URL to get MARC data. I will follow up with Sirsi support and try
> >> to get more specific details about it.
> >> Thanks for your help,
> >> Joyce
> >> On Jan 12, 10:49 am, jouchida <jouch...@gmail.com> wrote:
> >> > As far as I and my colleagues know, that is the only way to get MARC
> >> > data through the OPAC: Display Options --> unformatted display -->
> >> > All. I think All is more complete than Full.
> >> > --Joyce
> >> > On Jan 11, 9:41 pm, Avram Lyon <ajl...@gmail.com> wrote:
> >> > > Joyce,
> >> > > I want to clean up the code some before rolling this out, in part to
> >> > > ease future troubleshooting and in part to make it possible to add
> >> > > support for other e-Library installs that it doesn't currently
> >> > > support. I would be very interested in making the translator continue
> >> > > using MARC data, since our current approach of using natural language
> >> > > labels in the interface will break down very quickly internationally.
> >> > > Can you, your local SirsiDynix specialists, or anyone else on the list
> >> > > say whether there's a way to get MARC data through the OPAC without
> >> > > going to Display Options --> unformatted display --> Full Record?
> >> > > Doing this through scraping alone isn't going to cut it, I'm afraid.
> >> > > I can redirect my question to code4lib if need be.
> >> > > Avram
> >> > > On Wed, Jan 11, 2012 at 5:57 PM, jouchida <jouch...@gmail.com> wrote:
> >> > > > Hi,
> >> > > > The code is essentially the same as Rice University's translator (so I
> >> > > > kept the creator the same), but I've genericized the regex, the
> >> > > > priority code, and some branded values within the javascript. I didn't
> >> > > > edit the detectWeb code, it seemed to already be working fine. I've
> >> > > > tested on Sirsi sites (as listed under Unicorn on this page:
> >> > > >http://www.librarytechnology.org/arl.pl) and confirmed that both pre-
> >> > > > eLibrary and eLibrary sites are zotero-enabled, with some exceptions
> >> > > > due perhaps to template customizations by the institution. eLibrary
> >> > > > sites that are not currently zotero-enabled become zotero-enabled when
> >> > > > this translator is installed locally.
> >> > > > Also, the 2 existing eLibrary translators for Rice U. & IRIS seem to
> >> > > > take precedence over this translator, which is fine since I don't want
> >> > > > to mess with their connectors.
> >> > > > Anyway, as far as I can tell, this should work for Sirsi eLibrary
> >> > > > catalogs and not break other Sirsi connectors. Let me know if there
> >> > > > are any issues. I'm a zotero newbie so I might have missed something.
> >> > > > --Joyce
> >> > > > On Jan 7, 7:11 pm, Avram Lyon <ajl...@gmail.com> wrote:
> >> > > >> On Sat, Jan 7, 2012 at 9:23 AM, adamsmith <bst...@gmx.de> wrote:
> >> > > >> > Obviously working through the target regexp for the URL is preferable
> >> > > >> > (i.e. less resource intensive), but if that's not possible yes,
> >> > > >> > starting with the eLibrary-Sirsi and falling back to regular Sirsi
> >> > > >> > should work as long as the detect function for eLibrary-Sirsi will
> >> > > >> > return false for regular Sirsi catalogs. It needs to fail at the
> >> > > >> > detect level, though, not during the actual import.
> >> > > >> I'd be happy to see this as a fallback during detection. Just try to
> >> > > >> make the eLibrary-Sirsi detectWeb return false as quickly as possible
> >> > > >> for non-eLibrary installs.
> >> > > >> Joyce, would you feel comfortable taking this on and doing a little
> >> > > >> testing on eLibrary and non-eLibrary sites?
> >> > > >> Avram
> >> > > >> > Are we reasonably sure that's the case? Does someone have a couple of
> >> > > >> > examples of old fashioned SIRSI?
> >> > > >> > Sebastian
> >> > > >> > On Jan 6, 12:46 pm, jouchida <jouch...@gmail.com> wrote:
> >> > > >> >> Hi Avram,
> >> > > >> >> Yes, I think this translator should work for Sirsi installations that
> >> > > >> >> use the eLibrary OPAC templates. The problem is that I don't think
> >> > > >> >> there is a way to specifically identify eLibrary installations vs.
> >> > > >> >> earlier Sirsi templates (that use translator Library Catalog
> >> > > >> >> (SIRSI).js) just by the URL. If we assign a lower priority number to
> >> > > >> >> the eLibrary translator and item metadata is not found, does Zotero
> >> > > >> >> fall back to the next higher priority number translator that matches?
> >> > > >> >> In that case, the same regex target can be used for both translators.
> >> > > >> >> Or do you have other suggestions?
> >> > > >> >> --Joyce
> >> > > >> >> On Jan 4, 1:21 pm, Avram Lyon <ajl...@gmail.com> wrote:
> >> > > >> >> > Joyce,
> >> > > >> >> > Since this translator is just a copy of the Rice modifications of the
> >> > > >> >> > SIRSI translator, it would be best to just modify the Rice translator
> >> > > >> >> > to support both catalogs. And if this translator can be expected to
> >> > > >> >> > work out-of-the-box for more sites than USC and Rice, the right action
> >> > > >> >> > to take at this point is to find ways to identify such SIRSI
> >> > > >> >> > installations and run this modified version on all of them.
> >> > > >> >> > Are you using a particular version or module for SIRSI that requires
> >> > > >> >> > these changes? We'd like to stay away from single-library
> >> > > >> >> > modifications when a single translator would work, since the former is
> >> > > >> >> > a maintenance nightmare.
> >> > > >> >> > Thanks for working on this-- I look forward to getting this out!
> >> > > >> >> > Avram
> >> > > >> >> > On Wed, Jan 4, 2012 at 11:25 AM, jouchida <jouch...@gmail.com> wrote:
> >> > > >> >> > > Hi, we'd like to submit this translator for the USC Libraries catalog.
> >> > > >> >> > > --
> >> > > >> >> > > You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> >> > > >> >> > > To post to this group, send email to zotero-dev@googlegroups.com.
> >> > > >> >> > > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com.
> >> > > >> >> > > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
> >> > > >> > --
> >> > > >> > You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> >> > > >> > To post to this group, send email to zotero-dev@googlegroups.com.
> >> > > >> > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com.
> >> > > >> > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
> >> > > > --
> >> > > > You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> >> > > > To post to this group, send email to zotero-dev@googlegroups.com.
> >> > > > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com.
> >> > > > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
> > --
> > You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> > To post to this group, send email to zotero-dev@googlegroups.com.
> > To unsubscribe from this group, send email to zotero-dev+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/zotero-dev?hl=en.
