I see. Apparently my translator did not auto-update *and* I was bitten by the fact that "lastUpdated": "2013-07-01 14:13" in BibLaTeX.js was not updated between versions.

What I now get upon export is hyphenation = {en}. biblatex, however, will not understand this; it should be hyphenation = {english}.

timestamp is updated. I get langid={english} for both "english" and "en" in Zotero's language field, so that looks like it's working as intended.

I'll talk to the main dev of that translator - seems plausible to me to not render language when we have langid.

Maybe then we should never write to the biblatex language field. Do you think I should do that? Would people expect anything else?

I tend to think that content from the Zotero/CSL "language" field should never be mapped to the biblatex "language" field. In particular, it seems more confusing than helpful if some content is written to biblatex "langid" and some to biblatex "language." And - leaving aside the slightly confusing likeness of field names - I do not think people will actually expect a field that is never printed (CSL "language") to be mapped to a field that by default is (biblatex "language").

A translator fix is now up. Your version of Zotero will automatically update within 24hs, or you can update manually using the "Update Now" button in the "General" tab of the Zotero preferences.

Thanks to anjo7539

I experience a problem with biblatex export and my guess is that it is the result of recent changes described above.
I noticed a change because now the single Zotero field "Issue" is translated in two biblatex fields ("Issue" and "Number") with the same value. This results in the incorrect output like this:

Brader, Ted A., Joshua A. Tucker, and Dominik Duell. 2013. "Which Parties Can Lead Opinion? Experimental Evidence on Partisan Cue Taking in Multiparty Democracies." Comparative Political Studies 46, no. 11 (11): 1485-1517.

However there are other changes. Here is the result of standard biblatex export 2 weeks ago:

@article{brader_which_2013,
title = {Which Parties Can Lead Opinion? Experimental Evidence on Partisan Cue Taking in Multiparty Democracies},
volume = {46},
issn = {0010-4140, 1552-3829},
url = {http://cps.sagepub.com/content/46/11/1485},
doi = {10.1177/0010414012453452},
shorttitle = {Which Parties Can Lead Opinion?},
language = {en},
issue = {11},
pages = {1485-1517},
journaltitle = {Comparative Political Studies},
shortjournal = {Comparative Political Studies},
author = {Brader, Ted A. and Tucker, Joshua A. and Duell, Dominik},
urldate = {2013-12-01},
date = {2013-11-01},
keywords = {Great Britain, Hungary, partisanship, party cues, Poland, political parties, public opinion, survey experiments}
}

Here is what I get now:

@article{brader_which_2013,
title = {Which Parties Can Lead Opinion? Experimental Evidence on Partisan Cue Taking in Multiparty Democracies},
volume = {46},
issn = {0010-4140, 1552-3829},
url = {http://cps.sagepub.com/content/46/11/1485},
doi = {10.1177/0010414012453452},
shorttitle = {Which Parties Can Lead Opinion?},
abstract = {Political parties not only aggregate the policy HERE GOES COMPLETE ABSTRACT.},
issue = {11},
pages = {1485-1517},
number = {11},
journaltitle = {Comparative Political Studies},
shortjournal = {Comparative Political Studies},
author = {Brader, Ted A. and Tucker, Joshua A. and Duell, Dominik},
urldate = {2013-12-01},
date = {2013-11-01},
langid = {english},
keywords = {Great Britain, Hungary, partisanship, party cues, Poland, political parties, public opinion, survey experiments}
}

Questions:
1. How to fix the problem with double issue/number?
2. Is there a place where such changes are documented? It makes using Zotero unreliable when - without a warning - the same operation could not be performed after a short period of time.

1. Thank you for prompt and helpful response, as usual!
2. I see the problem with new translators. By the way, as far as I understand, with these changes in language fields you have just fixed the problem that was already fixed on the biblatex end (http://tex.stackexchange.com/questions/147749/excessive-fields-in-biblatex-chicago-author-date-style). I understand that there are many implementations of biblatex, but some sort of coordination with at least major ones could save resources on both ends. It maybe unfeasible though.

2. I am sorry, I maybe confused you. I meant not the "urldate" field issue, but the "language" field issue. It was solved though using the same \AtEveryBibitem{\clearlist\ function.
And ideally I would prefer biblatex to use only the fields I need rather than limit the information Zotero is storing. However, as far as I can understand, the partial solution here is exactly in the fine-tuning of the export translators.

@s0larix: The reason for expecting ISO language codes (e.g. en-US) and mapping these to babel (and soon hopefully polyglossia) languages is that this is what is used in CSL. If there are any CSL applications that makes use of it for switching language (Zotero word-processor plugins?), having the correct ISO language code would mean that it works both in that case and with biblatex.

The language fields in peoples real life Zotero databases don't neccesarily look that nice though. I've noticed that you could end up with many different language codes using the web translators.

@anjo7539: That makes sense. Luckily it wasn't too hard to update my database as explained above.