How does this sound?

Some remarks:

• This should not be a separate Special:GadgetPreferences but part of Special:Preferences in Gadgets section, when entire usage of one particular tool can be toggled. If this tool is activated, the preferences GUI should appear immediately below (and vanish if toggled off).
• The JSON spec should be subpage like MediaWiki:Gadget-myTool/preferences.json, while site configuration might be MediaWiki:Gadget-myTool.json and implementation is at MediaWiki:Gadget-myTool.js
• Texts do need localization mechanism. A global root may contain English, French, Japanese and German, and on Commons users will expect their user language. Further translations need to be added easily by global collection of local languages.

Actually the redirect table could be a further candidate for indirect use of linktarget table, when both pagelinks and templatelinks table migration are completed.

In T174811#9711272, @MusikAnimal wrote:

In T174811#9709334, @PerfektesChaos wrote:

There is the module jquery.textSelection at rMW /src/jquery/jquery.textSelection.js

• This is wrapping access to selected text or cursor position independent of browser methods, and does also permit text changes at cursor position or replacing marked text range.

This does currently not support CodeMirror but native text <input> and <textarea>.

• It should cover CodeMirror and DiscussionTools transparently as well.

I think the idea is to do the reverse – editors are expected to ...

There is the module jquery.textSelection at rMW /src/jquery/jquery.textSelection.js

• This is wrapping access to selected text or cursor position independent of browser methods, and does also permit text changes at cursor position or replacing marked text range.

This does currently not support CodeMirror but native text <input> and <textarea>.

• It should cover CodeMirror and DiscussionTools transparently as well.

In a similar way I would like to get a wrapper around CodeMirror and DiscussionTools, which shall allow to deal with text fields no matter which mode the user currently toggled:

• Retrieve textarea#wpTextbox1.val() as entire text
• Assign textarea#wpTextbox1.val(s) to the entire story
• If currently in CodeMirror or DiscussionTools mode, then retrieve via the corresponding API; if native then jQuery .val() function.
• There is a second text field on Special:Upload.

In addition I want to explore whether the user input did change CodeMirror text and possible errors have been marked.

• It is sufficient to know that the text has changed, no matter whether by programmatic assignment of entire or partial text or mouse event or keyboard event. When it changed I can look for arriving or vanished error class elements.
• I need to know whether CodeMirror was activated or left. While no CodeMirror is active I do not need to look for error class elements. Events or mw.hook() shall be fired when CodeMirror toggled.

In wikitext (,.;? followed by whitespace or text end will trigger URL termination just before.

We have a similar problem on mentioning plain URL in wikitext, interpreting terminating interpunction characters as part of surrounding text rather than part of URL. The same goes for many messaging tools.

It did not disclose to me on uselang=qqx that message, therefore I did assume that no config message is available.

In T344378#9612154, @bvibber wrote:

Do we.... have a good high-level task for this that covers the conceptual feature for both ios and android and not low-level implementation details?

In T359582 I just complained that

there should be a separate Phabricator trail for alt= image descriptions (even video).

My comments on mw:Talk:Wikimedia Apps/Team/Android/Image Recommendations were already linked, but I do strongly oppose to make this a LINT nor Growth task.

Thanks for adding categories.

In T31272#9582536, @Bugreporter wrote:

Small wikis without IF-admin could manage offered gadgets and circumstances themselve.

Such issue should be solved by global gadgets.

One question arrived now: Is editing of any MediaWiki:Gadgets/ page requiring successor of previous editinterface or gadgets-definition-edit right?

A key in a JSON object is always a string. Therefore a number is impossible. However a Lua table needs to be a JSON object if any not one-based array shall be mapped.

Yeah, obviously parsing needs to be revised. I would expect:

1. encountering =+ and in __NOEDITSECTION__ mode then
   1. create <h.> instead
   2. send back into stream
2. encountering =+ and not in __NOEDITSECTION__ mode then
   1. create wrapper business, be prepared for addition of edit/subscribe elements
   2. insert <h.> into wrapper
   3. send back into stream
3. encountering <h.> then append content to TOC etc.
   1. processing both native elements in wikitext and those created from =+

or any switch or fork or sub-process to handle <h.> elements for TOC purpose.

I am always open to new {{#...}} parser functions.

• However, I am worried since dewiki is using <h*> within some 1,500 wikitext source pages, and perhaps 1,000 of them may be broken by the recent and not announced change. Even our main page crashed, which got a hotfix.
• In the long run I do prefer {{#...}} parser functions since they have explicit opening and closing syntax, compared to some : or ''' or * somewhere, and they are not misusing [[...]] links for {{#category:...}} purpose.

I wonder whether you apply this if it is not an editable section with == but a deliberately non-editable section with <h2> in wikitext.

• I do understand that you separated the [editsection] business from the headline element to improve accessibility.
• However, if wikitext is containing <h2> there is nothing to be changed, no accessibility touched, no separate [editsection] element. There is nothing to be discussed, and nothing to subscribe or unsubscribe.
• Therfore, if either __NOEDITSECTION__ or <h2> is present in wikitext, just produce the traditional element without wrapper.
• Iff it is == then create that wrapper and [editsection] but that is almost everywhere regular article text or talk page without any special styling.

I am not deep in the most recent CSS but I think it is feasible to distinguish a wrapper containing a <h2> and turn that into inline, but keep block if there is no wrapper present.

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.