In T3836#2887986, @Deskana wrote:

@eranroz @Kipod Can you please look at @dcausse's comment above and test for us? If things are working as you'd expect, then knowing that helps us a lot. :-)

reopened the task.

sorry for the noise: the brain-fart was when i marked this "invalid".

@Krinkle
sorry for the late reply.

The fix broke something else: now, subcategories categorytree appear as "empty" even when they are not empty: i.e., the # of pages in the subcat appears correctly, however, the right-side collapser is grey, and has class
CategoryTreeEmptyBullet, and can't be expanded, even for non-empty subcats.

Some additional information:
I made a change in a template in hewiki, that should have removed some 400+ pages from some maintenance category.

1. this is hipri for hewiki
2. why is this under "cirrus search" ? the actual description talks about updating the category content, not about search. the issues we see in hewiki match the description, but not the title.

@Nemo_bis : i looked at T37922, and they do not look to be the same. the other ticket is about "formatNum", this one is about "parseFormattedNum().

In T131387#2173417, @Nikerabbit wrote:

Language::formatNum and Language::parseFormattedNumber are solely intended for use for formatting numbers in the user interface (and the reverse is needed for the plural magic word). They are not generic number formatters or parsers – that functionality should be implemented somewhere else.

In T130995#2173375, @Florian wrote:

Hi,

thanks for your report. Unfortunately, I can't reproduce the problem. I've put the code inside my MediaWiki:Common.js, and edited a page afterwards (with different modi, like fast connection, slow connection, bypassing cache, with browser cache) and the hook always fired.

In T131040#2173835, @Anomie wrote:

In T131040#2173323, @Kipod wrote:

in the original request i wrote "if possible, in a tree form of some sort...", implying that if it isn't possible, a list of pages transcluded directly will also be much appreciated.

It isn't possible, transclusion records are stored as a flat list (e.g. Page A transcludes template B which transcludes template C, it just records A→B and A→C with no distinction that A→C is not direct).

A flat list would work, although it would need a limit so it won't use excessive resources if a page has a huge number of templates, and possibly continuation. Each call would likely have to count as expensive.

@Jdforrester-WMF :
i also noticed that you changed the original problem description to

In T131000#2174427, @Jdforrester-WMF wrote:

Aha. When you said "structure already exists in transcluded page" you meant "already exists on a page which is transcluded onto this page" not "already exists on a page where this page is transcluded", which is the normal user editing pattern. Sorry. Will re-title.

In T131000#2158838, @Jdforrester-WMF wrote:

Clicking "manage tempaltedata" on template page gives no indication that tempatedata structure already exists in transcluded page, which is not good when someone does not realize it and creates templatedata in template page even though another already exists in subpage

Not true. Are you using a version from a very long time ago?

in the subpage, the tool loses the capability of automatically generating TD, and offering to add missing parameters

Not true. Same question.

In T131040#2154424, @Anomie wrote:

Recursive transclusions are unlikely to be at all well-performing. Even
fetching one level should probably be considered expensive, and should have
a limit of some sort so it doesn't explode when someone asks for
transclusions of Template:Citation_needed.

are there pieces in the system that use Language::parseFormattedNumber in core other than scribunto? what for? which of them will break if this call will become stricter? (as i believe it should)?

This will be very useful, and seems straightforward

as a temporary workaround, see [[he:Module:ReadTd]]. this short module uses
mw.title.makeTitlet()
title:getContnet()
and mw.text.jsonDecode()

In T130016#2145460, @Deskana wrote:

the suggester is *supposed* to get the precise matches before the imprecise one.

@brion :
please read your user page on meta. i created a patched version of your script that works with all skins, although i could not fit the icon sanely on the non-vector ones, so i resorted to text.

may be a good idea to fallback on "old" suggestions if CompletionSuggester returns empty list, regardless of the reason (software bug, broken index, some server is down, whatever), at least as long as the "old" suggestions still available..

if i understand correctly, this really means that there was a change on wikidata that triggered this.

In T123276#1948781, @Krinkle wrote:

Works for me.

also: hotkeys help form is completely borked in hebrew, probably in all other RTL languages.

In T117716#1827324, @Jdforrester-WMF wrote:

In T117716#1827319, @Kipod wrote:

another approach, would be to teach VE to perform true section edit, which is what most editors expect when clicking the "edit" linkett next to section heading.

personally, i would vote for the second option. i vaguely remember several (many?) tickets requesting section edit

Patches welcome. Still.

one way to solve this is to switch to VE all-page edit, incorporating the changes performed in wikieditor (i think this is what the original description of this ticket, "Take new section content, splice into base revision's wikitext using replaceSectionAtRev." means).

As far as i could see, the existing patch is a stopgap rather than a solution.

In T116001#1742767, @matmarex wrote:

In T116001#1741474, @ori wrote:

There is still a large backlog of jobs, but it is shrinking.
Keeping this open until the queue is back to a manageable size.

The number of jobs stopped growing, but isn't exactly shrinking either.

(I'm looking at a graph here: https://wikiapiary.com/wiki/Wikimedia_Commons choose "Jobs" from the dropdown under the graphs. Do we have our own graphs for this somewhere?)

this request was closed as "duplicate" of T54141, which in turn was closed as "declined".

@eranroz: did you check to see if double quotes ( " ) character in article name cause same issue?
at least on hewiki, double quotes is somewhat common in article names.
(would check myself, but could not devise query for "recent article with quotes in name").

i see this is "closed, declined".
since another ticket, opened by me, was "closed, duplicate" pointing here, i would like to request to reconsider.
implementing my request should be very easy, controllable, requres no changes outside VE, and very simple change inside VE, and, oh, by the way, will also close/solve this one. so i paraphrase my previous request here:

whoever closes this ticket - i think it may be good idea to redefine it as:

In T51506#1439722, @Bawolff wrote:

It is not yet available via the API. That is a future todo