Not sure if this is related, but this page reports a nearly 7-hour replag (as of this comment) for Wikidata's shard (which strangely is not what Special:DispatchStats is reporting).

I have noticed this as well when I need to form a relatively small number of QuickStatements queries in a non-Bengali language (i.e. not in my interface language) and I have to remove "ইংরেজি" or some other language name from the text file I'm using as my canvas after ripping the results from Special:Search.

In related developments, we now have a LilyPond notation property. Here's hoping that it is put to good use.

I figured as much about sysops and bots being automatically patrolled. Sysops should be able to grant the autopatrol flag.

Thank you for your comments @Ebe123; I will see if I can get a MediaWiki instance running on my laptop so I can examine the extension myself. I have noted your points regarding new bug reports.

@Zoranzoki21: Yes, the Publisher: namespace should also be searched by default, in the same way that the main, Author:, Portal:, and Translation: namespaces are searched by default (or at least that's what an advanced search sets by default). Also note the comment I made on your patch.

Hi @Jonas: I blocked that particular range, among others allocated to Telefonica Germany, in an attempt to enforce this global ban. @Multichill and @MisterSynergy can tell you more about what has been going on. If you'd like me to lift that particular range block, I'd be happy to do this, but please be aware of what you may be allowing to happen.

@Lydia_Pintscher (See the larger of the excerpts from my proposal on Wikidata:Project chat that Jc86035 included in the task description.) We initially stored population data as individual values on an item, but later began storing it as links to Commons tabular data (properties 1082 and 4179 respectively). We also store isolated mathematical expressions, not full derivations or proofs, as LaTeX snippets, and it would not surprise me if someone came around and proposed a property for links to derivations and proofs hosted on Commons (whether as raw LaTeX or otherwise). It would therefore make sense to initially store as statements musical snippets that fit in the 400-character limit for strings, and then later once a MuseScore extension for MediaWiki comes to fruition (or if Extension:Score is significantly revamped) link to full sheet music on Commons. The specific examples on the property proposal that Jc86035 created should not cause copyright problems, and I personally would not have a problem if we need to restrict such a property's use on items for copyrighted music.

Any reason why the language code for this isn't 'es-x-Q653884' or something similar, in the same way language codes are being devised for lexemes at present?

@WMDE-leszek: no, I also have used wb_terms to clean up descriptions and aliases as well; for example, I will most likely find some time to move gom entries to gom-latn or gom-deva as appropriate (similar things are possible for ks, crh, gan, ku, ruq, shi, ug, and with some difficulty sr, tg, tt, and kk). (Apologies for the delayed reply.)

I do not operate any specific tool that uses wb_terms—instead opting to write simple queries—but there are a couple things I have found useful about that table:

The language could be a superscript, as it is when labels for items in Special:Search are presented in a language different from the interface language, and the form could be a subscript. Borrowing Nicolas's example, L62 could be presented as "gwez _noun ^Breton (L62)".

At present there are the following, stripped of the "Index:" prefix, that appear in only one of the lists Andre linked to:

In T61983#3895884, @Dzahn wrote:

please see T184664#3895870

noto fonts are now installed on mediawiki app servers

I compiled the latest SVN version here, @Aftabuzzaman, and the Bengali edit summaries show up. Here's hoping that there is an official release soon, @Reedy, @Rjwilmsi, and @Magioladitis.

I am rewriting it now to support modern graphics libraries that allow different fonts, ligatures, right-to-left etc.

I'd go ahead and close this as invalid. He should be made aware of the need to reupload the image in question to Commons, though.

La imagen de lo que escribe Ud. no fue subida en Commons y por eso no la puede usar. Tiene que subirla allí, y ya que la licencia de la imagen es CC0 lo puede hacer si mismo.

@Aklapper You appear to have mistyped his username. This seems related to T186945.

I just noticed, @Reedy, that only a select few Noto fonts are actually in the noto-fonts package; the rest are in noto-fonts-unhinted and noto-fonts-hinted, so they should be added as well. (There are also noto-cjk and noto-cjk-extra, but I’d rather speakers of languages using those fonts weigh in for those.)

Per T184664 Noto fonts will soon be available for rendering SVG images. These necessarily include (not yet since those particular fonts aren’t available in Debian jessie) Noto Sans Bengali and Noto Serif Bengali. @Aftabuzzaman @MoheenReeyad @Tarunno what do you think of those two fonts?

Per T184664 Noto fonts will soon be available for rendering SVG images.

On a related note, per T184664 Noto fonts will soon be available when rendering SVG images.

The idea, @Ebe123, is for this module to take LilyPond markup and render it as the appropriate series of tables (it may however be advantageous if these tables are produced graphically to reduce DOM clutter rather than rendered by the browser)—in other words, have the separate "\relative c" and "\addlyrics" commands such that the regular score extension with the markup gives you the Western notation and this module with the markup gives you the swaralipi equivalent. (Here, for example, ideally the same LilyPond markup should be used for outputting both of the staves, which represent the second line of music on this page.) Hardcoding the tables is not optimal and prevents reuse in other notation formats, which reduces the accessibility of this music only to those able to read (this format of) swaralipi.

The previous bug report by @jayantanth himself was closed as invalid. Also the format used by Tagore (as shown in the link in the task description) differs in several respects from that used by, for example, Hindi/Marathi composers (see the page previews here and here), so simply asking the developers to support 'swaralipi' makes little sense.

@greg Okay, thank you for the clarification. I will close this task after Monday, then. (Probably should fix the URL I linked to, though.)

@Sjoerddebruin @Smalyshev @greg What’s up with https://tools.wmflabs.org/versions/ then? Are dewiki and wikidatawiki versions just not reported correctly there?

@debt No, the results are simply not appearing. The JSON response is still normal, up to the warning I mentioned above, but the results do not render on screen. The symptoms as listed in the task description still persist. See the screenshot in the task description.

This task reminds me of T114318.

In T173145#3527784, @dbarratt wrote:

Are you implying that, to understand any of the arguments posted here, I must first acquire a 'secret knowledge' that can only be obtained by further participation in the community?

In T173145#3524145, @dbarratt wrote:

I do not understand the validity of any of these arguments.

Added three supporters and three opponents of a related property proposal. (I wasn't able to find Innocent bystander on Phabricator.)

(subscriber removed in the spirit of @Sjoerddebruin's request)

I would also recommend Hind Siliguri and Noto Serif Bengali (both SIL OFL). I am unaware of any fonts that encode U+09FC and U+09FD yet.