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

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.

Now I'm going to bed really :).

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: I'll need the style code and item data for one specific failure.

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

@maras: Another MLZ fix just went up (m229). Here's what it's producing with local test data: http://img801.imageshack.us/img801/5932/multitest.png

Hoping for good news, thanks for your patience. Despite the repeated glitches, we're getting close with this.

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.

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

MLZ is m229. I'll uninstall style, reboot computer and install the same style :).

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.

And my problems again :).

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

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

I hope that my questions and problems aren't only particular things and that they contribute to development of Zotero and MLZ :).

And I wish you to find some quiet time :).

Thank you for your invaluable help and input.

Yes, it is working like a charm :).
THANK YOU!

Have a good travel!

I found one more bug, I think.

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