@TheDJ Thanks, now I can update WP:Print description. But as for the web inspector and an OS print preview, I will need to search out more information on those to update it fully.

Right now, it seems TheDJ's script (to convert MediaWiki's server "printable version" into a browser "print page" dialog) is in effect. But then 1) shouldn't we first remove the "printable version" selection from the sidebar's Print/export section of tools? 2) Firefox Reader Mode is now not cooperating. (It's gone, but will show up on PHP pages such as from the "Permanent link" tool in the sidebar.)

In T88140#1005044, @Nemo_bis wrote:

Thanks for filing this report. I didn't expect such a feature to be missing, it would be nice to have a comparison table between LQT and Flow.

Would someone please implement either a redirect or a tech-news item?

An inlanguage: parameter would solve all the problems listed, yes.

@debt, to solve all the problems listed, present a search domain option based on language, just as we have already done with a search domain based on namespaces. (i.e. a user preference)

It's more reasonable now with 70 characters than it was before with 50. Thanks!

Per recent title changes, yes, a little text processing of title listings shows 28 of the 53 regex hits are found by hastemplate, like Template:Speedy: hastemplate: documentation prefix:template:speedy

The hastemplate query does work, but it does not find what the regexp query reports, which is actual template usage in a site with Translate.

Actually, there's an insource-wildcard workaround

• insource: special* (A, S)
• insource: preferences* (Nothing)
• insource: special:* (Nothing. Note the colon : character, not being treated like a letter here, as insource does everywhere else)
• insource: special* insource:/special:/ The desired workaround.

Cirrus search says indexed searches map words.

@Aklapper and @Deskana,

When live preview was used with FireFox, it neither gave Document Expired nor offered Try Again, you simply lost edits. Also, it was intermittent, at times 80% loss, but mostly 100%. The problem went away immediately with the revert.

In T124510 db808 has backed out of wmf11 per these several incidents.

I've personally lost several edits because it is my usual habit to freely browse around my live edit, and it is the custom to check a wikilink in a preview before saving the edit. I don't know how many others edit like myself, but any level is unacceptable for any other priority than UNBREAK now.

The gadget is now at 70 categories, automatically producing incategory:pagename1|pagename2|...|pagename70 for us. Thanks!
I assume this is the desired level for the gadget, 70 (raised from 50).

In T113838#1677270, @dcausse wrote:

Concerning the "researchers" use case, could you elaborate a bit more? Is it just counting word frequencies (we can extract a top term for some wikis if needed)?
We plan to replicate our production indices into a lab instance suited for experimentation, maybe it will be more appropriate for this kind of usage.

Wikicheck mentions URL-style internal wikilinks as error 90, "Internal link written as an external link". No bots fix them, but they are found and listed for cleanup.

Use HTML p-tags with style=font-size:small attributes. Inside the p-tags the spacing created by the <br /><br /> will be proportional.

If the font changes, the spacing should follow. I opened T124000 for vertical changes.

T37402 led me to mw.loader.load( "//de.wikipedia.org/w/index.php?title=User:Christoph Fischer (WMDE)/Gadgets/DeepCat.js&action=raw&ctype=text/javascript" (plus the CSS) on my enwiki acct.

The polling one sounds like a stemming issue, but the emoticon one sounds like a page ranking issue.

The page ranking algorithm is an internal bias.

Finding 0 now works. For example:
[0 prefix:mathie](//en.wikipedia.org/wiki/Special:Search/0 prefix:mathie) shows the 68 of the 183 pages in that prefix.

On WP insource doesn't search .css or .js pages.

1. user: intitle:css 24,916
2. [user: intitle:css update](//en.wikipedia.org/wiki/Special:Search/~user:intitle:css update) 2284
3. [user: intitle:css update insource:update](//en.wikipedia.org/wiki/Special:Search/~user:intitle:css update insource:update) 4 pages only

As if insource only lists .css and .js pages where its search term is found inside a comment or nowiki tag on the page.

Insource regex failed to find /disable/i /AJAX/i, or /ajaxcategories/i, but not other items on that page.

I think the regex wasn't being processed because of the double quotation marks. The regex only needs slashes now: "Phi Beta Kappa" insource:/ Phi Beta Kappa/. "1977 in literature" was not included, and I checked five percent of the 267 results (to make sure each one had an instance with the space).

But intitle does not search redirect titles.

OK. So an empty section can be kept for naming purposes, and tolerated because it signifies build information that is not obvious because it comes from specialized knowledge source. Redlink usage and purpose supports this method.

How it happened to become:

1. The Wikipedia manual of style allows for a "See also" section on disambiguation pages, naming two templates that can be used there.
2. Each template produces it's own Search link.
3. These Search links show up in print, so they are given a "noprint" class.
4. Since they are in a See also section, they come after a normal bullet. So this practice instantiates large numbers of the "empty bullet in print" problem.
5. A "noprint bullet" would seem to fix the problem. A bot-fix on literally ten thousand pages.

The examples show a WrestleReunion and an E57.
CirrusSearch tokenizer creates term boundaries terms inside camelCase and 4tokenizing forms.
It matters whether there were "quotes" around the search term.
Please ask at the talk page of CirrusSearch, where someone should be obligagated to say:

T95849 shows a direct analysis of a single unicode character from 6 mos ago, but has been put "up for grabs" twice, saying

• insource:/★/ shows 35, but misses Emoji and Miscellaneous Symbols.
• insource:★ finds nothing
• type-ahead-searching for ★ finds three titles that begin with that char, but intitle: ★ finds nothing.

I would add that prefix:★ finds nothing, and probably no indexed search handles unicode.

A namespace in the search box overrides the search bar's Advanced namespace selection.