There is a way, but it is (as yet) non-standard (the CSL will not validate against the CSL 1.0 schema). Whether it qualifies as simple is a matter of opinion. :)

The syntax is documented here. I'm working on more detailed documentation of this and other features available in the experimental multilingual client, for inclusion in a book (draft text available here), but I won't get to the multilingual stuff for at least another month.

If it's only a few references, you're probably best off hand-editing in the final edit for the present.

It's triggered by the "language" variable on the item, or alternatively by the default language of the style if the variable is empty. The examples under the link show how it works; you would move the content of the layout to a macro (if all you're changing is the terms, you can use the same macro for all languages), and then define multiple layouts, giving the macro as the sole content of each. Each layout but the last has a locale attribute, containing the ISO codes of the CSL-supported languages to be applied. I guess you would be defining an "en" layout, falling back to Swedish, and with the default-locale of the style set to Swedish.

If none of that makes much sense, you're probably safer waiting until this is a little closer to showtime (!).

@maras,

I'll be happy to look at your style, and fix any problems that turn up in testing. Can you paste the code of your style to http://gist.github.com, save it as a public gist, and post the URL from the address bar back here?

I tried to remove default locale in both documents

<locale>
<terms>
<term name="accessed">žiūrėta</term>
<term name="online">interaktyvus</term>
</terms>
</locale>

but result the same.

I fixed style, but it is not validating. Errors are about locales, as I can understand:
Error: Attribute locale not allowed on element layout from namespace http://purl.org/net/xbiblio/csl at this point.

From line 779, column 5; to line 779, column 60

rue">↩ <layout prefix="" suffix="." delimiter="; " locale="lt">↩

Error: Element layout from namespace http://purl.org/net/xbiblio/csl not allowed as child of element citation from namespace http://purl.org/net/xbiblio/csl in this context. (Suppressing further errors from this subtree.)

From line 815, column 4; to line 815, column 60

ayout>↩ <layout prefix="" suffix="." delimiter="; " locale="en">↩

Error: Element layout from namespace http://purl.org/net/xbiblio/csl not allowed as child of element citation from namespace http://purl.org/net/xbiblio/csl in this context. (Suppressing further errors from this subtree.)

From line 851, column 5; to line 851, column 60

yout>↩ <layout prefix="" suffix="." delimiter="; " locale="ru">↩

Error: Element layout from namespace http://purl.org/net/xbiblio/csl not allowed as child of element citation from namespace http://purl.org/net/xbiblio/csl in this context. (Suppressing further errors from this subtree.)

From line 887, column 5; to line 887, column 48

yout>↩ <layout prefix="" suffix="." delimiter="; ">↩

Error: Attribute locale not allowed on element layout from namespace http://purl.org/net/xbiblio/csl at this point.

From line 929, column 5; to line 929, column 35

sort>↩ <layout suffix="." locale="lt">↩

Error: Element layout from namespace http://purl.org/net/xbiblio/csl not allowed as child of element bibliography from namespace http://purl.org/net/xbiblio/csl in this context. (Suppressing further errors from this subtree.)

From line 948, column 5; to line 948, column 35

yout>↩ <layout suffix="." locale="en">↩

Error: Element layout from namespace http://purl.org/net/xbiblio/csl not allowed as child of element bibliography from namespace http://purl.org/net/xbiblio/csl in this context. (Suppressing further errors from this subtree.)

From line 967, column 5; to line 967, column 35

yout>↩ <layout suffix="." locale="ru">↩

Error: Element layout from namespace http://purl.org/net/xbiblio/csl not allowed as child of element bibliography from namespace http://purl.org/net/xbiblio/csl in this context. (Suppressing further errors from this subtree.)

From line 986, column 5; to line 986, column 23

yout>↩ <layout suffix=".">↩

There is "fixed" style: git://gist.github.com/3316761.git

Now Lithuanian terms disappeared completely. I set default locale to ru, lt and en. Terms are English all the time in Lithuanian and English references, but Russian terms all the time in Russian references. Changing default locale changes nothing.

Actually, if you're willing to translate the CSL locale file to Lithuanian, please use https://github.com/citation-style-language/locales/blob/1.0.1/locales-en-US.xml as the starting point. We have some translation instructions here: https://github.com/citation-style-language/locales/wiki/Translation-Instructions

It should be enough to paste the locale to http://gist.github.com, as you have done with your styles.

For the multiple language layout issue, I did some testing and found that undefined locales (i.e. a locale defined inside the style, but absent from the CSL locale set) are recognised by the processor. There was a bug, however, that could cause selection of the incorrect locale for some items. I've fixed the bug, and released an updated version of the citeproc-js CSL processor. The simplest way to test with it is to install this plugin, which replaces the CSL processor in Zotero with the latest version.

If you will be producing documents that span language boundaries, you might take a look at MLZ (Multilingual Zotero). This is a personal project of my own, that (among other things) allows flexible inclusion of translations and transliterations in printed citations. MLZ is not supported by the core Zotero team, and you will want to back up your Zotero database and other files before installing, but it may be useful in your environment.

I've installed plugin. No changes - English terms in Lithuanian and English references and all good with Russian ones.
Maybe it is due bad construction of my style? It is the same as there: https://gist.github.com/3316761 I only removed default-locale.

There is a draft of lt_LT locale for CSL: git://gist.github.com/3318667.git Maybe better is to create another thread with questions about it?

Yes, please. (and it's slightly handier for us if you copy/paste the URL from the address bar, like https://gist.github.com/3318667, instead of git://gist.github.com/3318667.git )

@maras: We owe you a round of applause.

The Lithuanian terms in your style were not turning up due to a processor bug that caused locale nodes with specific xml:lang attributes to be masked in all styles, in both official Zotero and in MLZ. This must have been confusing to many style authors, and I'm very glad get it fixed.

If you update MLZ to the latest (m225), you should find that your style works as expected. For completeness, you might want to add all of the relevant nodes (style-options, date, and terms) from the locale you have prepared to the style, until your locale makes its way into a CSL release.

Let me know if you run into any more snags; but I think the tool will start doing its job for you now.

(Edit: If you haven't yet made major changes to the Chicago Fullnote style on which you're basing your work, you might take a look at the MLZ Chicago Fullnote style as an alternative. It validates against the MLZ extended CSL schema, which permits the multiple layout syntax. Validation works in the same way as for official CSL, but using the alternative schema. (I'll be reorganising the schema source soon, but that repo address will always contain the multilingual version.)

It definitely tests correctly here. It's late here, I'll be going to bed. If you can paste a style that fails for you, and data that fails with it (exported as Zotero RDF), I'll see if I can reproduce the behaviour you describe tomorrow morning.

The style is throwing some English terms in the Lithuanian locale because the Lithuanian term set defined in the style is incomplete, and English is used as an ultimate fallback. Here is a version that includes all of your defined locale terms, which seems to work normally: https://gist.github.com/3328311

Validation against the MLZ extended CSL schema is a little awkward at present. I'll try to set up an easy validation channel sometime fairly soon, but you should be good with the style above for now.

(Edit: I made one small set of changes to the processor, to handle the switching of punctuation-in-quotes behaviour across locales in a multi-layout style. You can pick up the changes by updating MLZ.)

Well, now all terms in Lithuanian AND English references are... Lithuanian. I even pasted all en_US locale to en locale of style, but no effect at all. And all OK with Russian references.
I upgraded MLZ.

There were some issues with the style file - bigger half of it was red when opened in Gedit. Because some remarks (in <!-- -->) maybe broke the code itself (apostrophe in "don't"). I don't know how this affected code. But there was no changes after I corrected that.

I think, that these problems will vanish after Lithuanian locale adding to Zotero. But there is languages without locales and it is not good if such a problem will continue.

Or problem is with my style.
How my style, modified by you, behaves with English references?

Now I am going to bed :).

Here's what I get with those references and the style I linked above:

http://img805.imageshack.us/img805/816/mixedlocales.png

That's all correct, I think.

Be sure that the language attribute in the locale nodes is set with xml:lang=, and not with plain lang=. The latter is not recognized, so that node would become the fallback. If a locale node in the style was set to <locale lang="lt"> with a full Lithuanian set of terms inside, that would produce the behaviour you describe (i.e. Lithuanian everywhere, unless overridden). But that's just a guess.

For final debugging, I'll need to see exactly what you are using for the style and for the entries for a specific error. The major wrinkles have all been ironed out, as far as I can tell; the problems are almost certainly with the input, and I'll need to see it directly in order to track down the cause of odd behaviour.

(Edit: we crossed in the post -- response below.)

With default-locale="ru", I do get bad output here, with Lithuanian terms in an English entry. This absolutely should not happen. I'll take a look. With luck you'll find it's fixed tomorrow morning.