I just ran into this problem while uploading a few files, one of which was https://commons.wikimedia.org/wiki/File:Ankeng_LRT_tram_1.jpg

I took a look at this and it's a bit more involved than I was hoping:

Yeah, I think #2 from @Legoktm's earlier comment is probably the easiest short term fix in MM. The long term solution is probably T290054 but I don't have bandwidth to work on it in the near future, and it doesn't look like anyone else is actively working on it.

I approved it because it seemed like a simple enough change—I wasn't aware of T313672 but it seemed reasonable that there might be one off pages (not just on WMF wikis but in general) that people want to make valid targets for MM, e.g. maybe you generally don't want to make the project namespace eligible, but have a specific noticeboard that you do want to make eligible. I don't feel strongly though.

Without fixing this, the user could submit a form with errors for preview, then fix them while changing the page message to a new title and then press send with the page title and revision ID being from different places.

Happy to help with code review if someone is interested in implementing the feature!

T306591 is the followup task for the suspected issue in core.

I do have a local test wiki (tracking the master branch), but I wasn't able to reproduce the issue by following the steps in the task description. @Urbanecm if you're able to reproduce the issue locally it would be great if you could share the relevant configuration in your LocalSettings.php (or if you have other idea why this might not be consistently reproducible); thanks!

Sorry, I didn't mean to imply the refactor was at fault, just trying to document what I've looked at in case it was relevant. Do you have suggestions for how to investigate further or reproduce the issue? It seems pretty unlikely that this was broken by a change to MassMessage (the content model logic hasn't meaningfully changed in years: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MassMessage/+log/refs/heads/master/includes/Content), but I got pretty lost trying to navigate the relevant code in core...

@Ladsgroup or @roman-stolar do you have any idea what might be going on here, or what recent core changes might cause something like this? (The content model logic in MassMessage hasn't been touched in a while.) I couldn't reproduce the issue on my local test wiki, and I haven't had much luck tracing the code to see what is setting $generateHtml to false.

A version of the JavaScript link-rewriting workaround has been deployed on zhwiki using a combination of gadgets and common.js:

Sorry, I tried looking into this and got stuck, and then it fell off my radar. I probably won't have time to help resolve this in the near future, but here are some preliminary thoughts:

In T279483#7155840, @Mooeypoo wrote:

I think that's a pretty big problem, and if nothing else, that preference should be made clear that its consequences of that choice ARE public.

Sorry for the delay in responding. I'm still struggling to understand what exactly the issue is...

@Krinkle, @Legoktm mentioned you'd worked on the AnonymousI18N gadget on Commons which I tried to imitate in https://zh.wikipedia.org/wiki/User:Wctaiwan/rewritePathVariant.js Would you mind reviewing the code to see if the approach makes sense to you? Thanks!

I put up a proof of concept for rewriting the links in JS at https://zh.wikipedia.org/wiki/User:Wctaiwan/rewritePathVariant.js and started a discussion at https://zh.wikipedia.org/wiki/Wikipedia:互助客栈/技术#在瀏覽過程中保留中文變體 for potentially adding something like this to Common.js on zhwiki. It wasn't complex as I'd feared, and anecdotally the performance seems acceptable.

@Winston_Sung can you provide reproduction steps (a link to some wiki page where people can see the bug in action, or better yet, a list of steps to trigger the bug so other people can debug on their own wikis) for the issues you mentioned? That would help me or other people look into what's causing them, and potentially come up with a fix or some better workaround. It still feels weird to me to put zh-hant strings in zh-hans arrays, and other people having to maintain the code in the future would likely not know what to put in the arrays to maintain the correct fallback behavior.

So our options are probably:

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/742677/ doesn't quite work because the parser cache is shared for everyone (logged in and anonymous users alike) looking at the same variant. This means that e.g. a logged in user viewing an article would fill the cache with non-variant-specific links, and so an anonymous user who later visits the article would still have the same issue.

I think this makes sense based on the needs being served by codesearch. For me personally, it's most useful in two scenarios:

Is the idea here that zh-hant would be used for zh-tw everywhere (and zh-tw shouldn't exist) and zh-hk would be used to override it for cases where it has different phrases?

I confirmed that the truncation seems to be specific to PHP-FPM. With both mod_php and PHP's built-in web server, the Content-Length header is not set because headers_sent() is true at https://gerrit.wikimedia.org/g/mediawiki/core/+/bc26dd1b446102cc861ff0d08cc7fc6efa8fd012/includes/exception/MWExceptionRenderer.php#79 With PHP-FPM headers_sent() is false at that point.

Done. I think T296103 is the more serious issue since it prevents debugging, whereas this is more of a nice to have assuming we can fix the error message.

Yeah, I think ideally this should be caught before the user makes it to this stage.

Filed T296103 for the error truncation.

The contents are truncated.

This is caused by https://gerrit.wikimedia.org/r/#/c/94691/, where a really old patch from pre-mmch days was revived and merged.

Hi. Phabricator is for technical issues with MediaWiki and other Wikimedia software. You can correct content issues with pages on Wikipedia either by editing them yourself, or asking for assistance on the talk page of the article. Thanks.

In T128643#2137011, @Kharkiv07 wrote:

Can't this already be done with Special:ChangeContentModel?

For anonymous users, it remembers the last editor chosen. In VisualEditor, you can switch to source editing by clicking on the "[[ ]]" icon. In the source editor, you can switch to VisualEditor by clicking on the pencil icon at the end of the toolbar. This page has detailed documentation.

I hope I can get a response to my previous comment.

When I first click Edit without having set a preference, I am presented with a dialogue box that asks which editor I want to use, which also includes the option to always show both tabs. It's one extra click the first time you edit, leaves the choice up to the user, and doesn't force anyone who doesn't want to use VE to use it. I don't see why this is problematic at all.

In T130148#2200465, @Jdforrester-WMF wrote:

That's not how wikilinks work. If you click away without clicking 'Done' it will discard.

Let's not.

I think we should aim for allowing anyone, not just sysops, to create delivery lists.

We should probably do this in a way that warns the user that the page is going to be converted, and tells them the old wikitext can still be accessed in the revision history--maybe something like the warning we give for missing signatures when sending a mass message.

What makes the developer summit costly? Perhaps reducing the number of scholarships or having partial scholarships (instead of covering all travel expenses) would help?

It does seem like the browser correctly sent all the cookies that were set.

In T125194#1981914, @Anomie wrote:

I note that being completely inactive for 30–60 minutes[1] will result in your session expiring, and if you didn't check the "remember me" checkbox that will cause you to be logged out. Note the username would still be filled in even without "remember me" checked. But that's how it has always worked, IIRC.

I'm going to close it as declined because the task started out as a feature request for MassMessage, and has since become a feature request for the newsletter extension. The task description refers to MassMessage, but changing it now would probably remove context for the existing comments. It's probably better to just start a new task with specific goals laid out for the new extension, if desired.

In T73240#1344502, @Vibhabamba wrote:

This is absolutely incorrect.

Well, not having the feature certainly preempts any social problems related to the feature. I still don't see the benefit, but I suspect further discussion would not be productive.

While I don't think we're realistically in the danger of having Reddit-like meme threads

I think anything that can be communicated with an image macro can be just as effectively conveyed through less distracting means. While I don't think we're realistically in the danger of having Reddit-like meme threads, restricting images to mockups and such would probably make for discussions that are easier to follow.

Any update on the deployment to zhwiki?

The quoted proposed solution sounds fine. It might be better if it still has a single Chinese entry for logged in users and respects the user preference set on zhwiki, but the added complexity is probably not worth it.

I've edited the task description. Let me know if any additional clarification is needed. (I'm testing this using a VirtualBox VM running Android.)

Seems fixed on http://zh.wikipedia.beta.wmflabs.org/

The patch has been merged. I'm waiting for it to be deployed so I can verify that it's working.

In T88164#1205941, @Yair_rand wrote:

(Chinese is the only one of these that has particularly visible unlocalized content, that being the "[Last edited] X hours/days/months/... ago".)

I basically agree with Quiddity that this needs community consensus, at least for enabling it on Wikimedia wikis. Deleting a post is much more similar to revdel (inaccessible to non-admins) than it is to reverts (still in page history). Individual communities can still allow for courtesy deletions.

Probably. I was thinking of abstracting that away so that extensions can just append themselves to an array, without needing a hook function, but that would also work.

One advantage with the gadget approach is that people can turn the features off very easily. I'm not sure it's a good idea to ask users to edit user CSS files (which is not that intuitive and potentially error-prone for non-technical folks) if they didn't want a certain feature. People are already complaining about the new sandbox link extension.

I think this is intentional. See the thread starting with https://lists.wikimedia.org/pipermail/mobile-l/2015-March/008761.html