In T145604#8631274, @Legoktm wrote:

In T145604#8627941, @PerfektesChaos wrote:

What is the value of splitting up the migration of RFC and PMID into two steps? Wouldn't it be less of a hassle to do both at the same time?

Look at the figues, especially deWP.

• RFC is a test balloon.
• Amount is not too large, check how support for small wiki will succeed.
• Give them some months to take breath; learn from experiences in RFC step.

Regarding German Wikipedia you need a smart stategy, then it will work.

• Looking at LINT errors dewiki will proceed; compare with enwiki.
• However, among 20.000 people there are a dozen fellows who started in 2005 and they do not want any change and everything has to be kept as it was in 2005. Unfortunately, they are quite loud and experienced and collected a lot of merits for their work as authors over two decades.

A promising plan would be:

• Wait until Vector2022 has been established successfully.
  • A war on two frontiers simultaneously is not a good idea.
  • Currently even enwiki is reluctant.
  • Gadgets need to be adapted to new page arrangement.
• After sea has calmed, announce a change for RFC within about 3 or 6 months; end of 2023 or July 1st 2024 or whatever, for all projects.
  • There is already a template.
  • RFC 1 can be switched easily by bot in article space towards RFC&nbsp;1<ref>{{RFC-Internet if not already within <ref>, then change access inside <ref> elements, then cleaning up the remainders. Other namespaces are no longer linked.
  • Tracking category may be activated then and tells occurrences for several years even if no link is generated any longer.
• Then announce discontinuation of PMID within 3 or 6 months.
  • Those will be overcome by [[pmid:1|PMID&nbsp;1]] whereever they occur.
• For ISBN you will need a global parser function {{#isbn:0-123-456-7|1}} with second parameter for invalid ISBN but printed in books and registered in national library catalogues.
  • This should format and hyphenate correctly and will apply a class and nowrap and error message and maintenance category and everybody is happy.
  • Since it is widely used, bots will need ages and version histories get lots of entries.
  • Small wikis have no bots.
  • A global migration plan needs to be developed, perhaps via server script (a parser function can be applied everywhere while a template needs local support and might collide with a local template).
  • When migrating to next Parsoid storage level this might be done automatically.
  • VE might dump parser function formatting.
  • When retrieving wikitext content deliver new syntax, or store new syntax every time when publishing. Will take some ages.
• After each stage, check riot level in all wikis. Adapt roadmap if necessary.

Please see T204201.

I am creator of lintHint mentioned above. This tool, some more of mine and I guess a pile of other tools are affected by the Vector 2022 change.

It is pointless to add an English image description Placeholder, we have no preview image here which will be forwarded only to people with screenreaders, which is an aural non-visual presentation of the content, and where the existence of any image is to be hidden from the recipients at all to avoid confusion.

In T320299#8338548, @matthiasmullie wrote:

No activity in a week - any opposition to move forward with the proposed solution?

The goal of this task is to monitor about 1000 wikis of WMF for hazardeous codes by global tech community.

You might not have understood the background, or living in English Wikipedia World only.

In T200766#8334633, @Izno wrote:

I'd like to see a more generic/general dropdown to filter by content model, which is a task I've been thinking about proposing and which would have general benefits aside from CSS/JS editing, for example being able to watch TemplateStyles edits, which is of general interest to me.

I am not aware of any other with empty parameter, but {{NAMESPACE:}} might be a bridge for migration.

• This one is the function call with new behaviour.
• {{NAMESPACE}} is the 2006 behaviour.
• Those who want the new formatting for current page may insert a : and get the new result.
• Currently {{NAMESPACE:}} is rendered as empty string.

German and Portguese wikis have an exhaustive gender distinction as well, and it is widely used to address accounts in a proper way.

In T320299#8312643, @Volker_E wrote:

Given that we also need to think from front-end performance angle, I don't see added value in additionally add role="presentation" – as the need is already covered by adding 1 and 2.

add aria-hidden to placeholder
add "thumbnail for PAGENAME" alt text for thumbnails

Sorry, but I did not understand the workflow for anonymous users.
There are two groups with different views:

1. Thumbs are okay, sometimes helpful, very often pointless, but when I am looking for a regional sports team it shows me the logo.
2. Never show images, since I have a slow or expensive connection and it slows me down and swallows my monthly budget.

What do you plan as default, and do you really expect that the other group will not use the search form field on every Wiki page any longer, but typing the entire URL for each query?

• I have stated above that a ticbox on search result page is required, memorizing the state by cookie, using this configuration for all further searches until cookies are cleared.
• This can be toggled for next searches until next switching.
• Registered users should set a persistent default preference, since cookies are frequently cleared, e.g. when the browser quits.

Just as a help fpr me to understand it right: By which preference shall anonymous users express that they do not want ever any thumbnail transferred via their slow and/or expensive internet connection?

There is no alt text required for screnreaders.

Yeah, I perform CSS/JS developing with an aged browser. If it works with an old browser it works everywhere. Console is visible only on development there, and some debugging otherwise.

In T320299#8303473, @Volker_E wrote:

@PerfektesChaos Why would aria-hidden="true" and role="presentation" be added? As soon as former is there, it's taken out of accessibility tree anyways.

Depends on screenreader software.

The alternative solution is to equip elements with

class="noviewer" aria-hidden="true" role="presentation"

If a screenreader is telling the page content such eye catchers are not mentioned. Otherwise blind people will be bothered with all the URL as image description, which is pointless.

I just detected this task, but have created T320344 already. There is a slighly different approach, but basically duplicated.

There are two approaches:

1. add a ticbox on search form (default: no) whether this anonymous user wants thumbs, and memorize by cookie.
2. add a preference for registered accounts, which provides default for ticbox, even if cookies are deleted after session. If such persistent user default is present, then general default may be “yes”.

I would like to see both, but at least the first one which helps all readers.

If I am looking for certain villages with some criteria it does not help me to get 500 images of a church, a town hall, or the monument of a writer or painter, or a farm house.

• I did not ask for 500 images. You are patronizing.
• But this idea is consuming and wasting my bandwith, and in less networking regions my device is blocked for a minute until all these undesired images arrive without any remedy against. This is burning the money of the audience, and a sin against environmental protection.
• There are many use cases why you are searching articles, and looking at hundreds of images is not the one and only one. You may start a text search within result page. Personally I did not need any such image within 15 years at Wikipedia.

Basically I am happy with this surprise.

• External (anonymous) audience might benefit from some visual guidance.
• Sometimes it will be pointless, 20 green views of 20 forrests are not really helpful.

For registered users a preference to opt out/in is strongly recommended.

In T120794#8277562, @Winston_Sung wrote:

Also, would we like to support localized #REDIRECT or keep it in English?

English is sufficient, since the audience are Lua programmers rather than encyclopedic authors. Lua is English.

It is completely fine to add (after empty line) such comment after statement as an explanation for such stupid one line modules.

Still experiencing.

If the problem is that the #expr and #if parser functions are swallowing the error messages generated by your modules

Indeed, this is the primary problem. However, this task has a wider view and is heading for a long-term replacement of square bracketed link syntax for categorizaton.

why wouldn't you just do the math or conditional logic in Lua itself?

Why wouldn’t you – well, if you assign you to me personally, this wouldn’t be a big deal.

• However, German Wikipedia has less Lua programmers and maintainers for all modules as fingers on your hand.
• But there are hundreds of authors with advanced skills in template programming, and thousands who could carry out simple template maintenance as well.
• Therefore we have a guideline that programming should be done on lowest level, in template language, if suitable. There are a few libraries with general functions on basic level to support templates, but content specific templates are written and maintained by authors without Scribunto.

You might consider figure@Expr which may be used to convert tricky local number formats into {{#expr:}} terms (better than {{formatnum:}} does).

Plesae note: de:user:aka hax contribs >1,000,000 which might have caused some overflow or timeout.

Addendum: Lua mw.text.trim() should be extended to similar syntax.

• They should share the unique core implementation, ensuring identical behaviour and DRY.

It is an impossible task to match all conditions.

• That implies that it is not possible to find any sufficient solution by keeping all requirements.
• The basic approach needs to be changed.
• The target is to reach usability for all.
• German Wikipedia is comforting users on regular base that something happened and they cannot edit any longer, like this.

What are the pitfalls?

• A textmarker is culturally dependant. This technique may be known in the US and in Western Europe schools, but not common in other regions. It is based on some academic paperwork, but kids are using eLearning and tablets in class room today. What is that, a pencil case, a textmarker?
• 10 % of users have bad eyes and difficulties to distinguish similar icons, or in rush and hit first intuitive click. Those writing devices have been learnt to trigger some editing. Even worse on low solution.
• The effect is not widely known. First you have to be familiar with the technique of syntax markup. This goes for developers and experts, but not the broad audience. Then you need to connect two English or European wordings, markup and marker. How is that connection in Japanese, Chinese, Suaheli? Who would understand a search light for highlighting?
• If clicked by accident, there is no clue what happened and what to do for returning back to usual appearance. Since jQuery.textSelection does not communicate with this input mode, none of the helpers for text insertion work any longer. Nobody will understand that a blue pencil does mean active highlighting, and another click will change into black pencil and turn off.
• The effect is to bring colours into syntax, but design rules permit monochrome only, here black (blue) and white. Even grey is not possible and does not work with 20×20. Black and white graphical icons only cannot explain what will happen.

Conclusion:

• Either not black and white icon only, but colours with some <>[]
• or explicit textual label.
• A ToggleSwitch element outside the icon bar would be much more comprehensive with L10N text or syntax characters with colours/grey if active.
• It is simply not possible to teach regular editors on possible highlighting technique by 20×20 monochrome pixels.
• The current design is not acceptable. This doesn’t work.

I guess there could be a bug in line 227 now.

• In function isExpired( key ) the key is the user provided name (might be documented more precisely, has been called raw key recently).
• Then I would expect that expiry = this.store.getItem( key ); needs to be prefixed by EXPIRY_PREFIX +.
• .prototype.set() is using the same key for both payload and .isExpired(key) assignment.

Furthermore, I would be more defensive on comparison < of expiry and Math.floor() since the item may not contain a number, perhaps always returning strings, or partially written on browser crash, or manual editing of values by development tools, or changing implementation strategy in future, etc. If not a positive number then always remove.

• Personally, I would expect .getItem() to return DOMString or null, therefore always parsing.

Pondering a while I would request for any syntactic identifier core:

• If length 1 then either ! or =.
• Otherwise at least two characters.
• First one is to be a letter, generic ASCII A-Z, or Unicode letter for L10N, or ideographic.
• More letters etc. permitted.
• Case insensitive by legacy.
• May contain a digit, like REVISIONDAY2, or Unicode digit for L10N.
• A _ is permitted inside but neither first nor last, and not subsequent.
• Function names may be prefixed by # which are not part of the core identifier. Those avoid mixing with any template since a page name cannot start with #.

Well, with exception of existing one-character-functions {{!}} and {{=}}.

And neither | nor # nor < nor > nor & or any other stupid idea.

@PerfektesChaos: can you please share what prompted you to name the case above? Is there something unique about this case that you think would NOT be covered by what is being proposed in T249293#8129301 ?

If the draft has been deleted no no-sysop is able to see that and nobody can discuss about nothing.

The idea of this /styles.css is to make the identical styles available for both any wikitext and even any JS gadget as distributed by MediaWiki.

If the subject does not exist any longer there is nothing to talk about and all discussion is discontinued and nobody should be invited to add answers in the wrong place.

In T249293#8133699, @Xaosflux wrote:

I don't like the idea of "ARCHIVEDTALK" for this, as opposed to a straightforward directive (e.g. NOREPLYLINK). There are plenty of possible use cases for a talk page that shouldn't use "reply", but have nothing to do with the type of content on the page; needing magic words to describe such a sub-case of content isn't consistent with anything else.

https://en.wikipedia.org/wiki/Wikipedia_talk:Sandbox/Archive_Overview

• There is no subject page. Do not invite to start a discussion about nothing.

https://www.mediawiki.org/wiki/Project_talk:Sandbox/archives

• Should not offer to start a new topic.

The reason why that template is providing all those styles has been that MediaWiki does not reliable provide all styles via classes. In 2018 MediaWiki announced that such CSS will be loaded if and only if a MediaWiki generated form (like special page) is requested. These styles are providing the same style for project pages etc., which may lack the CSS now or later.

Postpostscriptum: It works on regular pages, but not inside Flow discussions. Whyever.

Special:Hieroglyphs in any wiki does understand it, but tag syntax apparently not.

Addendum: It might be that the backslash syntax is part of the WikiHiero specification, but not available on-wiki. Or Gardiner himself.

Meanwhile I learnt that our extension permits mirroring of a single glyph. Please try

• <hiero>G11</hiero>
• <hiero>G11\</hiero>

Just append a backslash \.

BTW, on talk archive pages there is usually no subject page on /archive. If this is a talk page and the subject page does not exist it is most probably an archive subpage, and no section may be added nor anything starting, since only the root talk page owns a root subject page. If the subject page does not exist nobody should be invited to start talking about nothing.

It does appear for me, otherwise I would not have opened this issue.

BTW, on talk archive pages there is usually no subject page on /archive. If this is a talk page and the subject page does not exist it is most probably an archive subpage, and no section may be added nor anything starting, since only the root talk page owns a root subject page. If the subject page does not exist nobody should be invited to start talking about nothing.

Ah, wrong task, answering T314547, sorry.

Please prevent also Start a discussion about from appearing on inappropriate pages.

On different introduction of features:

• https://caniuse.com/?search=queryCommandSupported
• https://caniuse.com/?search=execCommand

Obviously some assumptions about behaviour of browser versions in the field are wrong, even with three years old tools.

I am not involved in this development, but it seems that older browsers will not work the new way, and newer or future ones will not since the new implementation was already obsolete when inserted.

Soemthing went wrong here.

The recent patch says

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.