Thank you, @Trizek-WMF.

@Aklapper, I fixed the task name you provided. Sorry that saw the problem so late.

There is a direction button in VE (under the hamburger menu / alt+shift+x), although testing it now it appears the CM functionality has regressed.
Alt-Shift-x is special:randompage

In T191923#4134021, @Esanders wrote:

Is it any more or less broken than VE (in either visual or source mode)?

Sorry? I tried it in VE, in source mode.

There is a direction button in VE (under the hamburger menu / alt+shift+x), although testing it now it appears the CM functionality has regressed.
Alt-Shift-x is special:randompage

Tried again. It works on desktop, but Alt-Shift does not work. I really think you should spent 5 minutes and a direction button. Something as one of the buttons in"BiDiEditing" gadget on meta.

Well, I tried on desktop computer, but it does not work. I get all the time error 503 "server problem on loading, try again?".

You asked me a couple to check CodeMirror on RTL, so I did this now again. I can confirm, after the check on mobile, that it looks ways better here and ready for deployment. But I also need to check it on a desktop computer tomorrow, because it can be different there. My main concern is Alt-Shift. If it works, everything is fine. I'll be back.

I see. A pity. Thank you.

@FreedomFighterSparrow?

@eranroz, check this out:

<li><a href="/wiki/%D7%94%D7%A8%D7%91_%D7%94%D7%A6%D7%91%D7%90%D7%99_%D7%94%D7%A8%D7%90%D7%A9%D7%99" class="mw-redirect" title="הרב הצבאי הראשי">הרב הצבאי הראשי</a></td></tr><tr><th colspan="2" style="text-align:center;background: #E0F090;">תפקידים אזרחיים</th></tr><tr><td colspan="2" style="text-align:right"></li>

In T190622#4092727, @Etonkovidova wrote:

@IKhitron Following the steps you described, clicking on "view diff" presented me with diff for both edits (tested in betalabs).

Hello, Etonkovidova. As I can see, you get exactly the same problem. Your middle screenshot shows a diff that includes only one edit, of ET3, when the edit of ET2 appears as diff base. If it works well, you could see some previous edit as diff base, and message "one edit of another user is not shown", as it always happens in version diffs.

In T191023#4091981, @Aklapper wrote:

This seems to be unrelated to the Commons extension, hence removing tag.

@DePiep, it's not threaded conversation. Just answer at the end, I'm here.

Continuing @DePiep, you can use the translationwiki for multiple forms in different languages. For example, MediaWiki:Convertunits-length-longform/sl will be something like
'''
$1 {{#switch:$1|1=meter|2=metra|3=metri|#default=metrov}}
'''
Using wikicode and magic worgs as plural, you can change forms, order, remove spaces, and so on. So, you can leave to local users to translate, choosing the most fit form for any measure, long and abbreviated as well.

Noticing @ssastry and @Amire80.

In T190282#4069689, @Niharika wrote:

CodeMirror should only be incompatibly with wikEd and not with wikEdDiff. See https://gerrit.wikimedia.org/r/#/c/395529/

A little addition. You said above that inline and TemplateStyle css can do the same. I just remembered it's wrong even from programming point of view. You can't redefine inline the behavior of existing mediawiki classes, or their interaction with user classes (as I mentioned before abour references with white text).

In T187729#4057582, @Amire80 wrote:

And by the way, did you think about one more reason to restrict this, in addition to all reasons you already have? A regular vandal should learn the wikicode to make more problems here, in wiki. But he can come when he already know css, because it's a language that exists outside in the world.

This sounds like a reason to make it easier for people to edit CSS pages, not a reason to make it harder.

Not funny. If vandals are more powerful here, you do not give them more opportunities.

I do not know why do you insist against all the arguments, and I still did not hear even one argument why this permission can be wrong

A wiki is a site that anyone can edit. It is supposed to have less restrictions, not more.

Enwiki does not allow anonyms to create new articles, as far as I know. I do not trying to change this, because it's not of my business.

In T187729#4057510, @Tgr wrote:

• TemplateStyles CSS pages are handled the exact same way as templates for change tracking purposes;

Wrong, as I explained.

• CSS stylesheet vandalism is no different in impact from inline CSS vandalism (you can do different things, but you can already use inline CSS to take over the entire viewport);

Wrong, as I explained.

• CSS vandalism is more annoying than dangerous, so there is no need to preempt imaginary things, they can be addressed once they have been shown to happen;

We did not talk about this, but if you are, it's absolutely the opposite. It's much more dangerous, because it's invisible in wikicode for a lot of people.

• if someone really insists on access control to TemplateStyles pages, it's already possible with AbuseFilter (although the user experience will be somewhat sub-par). More usefully, it can be used to tag CSS changes from less trusted users for quicker review.

I already explained why it's wrong.

I do not understand in these things as you do, of course, so I'm curious: Why do you not just add a colon to the message original text?

In T187729#4057121, @Anomie wrote:

In T187729#4057089, @IKhitron wrote:

In other words, the points you were trying to make regarding edits to TemplateStyles CSS pages not showing up in recentchanges and watchlists don't actually make TemplateStyles edits worse than normal template edits?

Not at all. I'm saying it's an element of context.

The problem is that you're trying to make development decisions for us.

No, I do not. You should not apply this change to all wikis, just a couple.

You're wanting additional features added to the code. Whether to do so or not is a development decision.

OK, if you say so. Still it would be very nice.

Or, another option you might try would be to add a local abusefilter that checks something like new_content_model == "sanitized-css" & ! "whatever" in user_groups.

I thought about this, of course. But it has some some problems: (1) Not all the edit is vandal, so it's not so right to use abuse filter for this. (2) It's complexity problem. (3) Why to allow open the page to edit and do not allow to edit, in place of make it read only for some users, it will heart in the good ones morally. (4) It's a problem of more than one wiki, and more than one large wiki.

Your (1) seems to be reading too much into the name "AbuseFilter". Which is why enwiki changed all the things they could to call it "EditFilter" there instead.

Sure, but I'm not the boss in this question in our wiki. I agree with your words.

Your (2) would need more explanation. As it stands, it's an empty claim.

As far as I know, abusefilter needs more complexity, because it checks every edit in the world, and avoids some, instead of not allowing some kind of edits, exactly as editinterface permission on mediawiki namespace editing.

Your (3) is a valid point, but given the current state of this task you might have to live with that if you want TemplateStyles on hewiki but don't want to allow "untrusted" classes of users to edit. Or, as I mentioned, you could just insist on not having TemplateStyles at all if that's the tradeoff your community wants to make.

Exactly. I do want have it.

Your (4) is not particularly valid, as other wikis could use the same filter if they want the same restriction.

I meant if it's something local, as bad word on some language, it can be fixed with abusefilter. Something more common can get its own technical solution, as for example url blacklists - it could be added as abusefilter as well.

In T187729#4057059, @Amire80 wrote:

This, again, makes me ask: Were there any actual problems in the Swedish Wikipedia since the deployment? It has now been almost a month since then.

Let's talk next year.

In T187729#4057043, @Anomie wrote:

In T187729#4056984, @IKhitron wrote:

It does appear in recent changes, just as "normal" templates do. And edits to "normal" templates don't show up in the watchlist for a particular page, in exactly the same way.

No. I said with the page name.

If that's what you meant, then the same applies to edits to "normal" templates.

See my next words below.

And edits to "normal" templates don't show up in the watchlist for a particular page, in exactly the same way.

Yes, so again, if it would just this, and not all the context, it would be OK.

I don't understand what you're trying to say here.

I'm saying, that if it was just this sentence, than the state would be exactly as is templates. But this is just one of many characteristics, that creats the bad situation together.

Inline css is always local, inside div or span scope.

I don't want to go into too many details for WP:BEANS reasons, but T10679 belies that at the level most people will care about even though you're right that it's always affecting just the element the inline style is on.

I can give you a problematic code with any css operator.

This seems to be a non sequitur.

Sorry, I do not understand you.

And at the and, guys: I'm not trying to convince you that I'm right and you are wrong. We do not ask to make these restrictions for all wikis. It's just for us, we believe it can be problematically vandal-wise in our wiki, so it is local. I'm sure you can prove me for example that editinterface permission should exist, and you do not force it to al wikis, or should not exist, pick one, and remove it for all wikis. It's an issue of local policy, so please do not make policy decisions for us, exactly as we do not do it to somebody else. Thank you.

The problem is that you're trying to make development decisions for us.

No, I do not. You should not apply this change to all wikis, just a couple.

In which case you do need to convince us that you're right.

Or else, I suppose, you're wanting to block deployment of TemplateStyles to ruwiki entirely because we won't spend development effort to make your demands possible. In that case you don't need to convince us that you're right here, you just have to convince whoever is in charge on T188198: Enable TemplateStyles on ruwiki on 2018-04-10 that the ruwiki community doesn't want it (and that there's no good reason to insist, if they want to insist).

If it was not clear: I'm speaking for hewiki, not ruwiki. We asked the same.
And just afetr the permission I wanted to ask this feture before the the rest wikis, because it's wonderful, not turn it off.

Or, another option you might try would be to add a local abusefilter that checks something like new_content_model == "sanitized-css" & ! "whatever" in user_groups.

I thought about this, of course. But it has some some problems: (1) Not all the edit is vandal, so it's not so right to use abuse filter for this. (2) It's complexity problem. (3) Why to allow open the page to edit and do not allow to edit, in place of make it read only for some users, it will heart in the good ones morally. (4) It's a problem of more than one wiki, and more than one large wiki.

In T187729#4056924, @Anomie wrote:

In T187729#4056782, @IKhitron wrote:

With TemplateStyles, a lot of cases will be for one particular page. Maybe even most.

That seems unlikely to me, although I suppose it's possible. It strikes me as more likely that TemplateStyles will be used for meta-templates like enwiki's mbox family.

You'll see.

It does appear in recent changes, just as "normal" templates do. And edits to "normal" templates don't show up in the watchlist for a particular page, in exactly the same way.

No. I said with the page name.

And edits to "normal" templates don't show up in the watchlist for a particular page, in exactly the same way.

Yes, so again, if it would just this, and not all the context, it would be OK.

Inline css is always local, inside div or span scope.

I don't want to go into too many details for WP:BEANS reasons, but T10679 belies that at the level most people will care about even though you're right that it's always affecting just the element the inline style is on.

I can give you a problematic code with any css operator.

Please, do not quote a part of my words only. If it was just this, it was exactly as in templates. I'm talking about all the context, all what I said.

How is TemplateStyles worse than changing the tags of a template to have non-closed tags that would break the whole layout of the article or adding <div style="display:none"> at the beginning of random articles to make them look empty?

The difference is that if somebody that do not understand in templates or css will see you code, they will open the page at this first line (or fifth, or wherenever the code was changed), to see how does it looks at this particular place. Again, you can't add inline code in line number one, so the change will affect only from the line number one hundred, but look the same until that. It can be done theoretically, but you should have permissions to edit mediawiki:common.css, and the vandal has not.

Great. Now, eventually, I can answer. If you create a template, you use it in many pages. It could be 30, or 30,000, but it's a large number. And if it's 30,000, you protect it. With TemplateStyles, a lot of cases will be for one particular page. Maybe even most. And an edit in css file does not appear in recent changes and especially in watchlist for this particular page. So, most of the people will not know that the page was changed, when css was. And TemplateStyles is much more powerful than inline css. Incredibly more. Imagine that you add a new class with TemplateStyles, "fifth column in table is italic", and add this class name to some table in a particular page. And a year after some vandal adds .references {color: white;}, so the change will not be at the table at all, but in absolutely different place of the page. Inline css is always local, inside div or span scope. So they are not the same, period. And also, it has no sence to protect each css page, much simpler to create a permission. This is why we decided allowing this to autoparolled only (the community minority was against this, and asked editinterface only, but they lost), and a year or three years after, when we'll be more used to this, we'll reconsider, and possibly remove this restriction. Thank you.

In T187729#4055843, @Deskana wrote:

I already explained it. I'll put it more bluntly then: the "security threat" behind this task is imaginary because the styles can be embedded directly in the template. Experienced developers and security experts have told you this already, and now I've told you twice as well. I'm not going to have engineers spend their time fixing imaginary security holes.

In T187729#4055827, @Deskana wrote:

Gergő notes in T133410#4055687 that this task is based on a misunderstanding of the threat model. A security restriction such as this one would achieve next to nothing in terms of security since styles can be embedded directly in the template. Additionally, TemplateStyles has already undergone and passed a security review in T133408.

For the above reasons, this task is declined.

I'm not sure. Once again: When adding the first and the second user, the autocomplete list has names of wiki centrallogin users. But when adding the third user, the autocomplete list includes nine names, that are not users. AutoID, AutoImage, and so on. Looks like the list comes from some program parameter.

See the message I left on the tool talk page. About AutoImage etc.

Now it has no users, but nine values of some enumeration.

Thank you.

Hi, it still does not work in yesterday's deployment. Should it work? Thank you.

Well, after a lot of time without any answer, I'll reopen the task. It still does not work, including in this week deployment. Hope will be fixed soon. Thank you.
@Deskana, @Esanders

Despite a token, I do not believe it will ever happen, because of complexity problems.

Maybe @Esanders? Thank you.

In T32750#4035557, @TBolliger wrote:

@IKhitron Sorry, I wasn't trying to dissuade you. I think your first idea has merit as new feature proposal, but as @TheDJ said we'll need to discuss it further before building them.

Internal links currently work (e.g. [[Cats]]) but external links do not work (e.g. [http://www.google.com cats]) (example). HTML links (e.g. <a href=") probably shouldn't be supported thought, in my opinion.

In T32750#4035505, @TBolliger wrote:

In T32750#4035406, @IKhitron wrote:

Hello. Thank you again for this task. Tell me, please, if I'll fill two more tasks, that are reasonable after both this one, and expanding to 1000 symbols, is there a chance for them, or some of them? I'm talking about:

• Adding url parsing (or at least pure html, with no []).
• Adding wikilink parsing. Thank you.

This would be an unrelated change to this project. You can propose it by creating a new Phabricator task.

In T32750#4035498, @TheDJ wrote:

In T32750#4035406, @IKhitron wrote:

Hello. Thank you again for this task. Tell me, please, if I'll fill two more tasks, that are reasonable after both this one, and expanding to 1000 symbols, is there a chance for them, or some of them? I'm talking about:

• Adding url parsing (or at least pure html, with no []).

This would add additional requirements on communities to patrol, as external links can lead to dangerous destinations. I think the communities would have to provide some serious feedback about the desirability of that, before it would be added.

I see. Thank you.

• Adding wikilink parsing.

I thought [[ ]] wikilinks are already parsed, are they not ? Random example

Sorry. My fault.

Hello. Thank you again for this task. Tell me, please, if I'll fill two more tasks, that are reasonable after both this one, and expanding to 1000 symbols, is there a chance for them, or some of them? I'm talking about:

• Adding url parsing (or at least pure html, with no []).
• Adding wikilink parsing.

Thank you.

Hi, @Deskana, are you sure it's resolved? It's better than before, but still does not work well.

In T90978#4020822, @Kippenvlees1 wrote:

Problem seems to have been fixed. I haven't noticed this error pop up on the Dutch Wikipedia for a few months and found no Global User Pages lingering on the sample I just did on the top 5 wikis. I think this can be marked as resolved.

In T14974#4006494, @cscott wrote:

We're going to make this a child task of {{#balance}} for now, because when we add a warning people are going to want to know what to do to suppress the warning -- and the thing we're going to want people to do is opt in to balancing (to get their desired start-of-line context).

Thank you. Weird. It was recommended us to discuss a year ago, here on phabricator. So, looks like we'll need to avoid TemplateStyles on hewiki, until it will be possible.

In T188287#4002712, @Urbanecm wrote:

Impossible atm

In T187729#3986048, @Anomie wrote:

And if it turns out it's only Russian Wikipedia that wants this, it might be better to add the restriction something like this instead.

No, it doesn't. Hebrew Wikipedia already decided to ask sanitized-css permission be given to autopatrol users only. I'll file a new task in about five hours, after the official finalizing of this decision.

Thank you, I understand. Possibly, it should be changed, but it's not so important to me so I'll start a discussion.

I see your logic, still don't agree. So, before closing the task as invalid, I need to ask - what is the point in blacklist if it can be fooled so easily, apparently in more than one way? Thank you.

Great, thank you, @Deskana!
But it does not look like as it was earlier today. I saw all the lines of the sections in red, and then once again in green.

In T187632#3983096, @Deskana wrote:

Your report is very unclear, so I do not understand what it means.

Please provide exact reproduction steps, and write what you expected to happen and what actually happened.

In T187495#3982614, @Elitre wrote:

If there's really something unclear in my message (your comment doesn't really relate much to what I wrote), you can move this conversation to my Meta talk page or wherever you see fit.

Sure, done, thank you.

In T187495#3980911, @Elitre wrote:

In T187495#3979825, @IKhitron wrote:

In T187495#3979819, @Elitre wrote:

I don't think the line that was added to Tech News about this change is accurate?

I added it, because I found the problem in the first place. What's wrong?

This team is good and consistent in flagging items for Tech News consideration.
Next time, please add the relevant tag to the task, or suggest that is added, so that they are also aware and can help with wording, in case. TY!

In T187495#3979839, @Whatamidoing-WMF wrote:

Neither of these are particularly desirable situations, but other than "don't use {{sfn}}", I don't think we have very many viable options right now.

Oh Boy. Hewiki uses only such references, because of direction problem. Can't fix just the part of previous edits, and drop the ability to see the new ones, created by such templates?

In T187495#3979819, @Elitre wrote:

I don't think the line that was added to Tech News about this change is accurate?

An example for ruwiki: https://ru.wikipedia.org/wiki/%D0%9E%D0%BA%D1%81%D0%B8%D0%B4_%D1%86%D0%B8%D0%BD%D0%BA%D0%B0.

By the way, I saw such generated references in other wikis too. Ruwiki, and even enwiki, something with CS1.

Thank you.

In T52769#3975407, @Esanders wrote:

Can you link to an example?

Sure:
https://he.wikipedia.org/wiki/%D7%90%D7%93%D7%99_%D7%A7%D7%91%D7%98%D7%A0%D7%A8?veaction=edit&uselang=en

Hi. Our wiki does not show any references in reflists at all in VE now, the list is empty. All of them are created by reference template, rather than by tag. I was not sure it's new indeed, because I do not use VE, but people say it wasn't like this before.

I have no idea how to do this. I saw it in Datawiki revision 658328957, a lot of time ago. it's not on recent edits any more.

Do you mean, @Anomie, that every edit I make on some Wikidata item adds me to all wikis that have a page connected to this item? In a month all users will have 902 wiki accounts.

I still do not understand, @Tgr. Could you tell me, please why exactly these wikis are in my account list now, nevermind when were they added? Thank you.

In T186629#3964541, @eranroz wrote:

1. The URL in the recent changes points to wrong URL

I can't reproduce it (looking on Special:Logs/move to find recent moves, and looking for the relevant "Language link changed from $1 to $2" messages - seems like those are correct links. I guess this was due to different versions(?) but anyway this is not reproducible/invalid.

In T186629#3963738, @thiemowmde wrote:

Can you please help us understand the issue better? At the moment, when I look at the given example page https://www.wikidata.org/wiki/Special:Diff/627491344, I can not find a "wrong" URL anywhere on that page.

Hi @thiemowmde. I do not know when @eranroz will return to this page, so I'll answer you partially. I found the problem in the first place and told him, still I do not understand in Wikidata mechanics.
The Diff link you gave is not relevant for me, do not know aboyt Eran. I am talking about local wikipedias with "view wikidata changes" on.

In T186977#3961115, @Tgr wrote:

T186945: Message welcome bots at local wikis trigger due to edits at Wikidata assumes that the cause is the wikidata edits which are propagated to recent changes of other wikis via sitelinks. In IKhitron's case the account creations do not seem to correlate with his Wikidata edits, though.