On Thu, Nov 3, 2011 at 12:43 PM, Sylvester Keil <[email protected]> wrote: > > On Nov 3, 2011, at 1:33 PM, Frank Bennett wrote: > >> On Thu, Nov 3, 2011 at 9:21 AM, Sylvester Keil <[email protected]> wrote: >>> Dear all, >>> >>> I was just reading up on multi-lingual content support in citeproc/json >>> items and was wondering about the feature's current status? How far >>> advanced is it as far as citeproc-js and citeproc-hs are concerned? The >>> manual describes a syntax using 'multi' and '_keys' hashes, for example: >>> >>> { "title" : "民法", >>> "multi": { >>> "_keys": { >>> "title": { >>> "ja-alalc97": "Minpō", >>> "en":"Civil Code" >>> } >>> } >>> } >>> } >>> >>> What is the rationale for using the '_keys' hash in this case? Are there >>> other possible elements in 'multi' or could't we use one top-level property >>> ('multi') that directly contains locale keys, which, in turn, contain the >>> transliterations/translations? >>> >>> Thanks! >>> >>> Sylvester >> >> Sylvester, >> >> Thanks for looking at that! The functionality is running smoothly in >> multilingual Zotero, and the internal data layout has been stable for >> several months. I should make a trawl through the documentation >> sometime to be sure it reflects the current state of the code, though. >> >> It's not yet used, apparently, but there is a possibility that >> citeproc-js might reference a "main" key ("main") on the "multi" >> object, to allow the explicit per-field declaration of the language of >> the headline field content: >> >> multi: { >> "_keys": { >> "title": { >> "en": "I Am a Cat" >> } >> }, >> "main": { >> "title": "ja" >> } >> } >> >> This ("main") *is* used on creator objects, which have a slightly >> different structure (without the field key). On creators, the >> processor check "main" in one function, to identify names explicitly >> declared as Vietnamese. That was introduced because heuristics to >> identify Vietnamese names from field content are, well, heuristic. We >> needed an explicit flag (which can be set in multilingual Zotero) to >> peg the content as Vietnamese for certainty, where that's required. >> >> It's probably best to keep the extra layer in place on both versions >> of the multi object, just in case. > > Fair enough. Thanks for clarifying that! > > By the way, you may be interested to know that I managed to embed trace > monkey into current versions of Ruby (it had been working for older versions > previously), and I'm now in the process of moving the citeproc/json API into > a separate package so that we can use the library with either the JS or Ruby > version (I'll really want to add support for the Haskell version, too, if > only to combine two of my favorite languages). Anyway, so far, citeproc-js is > blazingly fast in trace monkey and I have not encountered any problems so > far. I hope this will hold true once I run more taxing tests on the processor! > > Best, > > Sylvester
This is great to hear. I had tracemonkey working in my little test framework here until a few months ago, using a wrapper from the jslibs project. When I upgraded Ubuntu on my netbook it failed to compile, though, and I haven't gotten around to sorting that out. Rhino is quite a bit slower, and with the test suite growing in size, now is probably a good time to see if I can get it working again. For a performance torture test, disambiguate YearSuffixFiftyTwoEntries is a good one for jumping in at the deep end: https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/disambiguate_YearSuffixFiftyTwoEntries.txt Frank > > > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > xbiblio-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel > ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
