In the JS console, the error is:

Uncaught TypeError: ref.insertReferenceNode is not a function
    onSearchResultsChoose ve.ui.CitoidInspector.js:354
    emit oojs.js:858
    chooseItem oojs-ui-core.js:8014
    onDocumentMouseUp oojs-ui-core.js:7347

I have only seen this issue in production (actually I think I mistagged this ticket witch CX2-testing), last that I remember when translating https://en.wikipedia.org/wiki/Battle_of_Antietam to Romanian. I couldn't translate the first paragraph in "Aftermath" and the one about "Matthew Brady's gallery".

I have enabled my e-mail address.

As specified above, I should be the initial bureaucrat, under the username "Andrei Stroe"

Any more movement on this issue?

After some discussion, we decided on:

1. romd.wikimedia.org for the domain name
2. fishbowl wiki
3. "Wikimedia România și Moldova" for site name

Yes, it's perfectly OK, because the code I'm going to replace with a call to this function is brutely iterating through the claims table.
Further filtering should be left to the calling module.

We seem to be having the same problem on ro.wp

1. In ro.wp, the legend now contains the text that is explaining the abbreviation used by ORES for harmful edits: "r This edit may have problems and should be reviewed". The text is in English. Where can we translate it? Same question for the ORES filters description in the filters menu.
2. Also, this abbreviation is ambiguous. In ro.wp, we use the letter 'r' to mark bot edits. Can we use another letter here? For instance, 'p', as in 'problems'?

Never mind, it seems to have worked with the last of my scratch codes. For some reason, most of the others were not working.

The tagging campaign is now complete.

That was a series of bot edits that was untimely, so they were self-reverted in order to be redone in due time. You can tag them as not damaging.

This is the change that I made in order to avoid it. That module was loading up the Wikidata item of the city of birth in order to get the country where it was located. If you want to test it, just rollback my change and you can test live on ro.wp. We're a small community and we discussed the issue at the village pump, so just mention you're investigating it when you rollback my change and the patrollers should leave you alone. Thomas Mann is the only article where we encountered this so far, anyway.

FWIW, I managed to work around the issue by optimizing some modules so that they load less Wikidata items. However, the error should be better reported.

Just FYI, the behavior in this issue is slightly different: it did not create empty refs, it created no refs whatsoever.

I tried this today via API, and it seems indeed that the limitation is in the API now. If I use the API to push a date with precision 12 (to the hour), I get:

"error": {
        "code": "modification-failed",
        "info": "Out of range, must be no higher than 11",
        "messages": [
            {
                "name": "wikibase-validator-too-high",
                "parameters": [
                    "11",
                    "12"
                ],
                "html": {
                    "*": "Out of range, must be no higher than 11"
                }
            }
        ],
        "*": "See https://www.wikidata.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
    },

I think I have something that may help you investigate the issue at hand: I managed to unblock the Norway translation. Seems to be associated with the fact that one of the templates used in the translation did not have TemplateData (in my case, Convert), but was connected via Wikidata to a template in the original. After adding the templatedata, I got a translation that's still messed up, but editable.
I got to this by checking the list of requests made by the browser. The last one was a request to convert a template to wikitext. I looked in the source language wikitext, and saw that both that template, and the next template, Convert, were missing templatedata. After I filled in the templatedata for both of these templates, it works. The first one seemed to be successful, so wasn't much of a bother, but I suspect the Convert was problematic.

Done.

I've reproduced this at least three times in the evening when I reported it, but didn't ever since. It's possible that it had indeed completed, and the debug tool from Chromium failed to notice. Right now, I get a response for that particular xhr, albeit after a full 7 second delay.

Apparently, the labels I translated in https://meta.wikimedia.org/wiki/Wiki_labels/Interface_translation/Edit_quality and https://meta.wikimedia.org/wiki/Wiki_labels/Interface_translation aren't being used. I only see the English labels and they are not spaced well (Linux/Chromium browser).

"Calitatea modificărilor (eșantion de 5k)"

In addition to the groups corresponding to those at en.wp, at least for starters, we should also exclude templateeditor, patroller and autopatrolled.

I think allowing the deletion of a published translation should be the first step towards achieving this. Published translations are definitely saved somewhere outside CT.

I have reviewed the list and copied words to the two lists.

Thanks, @Strainu for the praise and for letting me know of this discussion.
By now, we have many infoboxes that have been refactored into working both in parameter-less mode, and with local override.

Thanks, that worked.

I pulled huggle from git and installed it, but rowiki does not appear anywhere in the login form.

Here is the error more properly formatted:

Notice: Undefined offset: 0 in /data/project/jarry-common/public_html/peachy/Includes/Image.php on line 181

https://ro.wikipedia.org/wiki/Format:Huggle/All

Done.

Attempting to translate [[:w:en:Salmon P. Chase|Salmon P. Chase]] from English to Romanian, and [[:w:fi:Venäjän–Turkin sota (1735–1739)|Venäjän–Turkin sota (1735–1739)]] to Romanian generated the same error.