Well, the core problem is a bit different.

• The article which transludes the modified template (Inverted Coaster) does not mention which media files or templates are causing the problem.
• Until mid of 2023 there appeared a link to Template:Navigationsleiste Achterbahntypen which tells precisely where to remedy the problem.
• If there are 100 templates and files in this page, you wilkl have a nice time to explore the responsible page.

The (kein Unterschied) is not really important. It does not matter whether any difference will result. By vandalism and reverting by a new user this may happen easily.

I suppose security-wise there is not much harm in admins being able to delete a page that they (for good reasons) aren't able to edit or create.

And this is intended: If there is malicious JS etc., every sysop can delete such a page immediately, without asking stewards etc. for further help.

It has been refused since the resulting order is not the sequence which the community does need for thematic arrangement. It goes for names only and does not take into account deliberately distinguished structures based upon ASCII codes.

German Wikipedia is using ASCII codepoints like !#,:* and more for special effects.

Unification and simultaneous handling of both regular and hidden categories is fine with me.

There were always some inconsistencies and strange things.

• iPhone on page headline but IPhone in category or other page list and search results.
• IPhone as title of revision history.
• _ and %XY in URL page names.

We should try to make such strange things like subpage names in namespace more readable and comprehensive by inserting some visual structure wherever possible.

• We cannot refrain from improving 99 % of the cases if there are some 1 % left where current solutions are too difficult. Perhaps one day iPhone is shown in categories and page history as well. Anyway, the page headline is displayed correctly right now.

The Title functions must not insert any space character.

• Every adapted presentation shall be created by CSS only.
• C&P shall yield the generic name as today.

BTW, hopefully people discovered C&P functionality and will not type letter by letter someWikipedia talk:Manual of Style/Accessibility/Alternative text for images

• However, if they type an extra space after : universe will survive.

I think phab is the wrong forum for this issue. Local dewiki platforms (template discussion or general template maintenance project) are more appropriate.

It is crucial that there is a visual spacing, but not a space character, if any.

• That means: As soon a page headline or any other displayed element is taken by C&P, no space character is inserted and may pollute wikitext by insertion, making search for strings and replacement of page names more difficult (it is legal yet, and there may be _ rather than space or lowercase letters).

For many people, separation of page name elements make semantic elements more readable.

• Visual separation of namespace+: and subpage hierarchy by / is considered helpful by many who are not wiki insiders over decades.
• Separation of page name components should offer may-break-here hints after : and / on long lines, rather between two words of a component.

A project wide feature to display all page headlines where subpages are enabled would be fine with me.

Nice idea.

It has been just reported by a dewiki user that LaTeX preference works fine but SVG crashes. How comes?

On top of that, using // is generally discouraged and should be cleaned up :P

Well, in order to clean them up it is necessary to find them via LinkSearch.

If you refer to:

• edittools-magnitudo[ResourceLoader]|actions=edit|edittools-magnitudo.js

Well, this is a fundamental syntax error at least on first glance.

Fine, after one and a half decade.

In T316533#8917077, @Od1n wrote:

You could make use of #iferror for your case. It catches any element (namely strong, span, p, div) that has a class "error". This includes errors generated by Scribunto.

This does not help.

Every Wikitext code like a nowiki exclusion, a {{db-u1}} request, an internal link to a user page or project page which shows up in Whatlinkshere or a Category: which really works is occurring in a JavaScript comment, since it would cause a JavaScript syntax error otherwise.

Many many templates are not documented by an individual JSON for each single template, but derived from series of JSON data generated by documentation template or Lua module, creating TemplateData for many productive templates.

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.