User Details

User Since
Aug 6 2016, 12:30 PM (166 w, 3 d)
Availability
Available
LDAP User
A2093064
MediaWiki User

Thu, Oct 10

A2093064 renamed T235141: Translate tool didn't create or update /lang page from Translate tool didn't create /lang page to Translate tool didn't create or update /lang page.
A2093064 added a comment to T235141: Translate tool didn't create or update /lang page.

I have never encountered this problem. The updates in the main page usually happen in few seconds.

A2093064 added a comment to T235141: Translate tool didn't create or update /lang page.

I just created Translations:API:Revisions/4/zh. But it didn't shown in API:Revisions/zh.

A2093064 added a comment to T235141: Translate tool didn't create or update /lang page.

What languages aren't showing up?

zh

A2093064 added a comment to T235141: Translate tool didn't create or update /lang page.

@DannyS712 And
https://www.mediawiki.org/wiki/Manual:CleanupEmptyCategories.php
https://www.mediawiki.org/wiki/Help:Extension:GWToolset (New translation is not merged into current page)
https://www.mediawiki.org/wiki/Extension:SimpleMathJax

Tue, Oct 8

A2093064 renamed T234873: Page argument in links on Special:ReviewedPages and Special:ConfiguredPages are encoded twice from "reviewed versions" links in Special:ReviewedPages are encoded twice to Page argument in links on Special:ReviewedPages and Special:ConfiguredPages are encoded twice.

Thu, Oct 3

I can reproduce this bug with x-powered-by: PHP/7.2.22-1+0~20190902.26+debian9~1.gbpd64eb7+wmf1, so HVMM is not related.

I can reproduce this bug with x-powered-by: PHP/7.2.22-1+0~20190902.26+debian9~1.gbpd64eb7+wmf1, so HVMM is not related.

Fri, Sep 27

Thank you! I have asked the local IA for help.

Wed, Sep 25

A2093064 added a comment to T233773: Source wiki edit comment in wrong language.

Not yet translated on translatewiki or dewiiki.

Sun, Sep 22

Nobody can fix it if you do not provide clear steps that allow other people to see and reproduce a problem...
I've asked for clear steps several times here, but my requests are ignored in this task. https://www.mediawiki.org/wiki/How_to_report_a_bug

Just implement anything that could be described by the following pseudocode, and you'll reproduce the problem:

Implemented in python.

1 import requests cnt = 0 while True: cnt += 1 req = requests.get('https://zh.wikipedia.org/wiki/Special:Random?uselang=zh-tw') html = req.text print(cnt) if '' not in html: break with open('temp.html', 'w', encoding='utf8') as f: f.write(html)

Sep 15 2019

A2093064 closed T232714: Wrong subst-if output as Invalid.

@Dinoguy1000 Thanks for the information. It seems that "yes" is the expected result. So I closed this task.

Sep 10 2019

Does the equivalent feature in the web UI not have the same result? If not, is that not considered a bug?

Moving over page in web UI doesn't trigger removal of sitelink. I don't think this is a bug. For example, in a history merge case.

On the other hand, the API client could just call action=delete followed by action=move to achieve the same effect. Is there a disadvantage to doing this besides that it needs an additional API query?

This resulted in the removal of sitelinks on Wikidata. So I think this feature will be useful.

Sep 4 2019

A2093064 updated the task description for T231982: NOINDEX userpages within the Chinese Wikipedia.

Aug 15 2019

A2093064 reopened T230294: Add Portal namespace on Chinese Wikisource as "Open".

The patch is wrong. There are already some configuration at Line 6822. But the patch added new configuration at Line 6461.

A2093064 updated the task description for T230548: Shortcut namespace redirect on zhwikisource.

Aug 5 2019

Do you think it is possible to make that default for all zh-language wiki?

Yes. But does this need each community consensus?

Aug 4 2019

Set $wgExtraNamespaces[828] = 'Module'; seems to solve this problem. Manual:$wgExtraNamespaces: It can also be used to rename the default namespaces.

Aug 1 2019

A2093064 updated the task description for T229541: Javascript injection in edit summary on mobile site (CVE-2019-14807).

I assume the second URL was provided just to show the diff?

Yes.

Jul 30 2019

A2093064 updated the task description for T229339: MediaWiki:Sidebar is ignored for variants on zh.wikivoyage.

Jul 26 2019

A2093064 added a comment to T228959: Abusefilter's block with a "Mobile edit" tag.

Maybe someone would think that Abusefilter can be controlled by real people.

Jul 25 2019

Reopen because I found same bug happen on zhwiki.

A2093064 renamed T228876: Some interface messages are default messages instead of local overrides for language variants on Chinese Wikipedia and Wikivoyage from The Chinese Wikivoyage tab name display error in browser to Some interface messages are displayed as default messages instead of local overrides on Chinese Wikipedia and Wikivoyage.

The changes you made are for zh-tw content language, so you won't see any changes.

Interface message follow Interface language setting. And I use uselang=xxx to check it.

I suspect the problem caused by the gadget (javascript can modify the page title).

I don't think so. This bug still exists with safemode=1.

Jul 24 2019

Are you browsing in zh-tw content language?

Interface language: zh-Hant-TW
Content language variant: zh-Hant

I can reproduce it.
When I do a null edit on MediaWiki:Pagetitle and the title of any pages changed to correct title.
Not it's fixed but I don't know why.

Jul 21 2019

When querying rc_id, namespace is required to same as rc_namespace (Original namespace).[1] Will removing this condition cause any errors?

Jul 8 2019

A2093064 renamed T227410: Visual editor is not compatible with Modern skin from Bug for Editing in zhwikiveristy using modern skin to Visual editor is not loaded on zhwikiveristy with modern skin.
A2093064 added a comment to T227410: Visual editor is not compatible with Modern skin.

@Aklapper In the short word
https://zh.wikiversity.org/w/index.php?title=303&veaction=edit&useskin=modern Nothing happened

Jun 19 2019

He moved "File:蔣培火墓.jpg" to "File:蔡培火墓.jpg" and got errors, then this file lost.

@Krinkle A user posted this error message in a Facebook group. He said he can't upload files and view Special:ListFiles/His_name. These are all I know. Maybe I can ask him for his permission.

Jun 17 2019

to ensure that the Special:Block JavaScript runs before the script.

Fixed this script.

Jun 8 2019

@Tchanders Yes. It's very difficult to reproduce it.
My environment is Google Chrome Version 74.0.3729.169 (Official Build) (64-bit) on Windows 10 Version 10.0.17134 Build 17134.
I have enabled many Chrome extensions, sitewide gadgets, and imported so many scripts in common.js. But scripts will affect block interface only are MediaWiki:Group-sysop.js (Line 31-69) and m:User:Xiplus/js/block-time-convert.js.

Jun 3 2019

@Tchanders I refreshed the page several times then got this screenshot.

May 19 2019

As close as possible to June 1.

May 18 2019

A2093064 added a comment to T216858: Customize date format of warning message header.

You can see that if you change headings to standard, then you can define which text will be used for template header. I suppose it could contains some wiki-text that would have the timestamp in format you prefer.

After my test, I found the documentation is wrong. The "headings" should be "page".

Apr 30 2019

I remember that the reason part of form was broken in appearance (Maybe something was not loaded because of my network). But I can still select a block reason.

Seen 7 times in the last week, 4 of which were on zhwiki today at short breaks (probably the user re-tried to submit the form).

A2093064 renamed T222170: InvalidArgumentException from SpecialBlock.php: "\$comment can not be null" from InvalidArgumentException when blocing user on zhwiki to InvalidArgumentException when blocking user on zhwiki.

Mar 12 2019

@FellTiger Maybe my statement is a bit wrong. There is no revisions on the page. So you can't delete it. But when you view the page, you will see some text from translatewiki instead of noarticletext [1]. This message (from translatewiki) will be displayed instead of the message on root page.
[1] For example, compare these two pages: A and B.

Mar 8 2019

@Yurik All language-specific pages of MediaWiki:talkpageheader exists. Although they are empty but they exist.

Mar 3 2019

A2093064 closed T217240: Massmessage list "add page" field not working as Resolved.

It works now.

@Aklapper

2. Move the mouse over the Star icon.
3. The tooltip shows 明星条目. The expected result should be 明星條目.

There are two links to 明星条目 in same page. One is written in zh-hans, another is zh-hant. But their tooltips both are 明星條目. We want the links in the Pagebanner work like this.

@Yurik This defines that this message exists and is empty by default (like Sitenotice). So language fallback not works. But this design is useful for most of message. If sysop custom a message (in rootpage, in English) but not in some language. Default message is better than custom message (for system interface message instead of notice message).
I still suggest creating 430+ pages as a workaround. You can do that by some tools like bots or AWB. There may not be a lot of pages with the same problem.
I don't know if there is a way to solve your problem at the system level. Maybe need to change the language fallback feature. I am not proficient in this.

@Yurik If there is a default message from translatewiki.net, it (eg. MediaWiki:Talkpageheader/xx) will fallback to default message instead of custom message in rootpage (MediaWiki:Talkpageheader). Language fallbacks only works for non-existent messages.