I think, I found what is going on.
default-locale must be set accordingly to how layouts are lined up in citations and bibliography, how to say, nodes.
1st style, where default locale should be lt. Layouts were in such order (from top, to down): en, ru, lt.
2nd style (default locale should be en). Order: lt, en, ru.
So, default locale must be that of layout above layout without locale. But not ru. Setting ru locale changes nothing or creates bad output. Maybe that is cause of such inaction of ru locale?
(Edited. One more style with order: en, ru, lt, default locale must be lt.)
Thanks for your work and feedback. It's useful to know that sequence can change things. According to the CSL specification it shouldn't matter, though, so this needs to be fixed in the processor. I should have a solution in a few hours.
(Edit: the spec link in this post is off the point: I misread, and assumed you were talking about sequence of the cs:locale nodes, not cs:layout. The fault has been fixed, though; see below.)
And something is wrong (or good) with Russian layout/locale - changing its position changes nothing. But sometimes it creates bad output.
One more experiment. I changed order only in one section of style - bibliography. So order in bibliography: lt, en, ru; order in citation: en, lt, ru.
Default locale - lt. Lithuanian reference - Lithuanian terms are everywhere. English reference - Lithuanian terms in bibliography, English - in citation.
Default locale - en: all vice versa.
Russian in both cases - OK.
If you update, I think you'll get better results, again. The sequence of the cs:locale declarations doesn't matter. The sequence of cs:layout + xml:lang declarations should also now be irrelevant, with two exceptions: (1) the final layout should have no xml:lang attribute; and (2) if you are matching variants of the same language (such as zh and zh-TW), the more specific variant should be above the less specific one.
The cause of this most recent (and hopefully final) fault was that it was retrying for a match between the item language fallback locale and the list of available locales, rather than against the one-element version of the item locale and those available. The fallback for "lt" (and any other non-standard locale) is "en-US", which is always available, so it was finding a match as soon as it hit that cs:layout node, and that was very wrong indeed.
m227 now.
Results the same. I used the last example with different order of layouts in bibliography and citation (order in bibliography: lt, en, ru; order in citation: en, lt, ru).
So:
locale en: all good with en and ru references, but lt references are with Lithuanian terms only in bibliography.
locale ru: all OK with ru, lt and en references with lt terms in bibliography.
without locale: same as with locale ru
locale lt: all good with ru and lt references, Lithuanian terms in en bibliography.
(Edit. Other style with alike order in bibliography and citation had correct terms only with "correct" default locale.
Edit 2. I didn't touch order of locales, only order of layouts in bibliography and citation [nodes?]. And sorry for my English - it isn't good indeed. :))
@maras: Good news, I have a failure. Citations are assigning the correct locale, but I can confirm the behaviour you describe in bibliographies. This gives me enough to investigate; you don't need to send style code and item exports. More soon ...
Well, situation is the same: http://imageshack.us/g/827/20120812235618.png/ English reference. Terms are correct only with en layout (it is on the bottom of layouts). And there is no difference between citations and bibliography.
Maybe it's not a bug, but a feature, as layout without locale, that must be on the bottom. As for me this situation is not bad at all.
Only one thing should be done - short instructions should be written about creation of multilingual styles with warning about order of layouts.
But something isn't good, because Russian layout isn't working as default. Maybe it's fault of Russian locale.
I can send you styles and examples, but this situation is with all my multilingual styles.
By the way, this tool: http://steveridout.com/csl/visualEditor/ always cuts out "xml:" from all locale names. I've send bug report.
(Edit. I think, Russian layout is working because Cyrillic of it - there is no other fallback, only one Cyrillic style.
One more idea. My MLZ locale - en_US, but "general.useragent.locale" of Firefox - lt. Maybe this creates mess of languages to processor.)
In csledit.xul and in documents, I'm getting consistent and correct results for all combinations, including those with no default locale, and with default-locale="lt", and with general.useragent.locale set to "lt".
Entries with no locale or an invalid locale are rendering in the default language, and valid language codes on an item force its terms and formatting to that locale. I can't produce output like that in your screenshots with the current MLZ version.
It's likely that there is a problem with your input. Please post your item data and the exact style code that you are using for testing to http://gist.github.com, and I'll take a look.
The editor at http://steveridout.com/csl/visualEditor/ will not (yet) work with MLZ styles by default, because it relies on the official CSL 1.0 schema. The developer has set up a means of configuring the editor to work with MLZ styles, but there are some bugs that need to be worked out before it's ready for use.
There will be documentation, and soon. I'm working on a book about MLZ, and multilingual layouts will be described there -- so I'm particularly keen to see that it's working correctly!
Maybe this is my fault - I only beginner in writing styles.
There is the same style as in screenshots: https://gist.github.com/3334891 All is OK with default locale en, but not lt or ru - Lithuanian terms then dominates in English references (not editor - it isn't translated here). There is only few terms described in lt locale. But I think, such a situation better reflects situation of ordinary user that can't create own locale for language.
There is the same reference as in screenshots: https://gist.github.com/3334921
Here's a thought: have you uninstalled or disabled the Zotero Processor plugin? If not, disable it; it is not needed with MLZ, and unless it is upgraded as well, it will replace the (newer) processor in MLZ with the older version embedded in the processor plugin.
Yes, you were absolutely right. All the problems gone after uninstalling Zotero processor gadget. At last!
Sorry for troubles.
And I think, that last bug you found because my complaints, was not the same as those, about which I was complaining :). But bugs were real, so not so bad.
Thank you very much for assistance and help.
Is MLZ updating automatically via Firefox or I must do it manually via your site?
Now third (and most complicated) stage of transition from EndNote to Zotero is before me - create styles that suits my needs. They should be humanitarian ones and that means - very complicated.
Yay! Thank you for patiently navigating the undocumented forest. We were indeed speaking at cross-purposes, but we were both listening, and that's what counts. :-)
I'm not sure if MLZ updates automatically. I think it does, but the "Find updates" item in the Tools -> Add-ons -> Extensions -> MLZ context menu certainly does work.
When I get a make-easy validation engine in place for MLZ styles, I'll post back to this thread. Meanwhile, don't hesitate to write again if you have problems.
I've almost wrote my multilingual style (it validates), but Lithuanian localization is working quite strange for me. Date style is not Lithuanian, but English and so on. Date style became Lithuanian only after inserting all Lithuanian locale to my style.
Is Lithuanian locale working in Zotero? Rintze added it to repository: http://forums.zotero.org/discussion/24804/some-csl-lithuanian-locale-translation-problems/#Item_17 My MLZ version - 232.
And one more strange thing. Ordinals became Lithuanian even in English references after insertion of Lithuanian locale to style. So edition isn't "2nd", but "2asis".
I'll need to reproduce what you see locally. Please post the style, the items you are using for testing, and tell me how the test document is laid out (sequence of items cited), and where to look for problems (whether anomalies affect citations or bibliography or both).
This is style: https://gist.github.com/3435283
This is reference no. 1: https://gist.github.com/3435300 (style of date incorrect)
This is reference no. 2: https://gist.github.com/3435337 (edition term is incorrect - English "ed." and ordinal "2nd" instead Lithuanian "leid." and "2asis").
All Lithuanian terms disappears from reference after removing all but one term from locale xml:lang="lt" section
That affects both citation and bibliography.
I am testing in Zotero CSL editor - there I can change language of reference, sequence of items and modify style itself quickly. I am citing documents as "first". But removing term "volume" from Lithuanian locale section affects both first and subsequent sequence of book (from "t." to "vol."). The same things are happening to the LibreOffice Writer citations.
The Lithuanian locale has not yet appeared in official Zotero, and I hadn't yet added it to MLZ either. I've just issued an MLZ revision that contains the new locale, so if you update, you should find things work correctly, with or without Lithuanian terms in the style itself.
The style code is not valid, but the syntax errors do not affect processing with citeproc-js. The main problem, which puzzled me at first, is in the date nodes. You have given these date-parts and form attributes. In that case, the date-part subnodes are ignored, and the locale code is used instead. You can just eliminate the subnodes. A copy of the style with these changes is here.
There are a few other issues with validation under the MLZ extended CSL schema. Number variables must always be rendered as number, not text; and spaces are not allowed in prefix and affix. Fixing these issues will take a lot of work, and possibly some rewriting of the style. The processor will run the style in its current form, though, so I would just use it as-is, until full documentation on the MLZ schema is available, and you have time for the editing.
I don't see any changes after updating MLZ. But it doesn't matter if that will be corrected after adding Lithuanian locale to Zotero. I think, you have more important tasks with Zotero than work with one locale :).
And how I can know is there Lithuanian locale added to Zotero or not? Where is this written?
Thank you for correcting my style :).
I am new to xml and to coding itself, so this was hard task to me to heavily modify an existing style to my needs. The official documentation is too complicated and time consuming to read and understand. So I feel myself as half illiterate when modifying style, copying from several styles to my style parts that suited my needs etc. :). But I think, that I managed to understand logic of CSL language (and xml itself) after some amount of such manipulations. Obviously that I dosen't know a lot of little things about CSL (as about date-parts). But my task is only to write some styles for myself, not to became specialist of CSL.
So I copied from Chicago Manual or Modern Humanities styles such a things as number variables as text. I'll correct that.
Is my understanding right, that some things that are correct in usual CSL schema, aren't correct in MLZ extended one?
It is quite easy to correct number variables. But I don't have any idea how to write correct style for my needs without spaces in prefix and affix. By the way, prefix " ." [space and dot] is correct or not?
(Edited. And I think, that most urgent thing is to create MLZ extended CSL schema validator (as validator.nu). When it points to the mistake it is more easy to understand the mistake and correct it than search for the mistake in the rather complicated documentation. This is correct for noobs, of course :)).
You are right. The MLZ update is definitely up, and the CSL locale is in there, but it isn't used because Firefox does not have a Lithuanian locale, and the CSL locale list (in MLZ, at least) is a filtered version of the Firefox list of available locales. I'll need to fix this. I have to run now, but it will happen within a week at the latest.
Setting up a validator for the extended schema is a high priority. I have all the necessary pieces, but I'll need to find some quiet time to set it all up.
MLZ version m235 (just up) should finally do it for you. It includes your latest revisions to the date format in the Lithuanian locale, and I have tested it with your style minus the lt locale terms.
The validator will take some weeks more.
(I will be out of contact for a couple of days, in connection with some upcoming air travel.)
Ordinals depends on default locale, not on language of reference. So edition is "2nd" even when reference is Lithuanian or Russian but locale - en, and, accordingly, when locale - ru, edition is "2й" with Lithuanian and English references; when locale - lt, edition is always "2-asis" despite language of reference.
This is with my style with your corrections and with that reference: https://gist.github.com/3435337 (all other references are affected too where edition is listed). All other terms are correct, as I see.
The same is happening with MLZ CMS style.
@arggem People have less and less quiet time for themselves in our times.
(Edited. This situation suggested me one thought. What if do such thing for some items in reference? For example, terms "accessed", "internet" and "online", form of date accessed must be in Lithuanian despite what is language of reference (when language of text is Lithuanian of course). There are quite simple to change some terms that should be all the time, lets say, Lithuanian in references via locale without xml indication. But there isn't possibility to change form of date in one part of reference without changing form of dates in other parts of reference. I saw such a request to French references there: http://forums.zotero.org/discussion/24999/problem-with-locales/ And it was about date of access too. So maybe is it possible to do that thing in MLZ - bind form of date of access to default locale of style, not to language of reference? I think, that such requirements for forms of date accessed are universal in all languages. Such is my thought and proposal that came out of a bug :). That would be nice feature, I think, if it is possible.)
Thanks for pointing out the issue with ordinals. I'll try to take a look soon.
Tying accessed date to the default locale is an interesting idea. I'll take a look at implementing that also, and we'll see if anyone complains.
(Edit: For ordinals, a glance at the code turned up the problem. There is a proposal for enhanced ordinals support on the table, though, which I would like to implement. I think it might make sense to put in a little more time on this, and fix both problems in one go.)
Upgrade Storage
default-locale must be set accordingly to how layouts are lined up in citations and bibliography, how to say, nodes.
1st style, where default locale should be lt. Layouts were in such order (from top, to down): en, ru, lt.
2nd style (default locale should be en). Order: lt, en, ru.
So, default locale must be that of layout above layout without locale. But not ru. Setting ru locale changes nothing or creates bad output. Maybe that is cause of such inaction of ru locale?
(Edited. One more style with order: en, ru, lt, default locale must be lt.)
(Edit: the spec link in this post is off the point: I misread, and assumed you were talking about sequence of the cs:locale nodes, not cs:layout. The fault has been fixed, though; see below.)
One more experiment. I changed order only in one section of style - bibliography. So order in bibliography: lt, en, ru; order in citation: en, lt, ru.
Default locale - lt. Lithuanian reference - Lithuanian terms are everywhere. English reference - Lithuanian terms in bibliography, English - in citation.
Default locale - en: all vice versa.
Russian in both cases - OK.
Now I'm going to bed really :).
The cause of this most recent (and hopefully final) fault was that it was retrying for a match between the item language fallback locale and the list of available locales, rather than against the one-element version of the item locale and those available. The fallback for "lt" (and any other non-standard locale) is "en-US", which is always available, so it was finding a match as soon as it hit that cs:layout node, and that was very wrong indeed.
Results the same. I used the last example with different order of layouts in bibliography and citation (order in bibliography: lt, en, ru; order in citation: en, lt, ru).
So:
locale en: all good with en and ru references, but lt references are with Lithuanian terms only in bibliography.
locale ru: all OK with ru, lt and en references with lt terms in bibliography.
without locale: same as with locale ru
locale lt: all good with ru and lt references, Lithuanian terms in en bibliography.
(Edit. Other style with alike order in bibliography and citation had correct terms only with "correct" default locale.
Edit 2. I didn't touch order of locales, only order of layouts in bibliography and citation [nodes?]. And sorry for my English - it isn't good indeed. :))
@rintze: Simon's validator looks very simple to explain and to use. I've forked the repo, but haven't yet recompiled the code with the MLZ schema.
Hoping for good news, thanks for your patience. Despite the repeated glitches, we're getting close with this.
Maybe it's not a bug, but a feature, as layout without locale, that must be on the bottom. As for me this situation is not bad at all.
Only one thing should be done - short instructions should be written about creation of multilingual styles with warning about order of layouts.
But something isn't good, because Russian layout isn't working as default. Maybe it's fault of Russian locale.
I can send you styles and examples, but this situation is with all my multilingual styles.
By the way, this tool: http://steveridout.com/csl/visualEditor/ always cuts out "xml:" from all locale names. I've send bug report.
(Edit. I think, Russian layout is working because Cyrillic of it - there is no other fallback, only one Cyrillic style.
One more idea. My MLZ locale - en_US, but "general.useragent.locale" of Firefox - lt. Maybe this creates mess of languages to processor.)
Entries with no locale or an invalid locale are rendering in the default language, and valid language codes on an item force its terms and formatting to that locale. I can't produce output like that in your screenshots with the current MLZ version.
It's likely that there is a problem with your input. Please post your item data and the exact style code that you are using for testing to http://gist.github.com, and I'll take a look.
The editor at http://steveridout.com/csl/visualEditor/ will not (yet) work with MLZ styles by default, because it relies on the official CSL 1.0 schema. The developer has set up a means of configuring the editor to work with MLZ styles, but there are some bugs that need to be worked out before it's ready for use.
There is the same style as in screenshots: https://gist.github.com/3334891 All is OK with default locale en, but not lt or ru - Lithuanian terms then dominates in English references (not editor - it isn't translated here). There is only few terms described in lt locale. But I think, such a situation better reflects situation of ordinary user that can't create own locale for language.
There is the same reference as in screenshots: https://gist.github.com/3334921
default-locale="lt": http://img809.imageshack.us/img809/9338/ltconfirm1.png
default-locale="ru": http://img36.imageshack.us/img36/5937/ltconfirm2.png
Both render the en-tagged item with English terms. This is with MLZ m229.
My guess would be either that MLZ is not yet at version m229, or that this style code has somehow not installed.
Sorry for troubles.
And I think, that last bug you found because my complaints, was not the same as those, about which I was complaining :). But bugs were real, so not so bad.
Thank you very much for assistance and help.
Is MLZ updating automatically via Firefox or I must do it manually via your site?
Now third (and most complicated) stage of transition from EndNote to Zotero is before me - create styles that suits my needs. They should be humanitarian ones and that means - very complicated.
I'm not sure if MLZ updates automatically. I think it does, but the "Find updates" item in the Tools -> Add-ons -> Extensions -> MLZ context menu certainly does work.
When I get a make-easy validation engine in place for MLZ styles, I'll post back to this thread. Meanwhile, don't hesitate to write again if you have problems.
I've almost wrote my multilingual style (it validates), but Lithuanian localization is working quite strange for me. Date style is not Lithuanian, but English and so on. Date style became Lithuanian only after inserting all Lithuanian locale to my style.
Is Lithuanian locale working in Zotero? Rintze added it to repository: http://forums.zotero.org/discussion/24804/some-csl-lithuanian-locale-translation-problems/#Item_17 My MLZ version - 232.
And one more strange thing. Ordinals became Lithuanian even in English references after insertion of Lithuanian locale to style. So edition isn't "2nd", but "2asis".
This is reference no. 1: https://gist.github.com/3435300 (style of date incorrect)
This is reference no. 2: https://gist.github.com/3435337 (edition term is incorrect - English "ed." and ordinal "2nd" instead Lithuanian "leid." and "2asis").
All Lithuanian terms disappears from reference after removing all but one term from locale xml:lang="lt" section
That affects both citation and bibliography.
I am testing in Zotero CSL editor - there I can change language of reference, sequence of items and modify style itself quickly. I am citing documents as "first". But removing term "volume" from Lithuanian locale section affects both first and subsequent sequence of book (from "t." to "vol."). The same things are happening to the LibreOffice Writer citations.
The Lithuanian locale has not yet appeared in official Zotero, and I hadn't yet added it to MLZ either. I've just issued an MLZ revision that contains the new locale, so if you update, you should find things work correctly, with or without Lithuanian terms in the style itself.
The style code is not valid, but the syntax errors do not affect processing with citeproc-js. The main problem, which puzzled me at first, is in the date nodes. You have given these date-parts and form attributes. In that case, the date-part subnodes are ignored, and the locale code is used instead. You can just eliminate the subnodes. A copy of the style with these changes is here.
There are a few other issues with validation under the MLZ extended CSL schema. Number variables must always be rendered as number, not text; and spaces are not allowed in prefix and affix. Fixing these issues will take a lot of work, and possibly some rewriting of the style. The processor will run the style in its current form, though, so I would just use it as-is, until full documentation on the MLZ schema is available, and you have time for the editing.
And how I can know is there Lithuanian locale added to Zotero or not? Where is this written?
Thank you for correcting my style :).
I am new to xml and to coding itself, so this was hard task to me to heavily modify an existing style to my needs. The official documentation is too complicated and time consuming to read and understand. So I feel myself as half illiterate when modifying style, copying from several styles to my style parts that suited my needs etc. :). But I think, that I managed to understand logic of CSL language (and xml itself) after some amount of such manipulations. Obviously that I dosen't know a lot of little things about CSL (as about date-parts). But my task is only to write some styles for myself, not to became specialist of CSL.
So I copied from Chicago Manual or Modern Humanities styles such a things as number variables as text. I'll correct that.
Is my understanding right, that some things that are correct in usual CSL schema, aren't correct in MLZ extended one?
It is quite easy to correct number variables. But I don't have any idea how to write correct style for my needs without spaces in prefix and affix. By the way, prefix " ." [space and dot] is correct or not?
(Edited. And I think, that most urgent thing is to create MLZ extended CSL schema validator (as validator.nu). When it points to the mistake it is more easy to understand the mistake and correct it than search for the mistake in the rather complicated documentation. This is correct for noobs, of course :)).
Setting up a validator for the extended schema is a high priority. I have all the necessary pieces, but I'll need to find some quiet time to set it all up.
And I wish you to find some quiet time :).
Thank you for your invaluable help and input.
The validator will take some weeks more.
(I will be out of contact for a couple of days, in connection with some upcoming air travel.)
THANK YOU!
Have a good travel!
Ordinals depends on default locale, not on language of reference. So edition is "2nd" even when reference is Lithuanian or Russian but locale - en, and, accordingly, when locale - ru, edition is "2й" with Lithuanian and English references; when locale - lt, edition is always "2-asis" despite language of reference.
This is with my style with your corrections and with that reference: https://gist.github.com/3435337 (all other references are affected too where edition is listed). All other terms are correct, as I see.
The same is happening with MLZ CMS style.
@arggem People have less and less quiet time for themselves in our times.
(Edited. This situation suggested me one thought. What if do such thing for some items in reference? For example, terms "accessed", "internet" and "online", form of date accessed must be in Lithuanian despite what is language of reference (when language of text is Lithuanian of course). There are quite simple to change some terms that should be all the time, lets say, Lithuanian in references via locale without xml indication. But there isn't possibility to change form of date in one part of reference without changing form of dates in other parts of reference. I saw such a request to French references there: http://forums.zotero.org/discussion/24999/problem-with-locales/ And it was about date of access too. So maybe is it possible to do that thing in MLZ - bind form of date of access to default locale of style, not to language of reference? I think, that such requirements for forms of date accessed are universal in all languages. Such is my thought and proposal that came out of a bug :). That would be nice feature, I think, if it is possible.)
Tying accessed date to the default locale is an interesting idea. I'll take a look at implementing that also, and we'll see if anyone complains.
(Edit: For ordinals, a glance at the code turned up the problem. There is a proposal for enhanced ordinals support on the table, though, which I would like to implement. I think it might make sense to put in a little more time on this, and fix both problems in one go.)