I just realized that the issue is not only that the translation fails but also that pywikibot breaks because of that. It should just fall back to an alternative translation.

Xqt's comment above was presumably about https://gerrit.wikimedia.org/r/#/c/293957/ (sorry for not linking this earlier here.)

@Xqt said that:

The extension is used to add the "mobile app edit" tag to edits and uploads done via the Wikipedia App and Commons App (since last week).

I don't know the answers to the questions, but here is what I suggest.

The variables $wgFixArabicUnicode, $wgFixMalayalamUnicode and $wgAllUnicodeFixes are now exposed:

It would help to have a concise command to reproduce the problem, not just the error message. In this case it would be something like:

The source data is extracted from http://www.unicode.org/Public/6.0.0/ucd/UnicodeData.txt.

See for example https://ja.wiktionary.org/w/index.php?title=%E7%89%B9%E5%88%A5:%E4%B8%8D%E6%AD%A3%E5%88%A9%E7%94%A8%E8%A8%98%E9%8C%B2&wpSearchUser=Johan+%28WMF%29 - where @Johan's edit were prevented by a filter which was supposed to stop a long term abuse known to use new accounts.

In T49782#486731, @Ciencia_Al_Poder wrote:

Another solution may be to "hide" them by default, and put a button to make them appear when clicked so they only appear when needed. This could be done as a gadget.

It seems that Arabic normalization is controlled by $wgFixArabicUnicode in MediaWiki. T11413 and rSVN60599 provide more details. There is also $wgFixMalayalamUnicode for Malayalam.

I filed T133375 before finding this task. I'm not sure if the two are about the same issue. @Betacommand: do you think your problem came from modules/templates?

Reopening - https://gerrit.wikimedia.org/r/#/c/271720/ changed the style of the warning box shown in the edit action, but not the preview action.

Does @Krinkle's comment at T53329#559212 apply here? (i.e., it's kept as it is for backward compatibility, new clients should use a more modern alternative for better machine-readability)

If we want to go beyond a set of rules/regexes, libraries like https://github.com/jprante/elasticsearch-langdetect might help.

Feel free to take from https://gist.github.com/whym/b5ac3feb2a78797c9d98. (CC0)

Should the list go to https://meta.wikimedia.org/wiki/Research:Revision_scoring_as_a_service/Word_lists/ja? I see regexes added in January there, which might need to be removed/replaced.

https://gerrit.wikimedia.org/r/#/c/272309/

In T119791#2019626, @Mpaa wrote:

Sounds like level should be part of the configuration template then?

I'm not sure https://gerrit.wikimedia.org/r/#/c/258988/ does what this task asks for. I'm not saying the patch is not useful, but the patch seems to solve a different issue.

In T121604#1886454, @Quiddity wrote:

I notice that around half of the top 10 longest names in jawiki are blocked accounts. Perhaps if you know how, you could add the SQL (that will add a column for blocked-status) to your quarry tasks, and then I'll update mine?

@Mpaa: Good point. In light of that, I'd suggest closing this as not done. It appears the problem was in the text, not in the bot.

As mentioned, archivebot.py as of now requires a well-formed localized timestamp. Would it be a good idea to modify it recognize English timestamps and localized timestamps on a non-English wiki?

I believe this was caused by the canonical (local-language) namespace prefix of the template being not recognized. In the old archivebot only English prefixes worked properly. After gerrit:136532 (merged Feb 20, 2015) it should support both English and localized ones.

I added the -sleep option to archivebot in https://gerrit.wikimedia.org/r/#/c/222727/ in July - whether or not it should go is up to discussion. (Sorry for not linking the change here.)

In T85984#1648966, @IKhitron wrote:

For Cat's sake, how could you find these queries, @whym? They have no names, and they are in draft.

It looks like @IKhitron has used the table. https://quarry.wmflabs.org/query/4833 https://quarry.wmflabs.org/query/4814

Thanks @Nemo_bis for the ping. Assuming the travel happens, I wonder if the event scout would be interested in spending a little bit of time with local Wikimedia volunteers (and perhaps OSS engineers) while their visit. A tech talk or just a casual meetup might be great to have.

@AndyRussG: I think @Nemo_bis meant that in some procedures you need to calculate "how many edits editor X has made in the last Y days" which no other API seems to support.

I quickly tested on my local instance of MW 1.26alpha (7b835dd), and it appears that it fails when there are additional lines (==== 出典 ==== {{Reflist}}) after the signature of the sender.

In T85984#1463905, @Glaisher wrote:

In T85984#1463898, @ori wrote:

The API module provided by the extension appears to be used by ArchiverBot and MysteryPedia.

ArchiverBot is managed by @whym but it uses archivebot.py?

Reminder on documentation (basically to myself): If we make DNAU an exception and generally keep ignoring HTML comments, an update to https://www.mediawiki.org/wiki/Manual:Pywikibot/archivebot.py/setup#How_to_prevent_archiving for clarification would be in order.

A couple of options:

In T74944#1075506, @Nemo_bis wrote:

For example, in order to input 誤字を修正しました [2] you may type "gojiwoshuuseishimashita<space><enter>

I don't see this happening so I assume this is about some OS IME, not ULS IME.

Potential sub-tasks I can think of:
*Find venues to spread the word. I can help with spreading it on Twitter and on Facebook via my personal network. Hopefully someone among them at university can respond.
*Find tasks that might attract more Japanese participants of GSoC (and any other similar student developer recruiting programs). I'd suggest including T88552 and some more i18n/language support issues (preferably that have impact on many languages, not just Japanese). This would be where community input from people who don't code could be useful.
*Create a discussion space in Japanese. Perhaps a page on mediawiki.org where Flow is enabled?