Upgrade Storage[Multilingual] Zotero fields and CSL variables
Most of Zotero fields (authors, title, date, etc.) are exposed as CSL variables, so the style can process them. However, "Language" field doesn't seem to have an equivalent variable. Is it possible to expose it?
This would allow style to detect the languages of a particular bibliography item and to process it accordingly. In effect, the locale can be set per item as opposed to per bibliography. Russian standard seems to require this behavior.
However, if we consider "Language" field as "What language is this book in?", then it would be probably better to create a new "Locale" ("How should this item be formatted?") field in Zotero and expose it as "itemlocale" through CSL.
P.S. May be this should be posted to Feature Request.
This would allow style to detect the languages of a particular bibliography item and to process it accordingly. In effect, the locale can be set per item as opposed to per bibliography. Russian standard seems to require this behavior.
However, if we consider "Language" field as "What language is this book in?", then it would be probably better to create a new "Locale" ("How should this item be formatted?") field in Zotero and expose it as "itemlocale" through CSL.
P.S. May be this should be posted to Feature Request.
Could't add the first tag for a while, only right click on the language name worked, now adding works as expected. However, I can't remove "ru" tag, don't know why. Add and removing all other tags works fine.
Now I am going to hack my style file. MLZ can tag almost every field, while both test seem to use "Language" filed. The first approach is much more flexible, but requires all the fields to be tagged.
Can I just use <layout locale="lang1"> ... </layout> <layout locale="lang2"> ... </layout> inside bibliography section, so that different layouts fire on different languages without tagging all the fields?
Thank you!
On the last point, yes, that's the way it's set up currently -- it's a "big hammer" approach, that replaces the entire layout. A more refined approach would only replace locale terms, where that is sufficient to handle the content, but that's for a future extension to the experiment.
I'm delighted that you've picked up the multilingual branch code for trials, but can I ask that the title of this thread be prefixed with "[Multilingual]", to avoid possible misunderstanding about the status of this variant of Zotero and CSL?
I suspect that while "locale per bibliography" is too coarse, not many people really need "locale per field" control.
I have checked out https://www.zotero.org/svn/extension/branches/trunk-multilingual but can't build currently. Does it makes sense to work with HEAD revision and build it myself? If so, then where should I post build-related comments?
My box is running FreeBSD 7.4-STABLE. The 1st problem was with the 1st line :) I changed it to
#!/usr/bin/local/bashas a quick-and-dirty solution. If the script doesn't use bash-specific features,#!/bin/shis a better option.Right now it dies with the following message
adding: chrome.manifest (deflated 76%)
adding: COPYING (deflated 65%)
adding: deleted.txt (deflated 36%)
zip warning: name not matched: install.rdf
zip error: Nothing to do! (zotero-multi-2.xpi)
It seems that install.rdf is missing from SVN.
Hope this will help you. If you are interested, I can test the build script on OSX.
Thank you!
1) re "Can't delete ru tag" -- turned out I had the "Citations and bibliographies/Sorting" checkbox checked, so it's a feature actually.
2) MLZ seems to use en dash instead of hyphen. 50% of my problems are solved :)
3)However, bibliography with different locales do not work for me. This is my test bibliography code:
<bibliography et-al-min="4" et-al-use-first="1"
entry-spacing="0" second-field-align="flush">
<layout suffix=".">
<text value="cite-gen"/>
</layout>
<layout locale="en" suffix=".">
<text value="cite-en"/>
</layout>
<layout locale="ru" suffix=".">
<text value="cite-ru"/>
</layout>
</bibliography>
I have two items, the first one has Language=ru, the second -- "Language=en" (as seen in Zotero interface). The output looks like this:
cite-gen.
cite-gen. cite-en
So it seems that without locale fire on both items (that is logical), fires on the second item (as it should), but somehow doesn't fire. Any ideas what should I check/test?
Thank you!
(Edit: What you should get is just one "cite-*" output string per cite, with "cite-gen" firing where no language or an unlisted language is specified on the item "language" attribute, and "cite-ru" firing on the language-"ru" item.)
<bibliography et-al-min="4" et-al-use-first="1"
entry-spacing="0" second-field-align="flush">
<layout locale="en" suffix=".">
<text value="cite-en"/>
</layout>
<layout locale="ru" suffix=".">
<text value="cite-ru"/>
</layout>
<!-- <layout suffix=".">
<text value="cite-gen"/>
</layout> -->
</bibliography>
then changing to that style gives me an error: "Zotero experienced an error updating your document. this.output.queue[0] is underfined".
If I uncomment it:
<bibliography et-al-min="4" et-al-use-first="1"
entry-spacing="0" second-field-align="flush">
<layout locale="en" suffix=".">
<text value="cite-en"/>
</layout>
<layout locale="ru" suffix=".">
<text value="cite-ru"/>
</layout>
<layout suffix=".">
<text value="cite-gen"/>
</layout>
</bibliography>
then I can (usually) change to this style, but the last part doesn't fire at all.
Is this expected behavior? It used to confuse me, but it makes sense to require default handler.
One more question concerning 's wrapped in . They are affected by language (i.e. the appropriate one is called, as far as I can see from the first example, but when is the language set? I.e., if I call a macro from without locale, will the with current item locale called?
Thank you!
Sorry, if my questions sound too vague :(
Currently, terms only follow the item locale if the locale set on one of the cs:layout nodes matches. If there is no match, terms from the style default locale will be used. We have talked about making this a little smarter (so that terms from the item locale can be used in the default layout), but for the time being, you need an explicit layout for each locale.
Anyway, MLZ seems to be pretty stable, so I believe its needs more exposure :) Thank you very much, and I'll glad to help: additional testing, manual writing, may be some boilerplate code (I am not a software developer but tend to know how things work), etc. Feel free to contact me!
The documentation situation does need to be addressed. I'll study git a bit more, and see if I can set up a schema for validating multilingual styles. Once that's in place, I should be ready to provide some documentation.
Thanks for your patience. Very glad to hear that it's worked for you.
(I noticed this morning that the site serving the multilingual client (gsl-nagoya-u.net) is down. I'll be calling the hosting service shortly when their help counter opens -- I think it's a problem with our DNS records, which we've been managing on a separate server. With luck we'll have it hooked up to the Internet again fairly soon.)
Update: 203.105.81.135 seems to be down, so it looks like the problem is not DNS.
(On our server issue, this turns out not to be a problem in our DNS. Line was busy when I called at help-counter opening time, and a refresh of the support page now shows a report of service outage. It's one for the hosting service to sort out now ...)
Unfortunately, formatting is lost if I paste it, so grab it here.
P.S. My English is far from perfect, so feel free to edit.
By the way, it looks like I found a bug in MLZ, what is the best way to report it?