citeproc/json multi-lingual content

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

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

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