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 ------------------------------------------------------------------------------ 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
