I must agree with Bodhi here that having a code for sat-olck is still necessary as it is not guaranteed that Santali speakers outside of India will be able to read it. "Official" in India need not mean "official" in the other countries in which it is spoken, as a closer read of the article on the language should indicate.

I have recently migrated all uses of "bat-smg", "bh", "fiu-vro", "roa-rup", "zh-classical, "zh-min-nan", and "zh-yue" on labels, descriptions, and aliases to "sgs", "bho", "vro", "rup", "lzh", "nan", and "yue" respectively, so now would be a great time to at least disallow those language codes.

I have recently moved all uses of the code "zh-classical" for labels/aliases and descriptions to use "lzh" instead, if this helps anyone.

@Amire80 To my knowledge it is not mandated anywhere that all variants of the representation of a lexeme lemma/form must use Q number private use subtags, but rather such uses are possible if other existing subtags within BCP47 cannot adequately indicate the necessary differences. The indication of Japanese written in different scripts can already be done with the BCP47 script subtag, so (¡¡¡)within the scope of language codes(!!!) the items I mentioned which are currently being used for those indications are redundant. Also, as I noted above, the distinction between kyujitai and shinjitai does not lend itself to a non-private-use indicator within the set of possible "ja" language tags, so this task is not meant to discourage the use of those private use subtags in that case.

What time on September 1st was this? According to https://lists.wikimedia.org/pipermail/commons-l/2020-August/008161.html it appears the data is reloaded every Tuesday around 9am UTC; perhaps after two days your changes will then manifest in the query result.

This applies to the Mattermost mobile apps (for iOS and Android).

Now that the only patch tied to this ticket has been abandoned, and now that the Commons Query Service beta uses the sdc: prefix, can this ticket be closed?

In T261420#6416738, @AntiCompositeNumber wrote:

This script, called on page load, replaces every number in a thumbnail URL with that number truncated to an integer, which strips leading zeros. It was placed in MediaWiki:Common.js by Sushant salva in this edit. I'm not sure what problem it's trying to solve, so I can't really recommend a fix short of completely removing it.

(As a note, a patch for this task was already made at https://gerrit.wikimedia.org/r/616609, although it is likely that it did not show up here due to the absence of the line "Bug: T258982" in the patch description.)

@Jdlrobson I was under the impression, based on "Assuming you do not want to do a big redesign and just want to retain the existing main page design, you can follow this guide." in the link given under "Option 2" in the task description, that simply rewriting the main page so that it does not use tables and inline styles was sufficient for remedying the issue put forth by this task. If there is some other requirement for mobile main pages that I am missing, I'm happy to incorporate that.

Have you tried adding a space between the '"12"' and the ']'?

Are you sure this isn't due to the presence of "[[User:Frettie/consistency check add.js]]" in your common.js?

In T249467#6046033, @0x010C wrote:

After a bit of time the purge has been effective ;)

In T208425#5992965, @Bugreporter wrote:

To find the number of labels in a specific languages, you can use ElasticSearch: https://www.wikidata.org/w/index.php?search=haslabel%3Abn though this will not work in aliases.

This does not yield a number that I would expect; for a language like Khowar (khw), which is not updated frequently (or at all?) on Wikidata, I obtained a number close to 270k when searching "haslabel:khw" today, which compared to the numbers in this table for that language doesn't make much sense.

I have a query, https://quarry.wmflabs.org/query/18763, that returns label/description/alias statistics for a set of languages (also mentioned in T197161#4300061). This was derived from a query used by @Pasleim to update this table (which worked until the end of May) and its South Asian counterpart (which worked up until wb_terms updates got turned off). I tried to rewrite the Quarry query to use the new databases (https://quarry.wmflabs.org/query/41692), but running this has not yet succeeded, either using Quarry or directly on tools-login. I am not sure whether this rewritten query can be simplified beyond what's written at present, so I was hoping there might be a better way of obtaining these statistics via SQL that does not presently time out.

The use of the API works up to a point. I am noticing that for GeoJSON files at or above 250KB I'm getting read timeouts when using Pywikibot. Any way to get past those errors?

In T234788#5635338, @Lucas_Werkmeister_WMDE wrote:

He has not circumvented any size limit check.

So somehow @Sic19 managed to circumvent the size limit check with "Data:Canada/Nunavut.map" (I suppose AWB is old enough that it's not sensitive to the workings of tabular data). Is there a way to make the size limit check apply to the compacted data?

As a note, this is desperately needed for a number of Indian languages (including Bengali) in which the standardization of spellings according to one standard or another does not preclude other spellings from being considered acceptable (even in the absence of some characteristic unifying the alternative spellings).

This error was the result of a title blacklist rule, which has been adjusted. (Once we get to L1000000, it will need to be adjusted again.)

@StevenJ81 what are your thoughts on this request?

32 months later, @Yurik, what's the status regarding implementing a new storage architecture for datasets (assuming that a stopgap measure such as uploading JSON in compact formats is somehow not tenable)? T200968 has officially opened up the floodgates for the upload of larger datasets, but there is still the issue, even when one does split up the data into discrete chunks, of overshooting this 2MB limit. Take, for example, the boundaries of https://www.wikidata.org/wiki/Q338425 : how does one properly split the data up into small chunks when the borders of its constituent elements (which I'm sure people would upload separately if those constituent element borders formed a partition (set theory) of the district) are not known?

In T200968#5330363, @eranroz wrote:

I uploaded a fixed patch to:
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/JsonConfig/+/456506/

In T226764#5297684, @Urbanecm wrote:

[T]he purpose of local uploads in your wiki is to upload files that are free under local law, but aren't free under U.S. law. That seems to violate the licensing policy, which says that an EDP must be in accordance with both local and U.S. law.

The bug, if there is any, is in GeoNames or in wherever else @Lsj's bot obtains its geographic information. Ultimately it must be corrected there or there is still a risk of reintroducing it to Wikidata.

This task seems similar to T199887, at least judging from the examples given in the task description (haswbstatement:P734=Q18390678 and haswbstatement:P171=Q127134).

To present a more concrete use case for such functionality, @debt, the infoboxes on articles for localities in India have slots listing the national/state-level parliamentary constituencies that they're located in along with the current representatives in those constituencies. These slots, which at one point were prefilled from Wikidata, no longer work since the misuses of P585 ("point in time") on the Wikidata items for those constituencies that allowed such information to be present have been removed. In the absence of a property linking a Wikidata item about a constituency to an election involving that constituency (to use the example of a national-level constituency in Kolkata, from Q3348171 to Q63988950), it would be helpful to obtain a list of items which link back to an item for a constituency via something akin to haswbstatement (in this case, to continue using the previous example, akin to haswbstatement:P1001=Q3348171) so that the most recent election information (from electorate size to successful candidates to numbers of spoilt votes, to name a few facts) could thus be obtained with a few more steps.

Perhaps this issue of conciseness in the data model is something worth addressing to @Smalyshev and @Gehel?

@ArielGlenn It appears that particle physics is a massively collaborative enterprise, so that the results presented in a single paper can have thousands of people behind them, all of whom are credited (hence the particularly large revision size).

@Mrjohncummings @MSantos have any clearer directions for development come out of your February discussion?

https://quarry.wmflabs.org/query/28286 lists all pages in the Page: namespace below 500 bytes, in ascending order of page length (so that the shortest pages in the Page: namespace show up first). The commented lines, if uncommented, will list those pages that have already been proofread but not validated--this is presently based on links to the category "Proofread" rather than page properties, but I'm sure this can be fixed easily.

While I believe it is possible to get a list of such pages via Quarry queries, being able to view these within the special pages themselves would be quite helpful (and not just for the two aforementioned namespaces, and not just for Wikisources either).

I made the circular element for WikiProject India's regular logo (https://commons.wikimedia.org/wiki/File:WikiProject_India_bars.svg) as a substitute for the chakra in the center of the Indian flag, and not initially in the interest of having a logo fit perfectly inside a circular frame. (The logo which is present on the account to which David linked is meant to represent a datathon running from the 21st to the 24th and will be substituted with the regular logo at the datathon's conclusion.)

That looks great!

Is the language that odd? https://en.wikipedia.org/wiki/Okinawan_language

Ideas regarding the open questions in the task description:

Concern has been raised about semi-protection of these items here.

I suggested separate codes for separate scripts in this instance because of a situation in another language (Meitei) which is frequently used with two different scripts. While the CLDR indicates that the language exclusively uses the Eastern Nagari script, a contributor to Wikimedia projects (User:Awangba Mangang) has been providing localization exclusively in the Meetei Mayek script.

I would recommend adding separate codes for ccp-beng and ccp-cakm since both writing systems (Eastern Nagari and Ajhapath) have been used to write the language.

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.)