Dealing with JS/CSS resources is no longer sysop business.

• It is up to IA to decide what shall happen with sanitized and deleted code.
• If you do not want a page to be deleted do not ask for deletion.

Dealing with skin resources is no longer sysop business.

• It is up to interface administrators to handle JS/CSS pages.
• The ability to delete JS/CSS pages was left to react on threats as quick as possible, e.g. privacy violation via beacon just discovered.
• People should think twice before asking for page deletion. Once something was deleted it always needs further explanation and requests to get back content which might be copyvio or legally questionable or harrassment or TOU conflict or whatever. It is up to interface administrators to decide upon JS/CSS page content.

It is the intention of this procedure:

• Every regular sysop may delete malicious software immediately.
• A sysop account may be hijacked, somebody may be persuaded to undelete or to forward the bad code. All misusing pages could be exploited then.
• Once the code page was deleted experienced staff has to be asked for undeleting or even copying presumable malware, investigating thoroughly first.
• Recovering malware is doing harm. A suspicious resource which is unavailable for a couple of days until checked and released again does not cause any damage, it is just a tool being temporarily unavailable.
• If there is no good reason, a sysop should not delete pages.

UPDATE 2020
Within the recent five years two more aspects arrived:

1. CSS selectors
2. TemplateStyles

• For generation of any URL, both internal and external, %2E in <a href="...%2E"> would be sufficient. It will be copied by context menu mechanisms as-is and hide the dot from any mail client and office program, whichever URL might be mutilated otherwise. However, that is the same URL as before.
• For our pages themselves they should declare their own URL by appending _ which will be kept in address input field of the browser and may be copied there. If wiki server is called with superfluous _ that is removed anyway.
• On footers, by Special:CiteThisPage etc. the URL of this page, if any, shall be propagated as %2E terminated, but currently ending with digits anyway.

At least there should be a global dictionary for selectors, even if no CSS implementation is delivered.

• German Wikikipedia calls that thing .deviceProperty-not-narrow, another Wiki might define .nohandheld and a third one is using .nosmallmobile as selector.
• This is affecting exchangeability of templates, gadgets and page programming components.
• If there is no global CSS implementation distributed on all pages, every project which likes to use that can specify an implementation by site CSS (MediaWiki:Mobile.css or via MediaWiki:Minerva.css) or TemplateStyles on pages where such elements occur.
• The target is to focus on the main track of the story, if there is a lack of space on a small device. Decorative nice images, the joke of the day and distracting gimmicks shall be omitted. Looking at https://www.mediawiki.org/wiki/MediaWiki the photo is superfluous and does not solve the problem of the visitor, show it on desktop and tablet, but do not fill the entire first screen of a handheld.

The failure first.

Okay, thanks for your efforts.

This may be a misunderstanding.

In T237700#6169065, @Esanders wrote:

If they are obliged to sign with every small wiki individually, they might get problems to track their business distributed over 100 small wiki user talk pages.

You can just turn your local talk page into a soft redirect to the desired one. We also have global notifications now.

In my home wiki I could help myself: Template:WikiLayout/styles@dewiki

• However, that goes for my own wiki only.
• I am heading for a global solution for 1000 WMF wikis and outer space.
• That is what Phabricator is for.

“encourage TemplateStyles adoption”

• That is putting quite a lot of efforts on source editors.

Please compare:

[[File:note.png|class=nomobile-narrow|16px]] NOTE:

with

<templatestyles src="WikiLayout/styles.css" />
[[File:note.png|class=deviceProperty-not-narrow|16px]] NOTE:

The latter is local only, my proposal could be exchanged among wikis.

German Wikipedia does not want that threads in a talk archive might be continued.

• Talk archive pages are in the related talk (or other) space.

Are these pages marked in anyway that would let us know they are archived?

There are various templates, but all of them use both __NOEDITSECTION__ and __NONEWSECTIONLINK__ to prevent thread editing by accident.

German Wikipedia does not want that threads in a talk archive might be continued.

• Talk archive pages are in the related talk (or other) space.
• Talk archive pages are marked as terminated by any archive template and those request explicitly __NOEDITSECTION__ and __NONEWSECTIONLINK__ to prevent thread editing by accident.

DiscussionTool must not invite to reply in a terminated thread.

Strongly opposing.

Well, MediaWiki's Language class is expecting internal queries within PHP infrastructure only. There all codes might have been doncased already.

Thanks. BTW, you might check the heading comment of rMW/ maintenance/markBadBlobs.php – it looks like copied from rMW/maintenance/cleanupImages.php and is bearing wrong purpose, several brion, and 2005-2006.

Please consider a link to a user page with the same nick but a different wiki.

• Imagine a steward or a small wiki support hand. They might link to a user or user talk page at meta: or at their home wiki.
• If they are obliged to sign with every small wiki individually, they might get problems to track their business distributed over 100 small wiki user talk pages.

A main user page or main user talk page should be linked at least, not only subpages. That goes for version history and transparency; it would be easy to channel all complaints into a subpage, then request deletion of the subpage and keep a clean main user talk page version history. German Wikipedia has specific rules on deleting main user talk page (never deleting, might be moved, but moving can be tracked).

Well, the first guess does not change any page:

• If namespace is even and 2, 4, or >90 and there is NEWSECTIONLINK but no NONEWSECTIONLINK then regard this as a forum.
• If namespace is odd and there is NONEWSECTIONLINK then do not permit to extend a thread.

The new keywords to equip rare exceptions where the guess fails may be introduced at a later stage. Therfore no page can be changed for those now.

That might happen by incident, but you cannot prevent on millions of pages that people introduce inappropriate syntax, declare a regular article as disambiguation page or empty the entire content. Projects are patrolling on a regular base and fix such mislead stuff, or search and rescue the John Hopkins University once a quarter.

Well, it seems to depend on browser technology.

• Your example browser is ignoring the orphans/widows rule. They take the wording avoid too seriously.
• I learnt Firefox is not good at this for now.
• https://caniuse.com/#search=orphans
• I recall a browser which divided the S properly as expected, but I forgot which.

The development is proceeding; we should revisit this every spring.

• At least there was progress in keeping things together since 2015.
• Now we are grizzling that it is kept together too much, we want it to get split again.

In T245890#5951850, @Alsee wrote:

The magic words would each override the namespace.

They should be able to override the guess.

• However, the guess should be taken from both namespace and NEWSECTIONLINK (NONEWSECTIONLINK) to avoid tremendous insertion of new magic words within existing pages.

But yes, as I suggested above, a __NOTALKPAGE__ might revocate continuation of closed discussions in archives, and NOTALKPAGE should override EXPECTTALK and namespace and any other.

Nowadays it may be overcome by applying

.mw-category-group {
   break-inside: avoid;
   break-inside: avoid-column;
   page-break-inside: avoid;
   page-break-inside: avoid-column;
   -webkit-column-break-inside: avoid;
   orphans: 3;
   widows: 3;
}

including some fallbacks for CSS2 and older or less smart browsers.

There is a magic indicator: __NEWSECTIONLINK__

That’s entirely right. For a single image (like an icon) the effect is the same.

(+) Some Screenreaders do generate a TOC already from document headlines in the same way as MW does.

Well, on a wiktionary only pages in main namespace are SENSITIVE_ALL, but templates and categories do behave like every other wiki.

Just a reminder:

• The Flag needs three states:
  • IGNORE
  • SENSITIVE_ALL
  • SENSITIVE_2ND or IGNORE1_SENSITIVE
• For hastemplate: and incategory: IGNORE1_SENSITIVE is appropriate.
• On a Wiktionary, linksto: is SENSITIVE_ALL for main namespace, but any other linksto: is IGNORE1_SENSITIVE.
• Common text search is IGNORE.
• When accessing the database tables, it is no problem at all, capitalizing first character of the title part (not namespace) will deliver IGNORE1_SENSITIVE entries.
• There are config variables indicating which page names might need SENSITIVE_ALL.

Strong support for scheduled termination.

• It is not a good idea to maintain current doublespeak in eternity. One day this has to be discontinued.
• It has been discouraged for a couple of years now, it might be 2021 when support for source ends.
• Throwing a maintenance category for a year is a low level action to give opportunity for a smooth change of affected pages.
• It is most confusing in a syntax description that one thing known with an entirely different meaning is an alias for something with another major identifier.
• Even more if <source> is occurring within the displayed HTML code.

German Wikipedia migrated soon after renaming all encyclopedic articles and active project pages.

• Some recent C&P from enwiki, some user pages or archived discussions might still use source but can be cleaned up by bot easily.

The localized version is inserted, e.g. Datei: or Fichier:.

• Localization is blocking C&P transfer into other language wikis.
• German Wikipedia is removing the namespace name by JS tools when source code is edited to enable smooth exchange with other wikis.

The namespace name is redundant and superfluous in gallery and has been a less smart concept there.

• Nothing else than a media ID is permitted at this position, and therefore it is pointless to ask whether it is called Image: or File:.

VE etc. must not insert any namespace name.

• It is cluttering diff and disabling interwiki exchange. At least confusing, no benefit.

This task stalled.

Ages ago I wrote editorContent which might help for the time being.

• I do not know whether it still works, please complain if not.

The nasty thing: While JS and CSS can be recognized by so-called extension, and will get a content model by system, lua code in user pages has no content model nor .lua termination and is difficult to identify.

1. I am a volunteer developer on dewiki and I created a pile of JavaScript tools and Lua modules applicable to any wiki in any language.
2. Basically I am happy.
   1. I am about ten years on this drug.
   2. I created all tools I need, and some are running private, some are made available to everything under MediaWiki.
   3. What slows me down are some users in my own community, but there is no remedy on any conference.
3. What we could need in the long run would be another edition of TechNews; in developer mode, or perhaps focussing on JavaScript, Lua, API, parsing & maintenance categories & LINT, toolforge, VE etc.
   1. The broader and translated TechNews on a weekly base is too much information for me; most things I do know already or I do not need at all. It is too long for me and explaining too much; it is heading towards another auditory and I did not subscribe. Information overflow.
   2. An English only newsletter for developers in a particular field on important occasions like breaking change, deprecating public functionality etc. might improve communication, with short notices for experts (legacy function mw.util.grandfather() deprecating from now, see phab:T1999). Since narrowed to JavaScript, Lua, API those subscribers only will be fed and not bothered by other fields. And if there is nothing worth to broadcast over months it is fine and does not cause work.
   3. The Project News on dewiki are maintained now for a dozen of years, and I can watch this and I am precisely informed, if the editor does not fail to include something which is important for me.

This task has been sleeping for more than three years.

Yes, indeed, somewhat duplicate but might change course towards Lua which has not been known 2011 in T33439.

In T189095#5410402, @cscott wrote:

This was an intentional change to make preprocessor behavior more uniform.

This time a regular article page, no JS nor user page.

Yeah, everything fine now.

Just look at the gallery page. That one is maintained and updated. And only that one. Forget all categories and the double amount of icons which have been official OOjs icons two years ago, and might be recovered next month again.

It is disturbing the watching users (who are supervising bot flag edits) and is blowing up the version history.

I am the guy who initiated in 2016 the porting of the icon collection, persuaded a script runner to create the first pile of 1000 icons, and I added manually several hundreds of changed and added icons. I also refactored the gallery.

You split the discussion on two Phab tasks, while it is actually an issue for the Commons talk page. Therefore I am forced to comment here once again.

The naming is from 2017, and all icons received meaningful and systematic names when the files were created. At that time, the name has been correct.

Slot issues should be considered as well. That is rather complex for parser functions which are the approach of a decade ago. Lua should get access to a table of slots with revID, user, timestamp, size for the most recent and the first undeleted revision. From that the calendar details like month2 and day may be derived and any local formatting can be done as required.

In T179154#5330292, @Iniquity wrote:

Just for example what we are having now:

https://commons.wikimedia.org/wiki/File:OOjs_UI_icon_edit-ltr-progressive.svg	https://commons.wikimedia.org/wiki/File:OOjs_UI_icon_alert-destructive.svg
https://commons.wikimedia.org/wiki/File:OOjs_UI_icon_edit-rtl-progressive.svg	https://commons.wikimedia.org/wiki/File:OOjs_UI_icon_alert_destructive.svg

Or at least a Lua access in the Title object. Then everything else may be derived by programmers, and no further parser functions wil be required. Lua people would like to get access to both current and creation revision information anyway. If Lua knows, templates may be supported by utility.

It is a bit strange to discuss Commons categories outside of Commons. Usually the talk page is used there.

I do propose a different name for the entire project rather than Homepage.

@Kipod: You may have a look into JSONutil@dewiki, check the examples provided at JSONutil Test, use the JSONutil.fetch(source,true,"he") function for now rather than mw.text.jsonDecode(source), clean up all obscure syntax from your wiki by maintenance cat step by step (the dubious syntax won’t survive the next decades, one day you will need pretty syntax anyway); and a Hebrew translation at commons:Data is welcome.

Caught on BETA, but might help here.

• I understood that External Storage is used to store text blobs of productive WMF wikis.
• Perhaps some entries in mapping tables are corrupt.
• The following error report would result from a problem in the other direction.

Apparently // or /* ... */ comments were accepted but not by PHP7, if I observed correctly.

In T227872#5328785, @matmarex wrote:

As a side note, the languages menu is duplicated within the site content. While this seems a bit weird to me, it does provide an accessible alternative to the normal menu.

Uhhpff. I did not find that, but I did not read the entire page with all details down to bottom and scrolled quickly. However, it is important that the opportunity is shown in prominent position and ARIA-marked for those who cannot see it. The blind Spanish visitors will appreciate that.

As recommended above, I did open T227872 for the language selection dropdown issue.

I do confirm that the 2018 state has been present end of June, beginning of July 2019.

• The Code of Conduct issue in this task with ban for unspecified durance triggered by a 4Lword came up to my mind in the similar FRAMBAN case.
• I checked this task and the homepage several times.
• Congratulations, it took almost twelve months to publish a simple fix.

Now we have a different issue, if a am not tricked out by some script blocking?

• In the upper right corner there is a language selection gadget icon.
• The drop down option list is disabled by: display:none
• Either I make both option list and selection gadget disappear, or I would enable both.
• Once again a deliberate and intended design decision by the department for higher reasons.
• I guess in 2020 we can revisit that page and see the selection working

In addition a kind of query for namespaces is needed.

• Who has a partial block on templates, modules, article main space?

Additional note on trailing garbage:

• Recent PHP apparently stops analysis when opening bracket { has been matched by closing }.
• PHP7 JSON does not return any result if closing last } is followed by non-whitespace data.

Even more, unbalanced (missing) terminating } at end of data seem to be granted by lazy PHP while strict PHP7 is insisting upon correct assignment.

I am in doubt that magic automatic device detection is a safe way.

• I understood that people are using Timeless skin on smartphone and tablet. Who knows future size and resolution of mobile devices? They will be thrown to Minerva after each click.
• I view quite often pages in the m. domain from regular desktop business to check appearance. The first link might be initiated by some &usemobile=1 but this mode needs to be preserved until I decide to leave the mobile emulation.
• Some might regard their tablet as desktop and use a desktop skin. Others will use the identical tablet as mobile device and prefer Minerva style. How to configure if there is an automatic decision made by server?

For the record: success on 2019-07-03.

T227033 is reporting a similar issue, first observed about 27 June 2019.

I think it should be left to the user.

We should stick to multiline relaxed strings, while regarding superfluous comma and apostrophe delimiters as errors.

In T225599#5252734, @Aklapper wrote:

Users are made aware. https://foundation.wikimedia.org/wiki/Privacy_policy covers this and is linked from the bottom of https://tools.wmflabs.org/interaction-timeline

While every other tools.wmflabs.org acess is hiding private browser fingerprint from tool developer, this one is using a hidden mechanism to record IP address and full browser profile by clandestine means.

• Every tool developer may log all queries, recommended for tool improvement and error detection, but that will include just timestamp, all query parameters, and some general browser characteristics.
• For identifying user groups, containing almost one person, the anonymous browser characteristics are sufficient and available to every tool developer.

The approach here gives the full IP data and complete browser and hardware and preferences and cookies and private information to unknown readers.

• InteractionTimeline is used to spy on users suspicious to be sock puppets. Now everybody who is using that tool is subject for identification which physical user, identical with which Wiki account, is looking at such questions. It can be monitored which Wiki account is interested and expecting which other Wiki accounts are connected. I feel reminded to a Big Brother authority.
• If such secret service means are built in it is necessary to make every user clearly aware that they are tracked and identified more than usual and expected. The general disclaimer on every WMF page does not tell that.
• In T187374 task description I fail to see any explanation why it is necessary to identify every single individual rather than recording the browser access data, which is almost unlikely to be shared by two tool users.

Persisting:

[XP6iKApAICIAAJV-xuIAAACS] 2019-06-10 18:32:10

At least no temporary DB lag.

https://de.wikipedia.org/w/index.php?oldid=5780804 reported last year:

Interner Fehler [W9n5NApAMEoAAJqHzzYAAABM] 2018-10-31 18:49:24: Fataler Ausnahmefehler des Typs „MediaWiki\Revision\RevisionAccessException“

Not convinced of my uselang statement any longer, cannot reproduce details and URL.

Thank you for now.

Well, the use case is that I want to edit those pages which transclude the redirect, in order to modify template name and old parameters, rather than pages transcluding the generic template name where new parameters are already used.

Thank you for your edit but you missed that one and also upstream notification which will trigger downstream dependency one day.

I count 88 pages in elwiki:Help: (including 14 redirects), but 900 pages (including many redirects) just as top pages in dewiki:Help: which indicates that there is an intensive usage in one project and a more relaxed in another wiki, and there might be projects with almost no helpful page in Help: namespace.

In T221892#5168211, @matmarex wrote:

But another idea was proposed – why not just move the sandbox page to a namespace where VE is enabled? The 'Help' namespace seemed like a good candidate to us.
Do you think that could be an option?