Collapse initially on small windows, e.g. phones.

I did not make any search, but e.g. this one came to my mind. There is nothing about to be called as it's probably broken already but a usual implementation, especially within a “global template” which is distributed automatically on all depependant wikis.

No need to make a global search on 982 WNF wikis.

Oh, sorry, I forgot: In Lua there is mw.site.siteName – how do I read this proposal on that issue? And the broken Lua modules relying on that constant? Or using a different identifier than for parser function?

Please note that there is also wgSiteName in the JavaScript environment, as by mw.config.get("wgSiteName").

This is a breaking change killing any

{{#switch: {{SITENAME}}
  |Wikipedia=encyclopedia
  |Wiktionary=dictionary
  |MediaWiki=development coordination
}}

There is also {{SERVERNAME}} which yields www.mediawiki.org right now. Next one will complain that it is confusing the new SITENAME is a domain name as well.

The following system messages are required:

• revreview-editnotice
• revreview-pending-basic
• review-edit-diff

Actually, it is a browser bug.

Okay, it was not clear what will happen and what is supposed to happen when we pass the line.

In T273873#7812738, @Pols12 wrote:

Sometimes, we might also want variable/function names to be translated
Strings could also be localized (e.g. they are often translated on PHP manual).

This feature was added so we have a native implementation that is similar to LintHint, but requires no special efforts on the editors part to setup and use LintHint. LintHint can also add more features that we arn't able to add for various reasons.

What features of LintHint can not be done and why? Particularly, some highlighting or indication of all on the page?

As inventor of lintHint I guess:

• Cleaning a pile of errors within a single source edit.
  • That is what has been mentioned above: On multiple problems clear the last one first, then going upwards to start of text.
• Automatic messaging if there is a problem within a visited page, even if not viewed for lint processing (option for frequent cleaners).
• Re-analyse intermediate states of a source editing area, e.g. after removing a bunch of errors and check whether all gone.
• Linter analysis after large regular edits before saving, to ensure that no new errors have been caused.
  • I terminate editing usually with lintHint as last action before saving when I made larger modifications.

There may be more tasks supported, but those are the most common ones.

User request #1 is connected to preference watch every page I am editing.

https://de.wikipedia.org/wiki/Template:MediaWikiGadgetPage is prepared to support namespace independent page links now.

The transcludes= is much safer than any suggestion in this task or any other.

Another but safe approach tailored for this desire has been specified in T204201 by either transcludes= or a bit more risky categories= condition available to interface admins only.

Users in projects without interface admins might want to export, check, control their offered gadget preferences, but they are not able to edit them. They will need global help.

Warnings on Special:Gadgets are confusing and frustrating for regular users since that audience is not able to take action. If these messages are displayed over years nobody will take care about any warning.

Gadget IDs are to be registered globally; see T117540. If a local site is using the same ID for another purpose maximum confusion level is reached anyway.

In T204201#7616924, @SD0001 wrote:

BTW, you will need two URL calls, one for JavaScript and one for CSS.

No, unless you use &only=scripts or &only=styles filters, the same call includes JS, CSS and JSON (and messages).

Well, I am to retrieve for appropriate content model:

• mw.loader.load( URL&only=scripts" );
• mw.loader.load( URL&only=styles", "text/css" );

And please correct me if I am wrong, but from my experience load.php?modules= does not include or request dependencies nor messages. It is just the bundle of its own resources.

I guess it will work, but I stated no official support for cross-wiki usage of gadgets via URL yet.

It is hard to find a definite list of action= since those may depend on extensions and vary over time.

• action=markpatrolled – Extension business, not activated in every wiki project
• action=deletetrackback – valid but not active in WMF
• action=dublincore – valid but not active in WMF
• action=creativecommons – valid but not active in WMF
• action=credits – valid but not active in WMF
• action=parsermigration-edit – has been valid but pointless today

The gadget is composed of multiple .js .css .json resource files.

• Some resource files may be shared between various site gadgets and user scripts, even from other wiki projects.
• Every gadget resource should ensure that dependencies are satisfied, otherwise request now; and if conditions for namespaces, action, special page are necessary, they shall be checked again.
• If dependencies are provided already per package, the RL will just confirm and continue; if missing for any reason they shall be loaded now. If why ever the code is executed within inappropriate context it should stop and might log an error message.
• Gadgets-definition should provide efficient pre-loading of resources and dependencies by package, and start site gadget automatically only if meaningful. That is supported by this definition within local site.

Every useful gadget may be called from an external wiki. In this case, no Gadgets-definition is present, and there is no official support for cross-wiki usage of gadgets via URL yet.

• Users might start gadgets not on preferences setting automatically when wikitext page is loading, but interactively on individual request when clicking a button, or in more restrictive user defined situations only, e.g. no other than articles.
• Since no Gadgets-definition is in effect then, no code can be sure that it is never called rather than by site mechanism.
• Good and robust gadgets always assert that dependencies and context match expectations, otherwise take suitable action, e.g. load missing modules now, or terminate if nothing to do. They simply work fine with no complaints ever under all conditions.

The list might be overwhelming.

I am not happy with the viewpoint suggested by {{#env:}} or {{#var:}}.

On Invalid page actions specified: The set of possible actions is unlimited.

• Once there has been a parsermigration-edit.
• They do no harm.
  • If they are mentioned, but nobody ever is running a URL with that action they have no effect.
  • If somebody misspelled edti the gadget will not start and this will be discovered quite soon.
• raw is a valid action but it is hard to imagine a meaningful gadget operation.

I am thinking in three levels, and I could imagine that all three will be available one day:

• global
• site
• user myself

I would expect in Preferences that all three chapters are offered in future. However, I am not sure which century. The generation of entries in Preferences is identical for all three origins. However, global specifications will need translatable texts.

Basically, I would expect another syntax for gadget identifiers similar to page names:

• commonswiki:HotCat

A mw.loader.load("commonswiki:HotCat") will request the identical module bundle as has been specified within host wiki.

• It is not really the business of other wikis to configure how to access particular resource pages at .js .json .css or whatever level.
• The other wiki will be responsible to maintain the package specification.
• It is obvious for RL how to resolve the request into a resource module from that wiki. All requests from that wiki might be collected and merged into one cacheable multi-module URL for that wiki. This is the same as for resources from current site. It might be even shared in browser, since the URL is identical for a request from own site and when visiting another wiki and asking for the same bundle.
• Somebody might offer a (hidden) library gadget which could consist of just one .js resource page only if that is a universally useful script. It will be installed and executed as everything else.

A user defined GadgetDefinition sounds interesting.

Yeah, in January 2020 it has been made a step forward by closing the call for comments.

I think it should be reconsidered every couple of years.

• It needs to be investigated whether this is common practice today and we should provide that. Basically also a “webmaster” is to be contacted somehow.
• The individual wiki page is not affected, but a single file per WMF subdomain or just domain could be accessed which may all be redirected to the one and only definition specifying an e-mail address and perhaps Phabricator security report procedure.
• If we could improve security at low cost which is quite easy to maintain we should do that one day. If security detection bots are expecting such URL we might serve; if not commonly used we can postpone it some years agein.

Thank you for your hint. I think it should be considered.

• It needs to be investigated whether this is common practice today and we should provide that. Basically a “webmaster” is to be contacted somehow.
• The individual page is not affected, but a single file per WMF subdomain or just domain could be accessed which may all be redirected to the one and only place specifying an e-mail address and perhaps Phabricator security report procedure.

There are three issues which are mixed and confused in this task. They should be distinguished clearly.

The outcome of <hiero> shall reproduce the same graphics as written milleniums ago.

Yeah, I do prefer __ARCHIVEDTALK__ as content based, and any software in the next centuries might decide on appropriate behaviour.

Tech News: 2021-32 made it better for .visualClear

• The message was clear and obvious.
• Some three pages needed to be updated.
• Fine.
• No gadget programmer involved.

Not all JavaScript maintainers are permanently active and check every line and every word of every Tech News.

In Tech News: 2021-18 issued beginning of May 2021 I found now an inconspicious sentence amid of a longer statement:

I cannot create articles occurring in such maintenance categories, nor other pages, since our maintenance team will remove that immediately.

I cannot reproduce this: https://www.mediawiki.org/wiki/User:Mainframe98/Sandbox#Phab:T280766 (nor on the beta cluster).

Since a couple of days, elements marked as noticeable error are no longer appearing in red text color, with frame in red color where requested, in enlarged font size.

I hate to repeat myself.

Who will do the job in replacing that in thousands of arcticles and many templates?

Questionnaire back:

• If you make a questionnaire in the backyard of Phabricator, where nobody will take notice of that, why are you not waiting for answers?
• If you make a questionnaire on “Community expectation” why are you not asking via Tech News and village pumps of some major wikis?
• If you make a questionnaire on “Community expectation” why do you not wait for any answer but remove the feature immediately?
• If you plan to follow a new strategy what has been so darely urgent that you cannot wait for answers after broadcasting your questionnaire to the communities, to get something removed within a few days which was present for a decade?
• If you plan to follow a new strategy why did you not check en:Help:Table first, where this has been advertised since 2016? Why did you not check mw:Help:Tables where the enWP is recommended for more details? Why did you not make a simple Cirrus search on enWP within all namespaces? Why did you fail to make any investigation first before removing this feature?
• Since you watch your steps carefully why did you fail to make an announcement in Tech News first and require removal of a feature propagated for many years and used rather widely in various projects? Giving time to communities to update their content and templates? Did you ever hear the term “migration”?
• Why are you making a breaking change without being aware that this is a breaking change?
• Who else than you personally has made the decision to remove this feature? Why did the reviewer fail to check whether this can be removed without disruptive change? Who authorized you to make such decisions as a single person, and without the necessary investigations first?

On the historical question about Who did permit projects to use this feature (“It appears they are used in wikitext, but this was not documented in the code.”):

• English Wikipedia documented the class in 2016.
• German Wikipedia documented the class in 2012.
• mw:Help:Tables #See also refers to the more elaborated enWP help page right now.

The expectation of the communities is that this is a feature supported on any page without any precaution.

It refers to the suggestion to use TemplateStyles for equipping of a particular table. However, nobody can introduce a class table-something without the risk of collision with other specification of the same class name but other effect in global things.

Please note that all efforts with TemplateStyles always need a collision-free class naming policy.

• No class name of one local TemplateStyles page must conflict with any other in the same project.
• No class name of a TemplateStyles page must collide with a global MW class name.
  • Please note that not all MW classes are preceded by mw- prefix.
  • There is no dictionary of all basic MW classes available, nor an explanation of promised effect.
  • Nobody can check whether the same class name is reserved for MW purposes already.
• For exchange between projects, gadget usage and so-called “global templates” and “global modules” a global registry of class names is required first, to ensure that a local class name will not collide with another one, and the same class name will have a similar and expected effect when copied into a different project.

I answered at mediawiki.org and it is not really a MediaWiki problem.

It is an issue who will monitor edits in which namespaces and trigger tagging.

• On global level this is soemthing around parsing, or similar to mentioning users (notification).
• On site level a cloud tool would be required, which could listen to changes on all WMF wikis.
  • That cloud tool could maintain a database which keeps track of all media identifiers, both site local and commons, via pageid to be robust against file moving.
  • A database could provide image descriptions in a particular language for other pages with transclusion of the same image.
  • Editors could use the text from another page, or use it as base for (automatic) translation and refining in the own language.
  • A JavaScript gadget may be written to be triggered by blind people which would equip the HTML document by alt texts if database knows any image description in an appropriate user language, or might try to provide an automatic translation on the fly.

Tagging edits as requested in this task is not the solution for the goals. It might be one single piece in the jigsaw puzzle for one particular approach. It is not really required. Tagging itself is no solution, and it is pointless without other tools to set the tags, and to evaluate tagged edits.

If at least one tag has been established, revision history will be displayed with an additional checkbox for each revision since registered users will be able to edit tags for this revision.

This should be done on global level, if ever.

It is confusing to use well defined HTML elements for something different.

This is simply not true. The following post has opened a doubled thread for <resourceloader module="ext.gadget.mybookgadget" /> here.

The comment before is cross-posting at T241524 so I feel free to answer by C&P here as well.

• The proposal is also creating a risk of undiscovered vandalism.
  • Malicious users, even every anonymous user can trigger all available gadgets and increase client load of all visitors. Since not useful in current situation, no gadget will have any visible effect and attack may be detected years later.
• It is not clear what is taken precedence over explicit user opt-out. Will the proposed element override user option?
• There are not many templates which have a reasonable connection with a specific template.
  • A template for coordinates may trigger the local adaption of WISWOSM. That can be administrated by the new syntax of T204201 and narrow such gadget calls to pages where coordinates really occur.
  • If a gadget is related to a particular template it is up to inventors to tailor the usage precisely that transclusions and gadget loading are matching well.
  • It is even possible to define a dummy template which creates no wikitext output at all, and has the one and only purpose to trigger gadget loading. That is exactly what the proposed new element shall do, but limited to exactly those gadgets which are defined for such assignment.
• There will be only very, very few templates which are related to a gadget.
  • The total number of gadgets is not very large, and it is an exception that a template is related to a possible gadget in that wiki.
  • There is not a huge number of applications with relation of content and JavaScript. Table sorting, collapsible elements. Those as well as extensions like Graph and Kartographer are under MediaWiki control.
• Management of gadgets shall be kept limited to interface administrators by maintaining Gadget Definitions specifications.

This entire proposal has high risks of misuse. It has no benefit which would not be available via extended Gadget Definitions, but creates double work and complicated additional framework for a single exotic purpose.

• The proposal is also creating a risk of undiscovered vandalism.
  • Malicious users, even every anonymous user can trigger all available gadgets and increase client load of all visitors. Since not useful in current situation, no gadget will have any visible effect and attack may be detected years later.
• It is not clear what is taken precedence over explicit user opt-out. Will the proposed element override user option?
• There are not many templates which have a reasonable connection with a specific template.
  • A template for coordinates may trigger the local adaption of WISWOSM. That can be administrated by the new syntax of T204201 and narrow such gadget calls to pages where coordinates really occur.
  • If a gadget is related to a particular template it is up to inventors to tailor the usage precisely that transclusions and gadget loading are matching well.
  • It is even possible to define a dummy template which creates no wikitext output at all, and has the one and only purpose to trigger gadget loading. That is exactly what the proposed new element shall do, but limited to exactly those gadgets which are defined for such assignment.
• There will be only very, very few templates which are related to a gadget.
  • The total number of gadgets is not very large, and it is an exception that a template is related to a possible gadget in that wiki.
  • There is not a huge number of applications with relation of content and JavaScript. Table sorting, collapsible elements. Those as well as extensions like Graph and Kartographer are under MediaWiki control.
• Management of gadgets shall be kept limited to interface administrators by maintaining Gadget Definitions specifications.

This entire proposal has high risks of misuse. It has no benefit which would not be available via extended Gadget Definitions, but creates double work and complicated additional framework for a single exotic purpose.

Do one thing, and do it well.

• Please use a class mw-page-position-top.
• That does say: This block shall be arranged before introduction section.
• Nothing more.

Those local ambox and hatnote and infobox are decoration classes. They define how this particular wiki is decorating things. That is not a statement on the exact position where to arrange it in a page.

• Structural global semantics are one thing.
• Local decoration is something different.

The ambox and hatnote are providing a particular decoration. They were never limited to certain structural declaration and effect on order of elements. Those are definitely the wrong class names to introduce a new capability. Nobody knows which templates in 1000 WMF wikis are equipped with such classes and which expectation and usage are supposed there.

I don’t think that this proposal should be implemented. It is a rather hard break in usual cooperation of interface, page content and JavaScript gadgets.

• T204201 Extend MediaWiki:Gadgets-definition capabilities would solve the JavaScript loading issues much better. It serves much more cases and is flexible enough, e.g. by loading JavaScript if a certain template is transcluded.
• Introduction of new <elements> will destroy the separation of HTML content, as provided by wikitext, and JavaScript which is part of current interface and basically independent of HTML. CSS is quite close to HTML presentation.
• Gadget administration should be done in a central place, not scattered over source code of templates or even articles.

I don’t think that the recent proposal should be implemented. It is a rather hard break in usual cooperation of interface, page content and JavaScript gadgets.

• T204201 Extend MediaWiki:Gadgets-definition capabilities would solve the JavaScript loading issues much better. It serves much more cases and is flexible enough, e.g. by loading JavaScript if a certain template is transcluded.
• Introduction of new elements will destroy the separation of HTML content, as provided by wikitext, and JavaScript which is part of current interface and basically independent of HTML. CSS is more related to HTML presentation.
• Gadget administration should be done in a central place, not scattered over source code of templates or even articles (book content).

Yeah, I guessed something like that from a few examples, but they had various causes.

Do one thing, and do it well.

• I did suggest a class mw-page-position-top.
• That does say: This block shall be arranged before introduction section.
• Nothing more.

Those local ambox and hatnote and infobox are decoration classes. They define how this particular wiki is decorating things. That is not a statement on the exact position where to arrange it in a page.

• Structural global semantics are one thing.
• Local decoration is something different.

MediaWiki might publish a global Style Guide for such issues.

• Then projects do need 12 months at least to implement all such features.
• All class names are to be prefixed by: mw-
• A global dictionary of selectors exposed to the public and supposed to be utilized should be distributed immediately by MediaWiki design department.
• A .mw-page-position-top can be applied where desired then.

It is not acceptable to take the local customs of enwiki and use them as unpublished global standard for 1000 WMF wikis. This is a kind of cultural domination and patronizing style which can be observed as well with so-called global templates and global modules. It actually means: Everybody has to do everything exactly as enWP does. MediaWiki is supporting enwiki only, and all others are obliged to follow enwiki community decisions.

• T132308#3263787 For the record: Software and services that are used on hundreds of wikis are not required to abide by the policies or guidelines of any individual wiki.

dewiki has no problem to equip all their related templates with an mw- class.

• Our Template:Hinweisbaustein does know |POSITION=oben which actually means position=top and could trigger an mw- class with one edit only.
• The box design for top position is omitting top and side border lines.

I am looking forward to get informed about the MediaWiki selector dictionary with all these mw- classes.

Ah, and two similar resolved issues wrt author, might help:

• T160845 wrong author listed and wrong first/last name for the one author listed using ISBN lookup
• T203361 Publisher is incorrectly parsed as an "author full name" and split into first and last name when generating from DOI

In T249293#6889884, @Jack_who_built_the_house wrote:

I would also be happy if the page properties potentially brought about by these magic words were introduced to frontend somehow (via a config property, for example), so that user scripts (including mine) could use them.

• Each mw.config.get(wg) is blowing up the size of the delivered HTML page and adding bandwidth.
• In most cases, when reading an article, none of these page properties are needed.
• Delivering a pile of unnecessary page properties increases resource consumption for all readers and users.
• If a particular script is interested in a particular property which happens in 0,0001 % of cases that may be retrieved via API rather easily.
• The number of mw.config globals might be reduced for rare site properties.

There are only two values permitted: yes and no.

A change in strategy is needed. Apparently that has been started some years ago already.

• id= should not be used for anything else than to enable the reader to jump to a certain point in document.
• Elements to be decorated or manipulated shall be accessed by mw- classes only.
• If necessary, the mw- class might have one member only. That is the replacement for elements formerly addressed by id=.
• Implementing this consequently no conflict between headlines and MW system activities could occur any longer.

Migratíon to this paradigm is on the way, as see.

For example, by prepending it with h- for heading,

That is no help at all.

Actually I was wondering why Lua did not get fragment identifiers but JS/CSS received them. There are small doc texts possible on JS/CSS code pages by MediaWiki:Clearyourcache but those are short and constant and may be kept free of duplicates easily.

We do need user defined so-called anchors, and they are spread in millions of occurences over the wiki projects.

Just to clarify: Line numbers are working with Lua, see mw:Module:Gerrit, but no id= yet.

The major purpose is to have as first step some results from incategory: and any keyword search.

• Based upon the result set a bunch of pageids is collected.
• Then some maintenance operation takes place, perhaps a bot run.
• Finally, with the original query the search is repeated on the pageid set. If successful no results should be present. If still matches are showing up it needs to be polished again.

Any namespace limitation is pointless if a set of pageids is provided.