mw-log is really activity log, for all activities in my php bot, which is actually $wgDebugLogFile. There was a time people asked me "why my bot is doing (something) in (some way)" and the situation was difficult to reproduce. The only use of those files (until now) is to answer those questions for people (and sometimes for myself).

Another broken sample:

In T131061#2158907, @Jdlrobson wrote:

Ahh thanks @liangent for clearing this up. What do you mean by regular UI? Vector? What code hides them?

No it does not mean unchangeable. Technically ZH is just a variant, with an (almost) empty conversion table, 不转换 means unchanged.

Thanks. It will not be a reimport but a move, so I'll have to take care of host names every time... There's no way to ensure reliability I think, unless you have prev.commonswiki.labsdb and prev2.commonswiki.labsdb etc.

In T126946#2071461, @jcrespo wrote:

@liangent, user databases were lost and will not be able to be recovered.

Any plan or progress on this?

In T87332#1999997, @Bawolff wrote:

Note: i expect the patch on T119158 will break this behaviour

I got hit by this again after some NFS issue / maintenance:

job-ID  prior   name       user         state submit/start at     queue                          slots ja-task-ID 
-----------------------------------------------------------------------------------------------------------------
2176874 0.33696 php_dispat tools.liange Rr    01/21/2016 20:14:03 continuous@tools-exec-1403.eqi     1        
2557022 0.31185 lighttpd-l tools.liange r     01/21/2016 21:30:57 webgrid-lighttpd@tools-webgrid     1        
2674248 0.30267 php_cleanu tools.liange r     01/25/2016 23:03:03 task@tools-exec-1405.eqiad.wmf     1        
2695870 0.30098 php_dispat tools.liange r     01/26/2016 17:01:31 continuous@tools-exec-1408.eqi     1        
2699329 0.30069 php_cleanu tools.liange r     01/26/2016 20:04:51 task@tools-exec-1401.eqiad.wmf     1        
2710470 0.30000 php_popula tools.liange r     01/27/2016 03:27:03 task@tools-exec-1407.eqiad.wmf     1

job ID 2176874 and job ID 2695870, but note that 2176874 was started a long time ago than 2695870.

For the record, I was clicking rollback on https://zh.wikipedia.org/w/index.php?title=%E4%B8%89%E6%9A%97%E5%88%BB&action=history for the revision at 2016-01-26T16:41:30‎.

In T67857#1058984, @Anomie wrote:

This is somewhat intentional, see T22233. I wouldn't be opposed to returning a distinct error code (e.g. "ResetPass"), but this should remain an error condition.

If it's only Hong Kong people who report this, I suspect they're actually using some English operating systems / browsers, considering English is another official language there (is there any Cantonese operating system?)... Obviously they will see mixed content if they don't configure their browsers which send Accept-Language: en by default.

Copying my typescript here for now. I can't ensure that file will stay there longer than phabricator.

In T119687#1911453, @zhaofengli wrote:

FYI, the hardcoded conversion table is includes/ZhConversion.php which may help determine the language variant of arbitrary text.

Just a note, Language Converter in MediaWiki is not merely a representative transformation; it's hooked into many MediaWiki components, a bit deeper than what CX reaches currently (most importantly, link resolution).

I see Echo, CX and Flow there. Since I'm mostly working on content, hitting other items seems not so likely as they're more about user activities. However it's difficult for me to "predict" their behavior and new extensions will come from time to time.

Yes I'm hitting Flow content right now ... but since I'm using extensions "randomly" and I only look at their public interfaces I'm using, I'm not sure if they also try to talk to extension1 from other places.

In T121742#1887125, @jcrespo wrote:

@liangent which specific data (columns) do you need? I do not think it is possible to replicate everything, but for a specific column(s) it could be studied. Please note that this requires: the developers review, the ok from legal and the actual technical setup, so it may take some time.

I can now reproduce it in VisualEditor:

I haven't looked into the code but this type of bugs usually just need a wfMessage( 'parentheses' ) call in appropriate place. In this case it's easy and I'm tagging it easy for GCI.

No time to work on it right now but I guess it might be easy for a GCI task?

In T115266#1814760, @Dbrant wrote:

@liangent Can you provide a specific example of a page where this happens?

Wrong database used I guess; sorry.

Seems completely resolved?

I have http://tools.wmflabs.org/liangent-django/recent_contribs/ but I'm not sure whether any person is using it.

Still happened in May: [[zh:User talk:Yuriy kosygin]]

Although I said that I was looking forward to it and there would be good use cases on zhwiki, I don't have time to work on it right now. Since it's mentioned in the announcement that it will be available globally at some time in June, I guess I can just wait for it.

In T95575#1195233, @EBernhardson wrote:

Please type F12345 (but change the number) to link images. We are not able to see the image as linked.

The easy way is to drag and drop an image from the finder or explorer into the edit dialog.

(deleted)

Occurrences were also observed on zhwiki.

Phabricator is so unfriendly for slow networks. "Nothing happened" when I was typing in the Projects field :( but fortunately it still allowed me to submit the form.

In T85396#946012, @Reedy wrote:

In T85396#945836, @valhallasw wrote:

What is the suggested use case for this? What would it allow you to do you cannot do with the current search?

Browser plugins presumably?

Files:

I logged the attached data about https://www.wikidata.org/w/index.php?title=Q874074&action=history . It appears the behavior has regressed.

I added some logging to my bot and it appears that similar situations are due to T59754.

In T547#8678, @bd808 wrote:

This double encoding issue seems to also effect the links to OAuth accounts on https://phabricator.wikimedia.org/settings/panel/external/

It's not just non-Latin, the link on https://phabricator.wikimedia.org/p/mmodell/ is broken too...

Note that current links appear double percent-encoded so they're broken for user names containing non-"basic" characters. See https://phabricator.wikimedia.org/p/Fan/ for an example.