I wonder if you could do it in Solr itself, instead of SolrMarc? As an
input filter (I forget the exact technical language for this, but
there's something you can set to do this task in Solr); which you don't
need to get it built into the Solr distro to do, Solr allows you to have
your own custom plugins like this in the lib directory, and specify in
them in the schema.xml and such. I think. Just a brainstorming idea,
don't know enough details about Solr to know if it would work well for
sure. But if it would, I wonder if putting it configuration in Solr
itself is preferable to SolrMarc, for wider sharing/utility of code with
anyone using Solr but not neccesarily using SolrMarc.
Bess Sadler wrote:
By sending this here I hope I'm going to hit everyone on the
blacklight, vufind, and solrmarc mailing lists, and maybe some other
interested parties.
Our East Asian Languages Librarian has approached me with a problem he
wants to see solved. According to him, the typical North American
library cataloging rules for constructing Pinyin transliterations are
different from the rules that are used in China. What this means is
that native Chinese speakers have a lot of trouble searching our
catalog (it is "practically unusable" was his exact quote). His
proposal, and I think it's a good one, is that since we're re-indexing
our records into solr anyway, we could apply at index time an
algorithm to convert North American Pinyin to Chinese rules Pinyin,
index both values, and thus make the catalog much more useful to an
under-served population. This seems like a great suggestion to me, but
before I start devoting development cycles to it I wanted to poll the
community... is there a more obvious answer that I'm not seeing? Has
anyone solved this already?
What's the right place for such a piece of code? Solrmarc seems the
obvious place to me. As it has been described to me so far, this
doesn't seem like an issue affecting people outside the library realm,
which makes it seem too niche and community-specific to get it built
into the lucene codebase, but I could be wrong about that. Maybe it
would be better as a lucene contrib library?
So, thoughts? Anyone know more about this than I do and want to speak up?
Thanks!
Bess
