In T189095#5410402, @cscott wrote:

This was an intentional change to make preprocessor behavior more uniform.

This time a regular article page, no JS nor user page.

Yeah, everything fine now.

Just look at the gallery page. That one is maintained and updated. And only that one. Forget all categories and the double amount of icons which have been official OOjs icons two years ago, and might be recovered next month again.

It is disturbing the watching users (who are supervising bot flag edits) and is blowing up the version history.

I am the guy who initiated in 2016 the porting of the icon collection, persuaded a script runner to create the first pile of 1000 icons, and I added manually several hundreds of changed and added icons. I also refactored the gallery.

You split the discussion on two Phab tasks, while it is actually an issue for the Commons talk page. Therefore I am forced to comment here once again.

The naming is from 2017, and all icons received meaningful and systematic names when the files were created. At that time, the name has been correct.

Slot issues should be considered as well. That is rather complex for parser functions which are the approach of a decade ago. Lua should get access to a table of slots with revID, user, timestamp, size for the most recent and the first undeleted revision. From that the calendar details like month2 and day may be derived and any local formatting can be done as required.

In T179154#5330292, @Iniquity wrote:

Just for example what we are having now:

https://commons.wikimedia.org/wiki/File:OOjs_UI_icon_edit-ltr-progressive.svg	https://commons.wikimedia.org/wiki/File:OOjs_UI_icon_alert-destructive.svg
https://commons.wikimedia.org/wiki/File:OOjs_UI_icon_edit-rtl-progressive.svg	https://commons.wikimedia.org/wiki/File:OOjs_UI_icon_alert_destructive.svg

Or at least a Lua access in the Title object. Then everything else may be derived by programmers, and no further parser functions wil be required. Lua people would like to get access to both current and creation revision information anyway. If Lua knows, templates may be supported by utility.

It is a bit strange to discuss Commons categories outside of Commons. Usually the talk page is used there.

I do propose a different name for the entire project rather than Homepage.

@Kipod: You may have a look into JSONutil@dewiki, check the examples provided at JSONutil Test, use the JSONutil.fetch(source,true,"he") function for now rather than mw.text.jsonDecode(source), clean up all obscure syntax from your wiki by maintenance cat step by step (the dubious syntax won’t survive the next decades, one day you will need pretty syntax anyway); and a Hebrew translation at commons:Data is welcome.

Caught on BETA, but might help here.

• I understood that External Storage is used to store text blobs of productive WMF wikis.
• Perhaps some entries in mapping tables are corrupt.
• The following error report would result from a problem in the other direction.

Apparently // or /* ... */ comments were accepted but not by PHP7, if I observed correctly.

In T227872#5328785, @matmarex wrote:

As a side note, the languages menu is duplicated within the site content. While this seems a bit weird to me, it does provide an accessible alternative to the normal menu.

Uhhpff. I did not find that, but I did not read the entire page with all details down to bottom and scrolled quickly. However, it is important that the opportunity is shown in prominent position and ARIA-marked for those who cannot see it. The blind Spanish visitors will appreciate that.

As recommended above, I did open T227872 for the language selection dropdown issue.

I do confirm that the 2018 state has been present end of June, beginning of July 2019.

• The Code of Conduct issue in this task with ban for unspecified durance triggered by a 4Lword came up to my mind in the similar FRAMBAN case.
• I checked this task and the homepage several times.
• Congratulations, it took almost twelve months to publish a simple fix.

Now we have a different issue, if a am not tricked out by some script blocking?

• In the upper right corner there is a language selection gadget icon.
• The drop down option list is disabled by: display:none
• Either I make both option list and selection gadget disappear, or I would enable both.
• Once again a deliberate and intended design decision by the department for higher reasons.
• I guess in 2020 we can revisit that page and see the selection working

In addition a kind of query for namespaces is needed.

• Who has a partial block on templates, modules, article main space?

Additional note on trailing garbage:

• Recent PHP apparently stops analysis when opening bracket { has been matched by closing }.
• PHP7 JSON does not return any result if closing last } is followed by non-whitespace data.

Even more, unbalanced (missing) terminating } at end of data seem to be granted by lazy PHP while strict PHP7 is insisting upon correct assignment.

I am in doubt that magic automatic device detection is a safe way.

• I understood that people are using Timeless skin on smartphone and tablet. Who knows future size and resolution of mobile devices? They will be thrown to Minerva after each click.
• I view quite often pages in the m. domain from regular desktop business to check appearance. The first link might be initiated by some &usemobile=1 but this mode needs to be preserved until I decide to leave the mobile emulation.
• Some might regard their tablet as desktop and use a desktop skin. Others will use the identical tablet as mobile device and prefer Minerva style. How to configure if there is an automatic decision made by server?

For the record: success on 2019-07-03.

T227033 is reporting a similar issue, first observed about 27 June 2019.

I think it should be left to the user.

We should stick to multiline relaxed strings, while regarding superfluous comma and apostrophe delimiters as errors.

In T225599#5252734, @Aklapper wrote:

Users are made aware. https://foundation.wikimedia.org/wiki/Privacy_policy covers this and is linked from the bottom of https://tools.wmflabs.org/interaction-timeline

While every other tools.wmflabs.org acess is hiding private browser fingerprint from tool developer, this one is using a hidden mechanism to record IP address and full browser profile by clandestine means.

• Every tool developer may log all queries, recommended for tool improvement and error detection, but that will include just timestamp, all query parameters, and some general browser characteristics.
• For identifying user groups, containing almost one person, the anonymous browser characteristics are sufficient and available to every tool developer.

The approach here gives the full IP data and complete browser and hardware and preferences and cookies and private information to unknown readers.

• InteractionTimeline is used to spy on users suspicious to be sock puppets. Now everybody who is using that tool is subject for identification which physical user, identical with which Wiki account, is looking at such questions. It can be monitored which Wiki account is interested and expecting which other Wiki accounts are connected. I feel reminded to a Big Brother authority.
• If such secret service means are built in it is necessary to make every user clearly aware that they are tracked and identified more than usual and expected. The general disclaimer on every WMF page does not tell that.
• In T187374 task description I fail to see any explanation why it is necessary to identify every single individual rather than recording the browser access data, which is almost unlikely to be shared by two tool users.

Persisting:

[XP6iKApAICIAAJV-xuIAAACS] 2019-06-10 18:32:10

At least no temporary DB lag.

https://de.wikipedia.org/w/index.php?oldid=5780804 reported last year:

Interner Fehler [W9n5NApAMEoAAJqHzzYAAABM] 2018-10-31 18:49:24: Fataler Ausnahmefehler des Typs „MediaWiki\Revision\RevisionAccessException“

Not convinced of my uselang statement any longer, cannot reproduce details and URL.

Thank you for now.

Well, the use case is that I want to edit those pages which transclude the redirect, in order to modify template name and old parameters, rather than pages transcluding the generic template name where new parameters are already used.

Thank you for your edit but you missed that one and also upstream notification which will trigger downstream dependency one day.

I count 88 pages in elwiki:Help: (including 14 redirects), but 900 pages (including many redirects) just as top pages in dewiki:Help: which indicates that there is an intensive usage in one project and a more relaxed in another wiki, and there might be projects with almost no helpful page in Help: namespace.

In T221892#5168211, @matmarex wrote:

But another idea was proposed – why not just move the sandbox page to a namespace where VE is enabled? The 'Help' namespace seemed like a good candidate to us.
Do you think that could be an option?

Blacklisting pageids could be a hard job, since there are more than 10.000 pages in talk structure on German Wikipedia project namespace.

Oh, yeah, there are thousands of talks; almost 5000 daily candidates for deletion, and village pumps and various help desks and some 10.000 archives of talks.

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.