Internationalization issues, cultural aspects, script and language, world wide impact goes in similar way for templates and modules.

It is quite common that a software feature is developed for a certain purpose, but later the end user do find it helpful for more or even entirely different applications.

• The original target has been to generate random codes beginning somewhere at one letter, with no special meaning.
• It turns out that it is very useful to reserve 4 letter codes for mnemonic shortcuts like wikt or voya or whatever; leaving 2 and 3 letter codes for languages of Wikipedia as most frequented WMF project, one letter code like b c d v for (english) project entries, and 4 letter codes for various internal assignments not conflicting with language codes.
• Random shorteners start at aaaaa and have no meaning at all. That length is quite common for short URL and not difficult to type and write on a piece of paper or tell by phone.

The additional claim lang="..." should be entirely removed from the heading element.

@Shivanshbindal9:

Also, the code of notifications special page is not in the directory where the code of all other special pages is there i.e. in includes/specials directory.

The reason for preferring ISBN over OCLC is that ISBN gives access to both Worldcat and any other, like national libraries and book sellers and local library catalogue and research archives.

I was not aware of that lengthy task, but yes, they are describing the same problem, and yes, gerrit:486825 is the solution I proposed based upon my earlier <bdo>/<bdi> experience. Should be resolved, then.

In T214413#4899875, @Dinoguy1000 wrote:

Wikipedia's Print.css may be worth investigating for this, too.

I learned now that apparently no PDF but always the HTML &printable=yes is affected.

After a good sleep, I am now dreaming of MutationObserver and the basic software should do:

• Do not equip initially any disabled or hidden input element, whatever user request might tell.
• Observe all requested input elements by MutationObserver.
• Hide toolbox as soon such element will be disabled or hidden.
• Pop up or create toolbox as soon such element will be enabled or displayed.

Browser availability is to be checked, but should disseminate soon. 2ColEdConflMgr is in BETATEST state, might take a while until regular.

In T211862#4889146, @EBernhardson wrote:

Would it be fair to rename this something like the following:

• Two users visiting the same search link have different searches run My reading here is that the expectation was a user could share a search link with someone else and they would see the same results, but that expectation was broken?

Equipping any page, even a Special:Blankpage with any kind of forms and input facilities shall be supported, no matter how an identifier is called. Therefore wpTextbox is limiting too much on official MW generated pages.

It might happen that some browsers regard hidden form fields as disabled, and others do not. However, the gadget shall not rely on this assumption.

BTW, it is intended that on Upload form or any other page with multiple textarea fields expecting large amount of text input each big input element shall be equipped with input assistance directly attached.

Thank you for informing me; I am not using that feature, and I was not aware that any other script is inserting hidden enabled textarea elements at that stage. CodeMirror, CodeEditor, Schnark, Ace, wikEd are using disabled property while sleeping if I recall correctly, or show up later. At least I have tested interaction and did not detect any problem.

I do appreciate the proposal to insert an additional MyDefault element if and only if there are differing user preferences in effect.

Yeah, thank you, established in July 2009. Did the predecessor check all files before 2009 on every Wiki? Or any monster sleeping in a dark cave?

This opens another question: Is it actually checked that no SVG on Commons does contain any <image>, <script>, <use>?

As far I know the following procedure should be sufficient, but a real SVG expert might check for further mouse holes:

1. URL-decode the url() value as inspected string.
2. Remove any whitespace from test string, even strange stuff. Or just leave ASCII letters and a few special characters <>#/:=.
3. Downcase the entire thing.
4. Look for the following strings:
   1. <image
   2. <script
   3. <use (may be permitted as <use href=#template)
   4. href= (but href=# is okay; perhaps also / relative URL). Just to make it bullet proof.
5. If any of those (or some more) is found, then drop.

First, I never used the “remember” feature, and I learnt now that my old fellow is reused by the advanced form. I simply did not know that my preference made a decade ago and no longer mentioned in preferences has still influence. On the Special:Search advanced form the int:powersearch-remember ticbox is not marked and does not tell me that I am reusing anything I want to be remembered.

Please note that these are not static pages.

• The URI comment looks like assigning a static page which is simply transcluded.
• Entire JSON TemplateData descriptions are generated individually by template or Lua programming; depending on parameters and existence of other pages.
• You may have a look e.g. at use of lang/Latn/Doku and the derived page.

In T148274#4832615, @cscott wrote:

I didn't actually know that -- is that documented on dewiki somewhere? I'd appreciate a pointer for future reference.

https://de.wikipedia.org/w/index.php?search=insource%3A%2Fref+name%3D%5C%22%5Chttp%3A%2F&title=Spezial:Suche&profile=advanced&fulltext=1&advancedSearch-current=%7B%7D

• For me, this yields to 15 matches in article talk and user space only.
• I presume you do not see any match?

@Lea_WMDE current behavior is that in case of no namespaces the user preferences for namespaces are selected (which is the wiki preferences if no user preference exists I think, and that is (Article) in de-wiki

I am not sure about renaming the ticket.

The traditional approach has been:

• &profile=default → ns=0
• &profile=images → ns=6
• &profile=all → every per project ns listed in URL
• &profile=advanced → if no ns specified, then all ns, otherwise those explicitly mentioned.

Easy way to reproduce: Switch off JavaScript.

• Wiki needs to work without JS, e.g. for security reasons.
• Even without JS the basic server functionality is to be delivered.

• &profile=advanced might be ten years old and offers a selection of namespaces; search is done in all namespaces otherwise.
• &profile=default is the opposite; small classic form but ns=0 searched only.
• There are also &profile=images and &profile=all which last searches all namespaces by small form.

The behaviour is identical for both classic form or recently introduced Extension:AdvancedSearch support or switching off that advanced feature which became possible a week ago.

Sorry, no, I am overburdened and do not get into any code patching whatever business. Even more not into a different GitHub Account authorization identification password procedure administration; I do have some 50 access management issues like this open and do not add any further.

I used these links over years. For sure it worked some weeks or months ago as expected.

@Aklapper * Hi, Master Of Ceremony, would you recommend to close this task as invalid and reopen with new title and description, since the encoding cause turned out to be a wrong assumption?

• I failed to make any user preference responsible for diverging behaviour on my account.
• Perhaps some kind of cookies involved?
• I do get always 20 of 223 results on first attempt.
• User preferences were checked, no influence.

Oops, meanwhile I changed prefereces. No idea which of the four options for search I have been assigned to when I opened this task. I do not recall that I ever changed them, but I am onwiki for a decade.

Ah, and btw there are user preferences for search. My ones are cirrussearch-completion-profile-classic-pref-desc. This may or may not influence which namespaces are gracefully considered.

Okay, it is not the encoding issue, but an undesired behaviour anyway.

• The search is meaningful for ns=10 only.
• Explicitly requesting this namespace makes consecutive links 20 50 100 250 500 working.

Entering the search term without namespace specification into Special:Search form gives me 20 of 223 matching pages.

• Yeah, fine.
• Now I want to get the next 20, but the chain is broken.
• Either the first search attempt fails, since limited to ns=0, then I am to specify a namespace. This is reasonable. (old behaviour, iirc?)
• Or I get 20/223 results. Then consecutive pages are to scroll through this particular result set.
• Currently after entering the expression into form all namespaces seem to be searched, but follow up links do not.

In T211862#4819925, @dcausse wrote:

@PerfektesChaos the URL attached to the task description leads to no results

Well, if I click the link above I receive 20 hits, announcing of 222 total.

• We cannot underline since that does not fit in arabic, CJK and other non-latin scripting, and we never underline anything.
• The regular way would be blue colour as everywhere, but that has been rejected for the time being.
• The arrow is the only remaining hint, and was common in that place as the only linked element for many years.
• Removing the arrow makes the greyed out stuff a matter of random experience by accident. And again a storm of complaints will arrive when that point of orientation vanishes.

• The current purpose is to indicate that here is a link which is not coloured in blue as every other link does.
• There are people editing since 2005 with 100.000 edits who never noticed that some five or eight years ago a link feature has been introduced. They learnt it two weeks ago when it all became blue and a debate started whether it shall remain blue or grey again as within the years ago.
• The arrow has been blue the last years, but nobody discovered the colour of that little arrow.
• If you are new in Wiki world you have no idea that somebody is hiding a clickable link, something greyed out just before the user summary. That is signalling inactivity, used for deactivated things.
• The arrow is the only thing which might give you a clue to hover at this part of the interface.

• Underlining is not feasible in many scriptings, like CJK and arabic etc.
• Even in latin underlining looks cruel if section headline is larger long, wrapping in three, four, five lines.
• Consider resource consumption by exchanging a three byte UTF8 arrow with a graphical arrow-like button or unavailable Unicode for enhance emody things.
• § is known in western world for section, but might be narrowed to English. In German that is used for paragraphs in laws and contracts only.
• Shading does not necessarily make things better, does not explain the motivation and makes many scriptings unreadable, even bad to read if text is a bit longer and conflicts with accessibility.

Task headline and task description wonder whether there should be an arrow at all. Or something like that.

• Is there a good reason we're continuing to include the arrow? Should we just remove it?

With the recent all-grey-change the arrow cannot be removed as remaining link indicator.

Back to the originally opening question.

• With the most recent change, the arrow is not a blue link any longer, nor is the TOC headline in blue as it has been for a few weeks.

Now it is hard for newbies and not frequently visiting users to learn that this grey thing is a clickable link.

• The only clue they get now is the arrow.
• The arrow (or similar simply accessible sign) is necessary now to give at least a hint to this type of link markup differing from any other clickable link.

• I am fine with fully clickable link.
• On wikilinks within section title: The fragment shall be shown and linked, the same as in TOC. Nested wikilinks should not be a problem, markup should be stripped off entirely and the link on outer pages should get the same appearance as TOC within target page, but dropping bold and italic. Automatically generated /*...*/ does not contain any markup.
• The leading arrow people are used to is fine and may be kept as part of the link.
• There might be some more space filled with I18N robust stuff between section link and begin of summary. If summary starts with wikilink, summary will start in blue as well. Something visible in black should create a widened gap between blue section link and blue comment start.
• There are people who did not learn over years that the arrow is blue and might be clicked. That feature has been introduced some five or eight years ago, and oldtimers as of 2005 never noticed that there is a link. On the other hand, newbies shall identify that feature immediately.
• Therefore, blue colour is necessary to clarify the behaviour. No other colour than every other link targetting such pages.
• If anything changes, even clearly improving, always some guys complain loudly that their wiki experience crashed now since they were forced to learn something. One year later nobody recalls.

Note: The migration from user to actor happened at the same time. That may or may not influence the access to reviewing permissions of the performing account.

I do confirm that dewiki@BETA works properly now.

Reopening: Unfortunately not yet fully recovered.

If you go through code of module:Infobox and hundreds of other modules, you'll find that they have considerable length, and are more than 80% similar (sometimes even copy paste like en to sa).

Take a look at Module:WikidataIB, there's only 1 developer substantially (of enwiki) and rest of Wikipedia are copy-pasting it. So if something updates on enwiki, it is lagged behind on other wikis due to variation in time of updation.

Please keep in mind that there are not only Wikipedias in various language versions.

Well, that is why I

• distinguish between
  • the parameter value span (or top level out of any template)
  • any other point of the template transclusion
• prefer cursor position with no selection range.

That makes expected behaviour much more predictable and easier to understand for end users.

• There are unambiguos cases of selected regions, but in general it opens more questions what a user request to be done.
• It might be intended that the selected region is to be enclosed as first unnamed parameter within a chosen template. Who knows? There are a lot of formatting templates supporting that.
• The user might not be aware that there is more than one complete template transclusion in selection range. Which one is meant?

I think we should stick to the well known system of separated pages for different purposes.

• They might have different protection level.
  • Documentation might be changed by everybody, since that affects one other page only, while template programming and CSS get higher protection until sysop only, since affecting perhaps a million pages.
• They have an independent revision history.
  • It is crucial to identify a history of effective programming changes and nothing else, or of CSS changes only to identify bugs and recent changes causing problems. A mix-in of various documentation and test example issues into one page history is undesirable.
• They have independent Whatlinkshere.
  • It is crucial to know which "slot", currently which transcluded page is influencing which other page. If everything is merged into everything since one slot is involved nobody can maintain templates any longer. If I want to know which pages are affected from TemplateStyles but not necessarily transcluding the mother template around I do need separated lists.
• In the end it stays at one page per purpose, and one slot within that page; and rather than multi-slot in one page it is more meaningful to have a group of independent 1-slot-pages related together. That is good practice for more than a decade.
• The mix-all-slots-in-one page will result in a very complicated system for editors and sysops, who cannot follow any longer a history or identify particular protection. At least most confusing and challenging for regular users who are not MediaWiki developers.

I stick to the position that this is encouraging uncontrolled misuse of CSS rules in classes suddenly appearing somewhere on pages, with no real chance for editors to understand when and why which class with which name has which effect under these conditions; consider name collision.

jQuery.Deferred exception: Das Objekt unterstützt die Eigenschaft oder Methode "find" nicht

TypeError: Das Objekt unterstützt die Eigenschaft oder Methode "find" nicht
at MMVP.loadImageByTitle (https://de.wikipedia.org/w/load.php?debug=false&lang=de&modules=mmv&skin=vector&version=0n1zvob:102:613)

I am happy with the current task.

Izno, thank you for comforting me.

Well, selection of a region is actually not recommended. Ideally it is cursor position only with no selection span. If there is a span, yes, it might become disambiguous. One existing template transclusion only shall be identified, best in name span, and the current values are supposed to prefill the form. Otherwise a new transclusion might be inserted.

Vorlagenmeister will open the nearest template around cursor (next template name / opening brackets to the left) and will show inner templates as plain wikitext.

• From the left edge, beginning with the name, the right edge (terminating brackets at same level) is searched, considering HTML comments and nowiki. Fields at same level will be assigned by name and value on the way.
• Since it is a development of 2009, nobody would complain on wikitext parameter values. Old fellows are used to wikitext.
• To deal with inner template, just save and reopen at desired inner cursor position.

Well, they cannot really change it.

An older one, I am afraid.

Please consider non-JavaScript users.

In T127328#4500232, @gerritbot wrote:

Change 452588 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] resourceloader: Remove support for state(name, state) signature

https://gerrit.wikimedia.org/r/452588

In T200742#4502407, @PerfektesChaos wrote:

And not to remedy that within one or two days. Does anybody recall the meaning of wiki?

The minimum is that this would be tagged by lang="de" as we are used to do with prominent shifts to other languages in our wiki projects.

Indeed, the version of May 2018 has been wrapped into <div> rather than wikisyntax table, but that suddenly made problems as well.

As far I know that was result of a fight against malfunction / bad rendering of a template that worked until July 2018 and now attempts to find a solution for correct rendering on 7th until 9th of August.

Make the entire top region collapsible, leave nothing more than a link or button labeled with timestamp to unfold any options and explanations. This goes for many special pages and similar evaluations.

We should not rely on 3rd parties.

In T201052#4479801, @Tgr wrote:

I think this can be closed in favor of the more specific T200176: Deletion of user js and css requires deletion and edituser* rights. Or am I misunderstanding what you are asking for?

I am afraid, yes. This task has a much broader scope.

The link is fine, but the classic design told me that my attention has been attracted five minutes ago already.

I do support the wish for a timestamp.

Destroying and removing productive contents is a No-Go.

I do support this, and it should be configurable the usual way per project rather than constantly

mw:Special:Mylanguage/Help:Notifications

as set in

• rECHO/includes/EchoHooks.php line 98
• rECHO/includes/special/SpecialNotifications.php line23
• All i18n like rECHO/i18n/en.json

Since many wikis do maintain their own guidelines this shall be configurable per project (not per language), with mediawiki.org/wiki/Special:Mylanguage as default, also for external installations.

Yes, fine, thank you.

Update more than six hours later:

• Persisting.
• Same for JS and CSS pages in MediaWiki: and User: namespace.
• Wikitext normal in all namespace.

The problem is at: line 97 of rEIMA/includes/ImageMap.php

• It reads as: loadXML( $imageHTML )
• That means: This part of the file parameter is supposed to contain XML.
• Now it is fed with a <br> tag. XML is expecting a closing </br> tag (which is actually nonsense in HTML). Since there is no closing tag found loadXML() issues an error message and the extension beaks.

It works with XHTML <br /> void element.

• This has a side effect: loadXML() is turning <br /> into <br></br>. Later the second one then is turned into <br> again by Wiki post-parsing Remex HTML cleanup.
• Use a pair <div> </div> which produces a new line by block element.