I am seeing an similar issue on is.wiki at https://is.wikipedia.org/wiki/Kristín_Á._Ólafsdóttir . Can create an seperate bug if needed.

In T316559#8523516, @Theklan wrote:

I understand what the purpose is (telling the reader that some pages shouldn't have interwiki links). But... why? Why shouldnt a talk page be linked to another talk page? In which way is this good for our strategy? I would understand that the opposite is the good practice.

In T314620#8177537, @ovasileva wrote:

Seems like our next step would be to define a list of namespaces that allows for translation. Maybe something like:

@Intodesa: (intentionally using simple english) So, the issue clearly is that the page can not be linked to Wikidata. But, there is an issue underneath that one, which causes the page not to be linkable. Not sure to what extent, tho. In order to fix this, we need an namespace called "ကာရန်" in an seperate task, an task like T314023, just for "ကာရန်" instead of "Appendix" or "အဆက်လက္ကရဴ". That also means there needs to be an discussion on mnw.wiktionary on this namespace, just like there was one with Appendix.

In T47212#8484695, @VirginiaPoundstone wrote:

Looks like the boolean [[ https://www.wikidata.org/wiki/Wikidata:Property_proposal/thumbnail_sharpness | mimic property proposal ]]is not getting support.

In T256959#8440940, @Soda wrote:

I personally think this is the way we should implement this task:

• Implement a mechanism that allows Thumbor to retreive the dpi value if present in as a URL parameter and use it to render the image via Ghostscript (for example: /War_and_Peace.djvu/page1-1536px-150dpi-War_and_Peace.djvu.jpg should/could render the image with size 1536px and a dpi of 150) (This step is identical to what @Vlad.shapik is implementing)
• Write code to teach mediawiki-core's DjvuHandler (and also the PdfHandler extension) that the dpi value exists and that it can be used while fetching images
• Have ProofreadPage read the dpi value from somewhere and then pass it to MediaWiki core (my instinct would be to use a Index: page parameter for storage, since that is how ProofreadPage already allows users to set the resolution of the image).

In T26768#8445891, @VZpolodov wrote:

ImageMagick fixed the issue. Apprently it was a one == vs != mistake violating the documentation.

gAMA chunk is no longer written in SVG case.

https://github.com/ImageMagick/ImageMagick/commit/b51609986ae9d40ed0ea68bd8698a90f6d498b1f

So regenerate all?

Added a request to create a property, that specifies if sharpness should be used, as per the discussions of this task and the sister tasks of this task. See https://wikidata.org/wiki/Wikidata:Property_proposal/thumbnail_sharpness. Chose an item type property given the available property types, https://www.wikidata.org/wiki/Special:ListDatatypes. The property will not allow other inputs than yes (Q6452715) and no (Q1814990). The logic here is if "sharpness = Q6452715" then sharpness should be applied. There will be at least 1 to 2 weeks until the property gets created.

In T256959#8440628, @ShakespeareFan00 wrote:

Why can the DPI value for a given PDF or DJVU not be stored in the database directly as I indicated in my original suggestion ( I.E in the image links table.)?

The front-end at Wikisource can then just query the relevant field in the image links table, to supply to thumbor. (AS a fallback most likely, given that with the OSD changes, there was a suggestion elsewhere to support direct access to scanned images on reputable external sites like Hathi and Internet Archive.)

In T256959#8440164, @ShakespeareFan00 wrote:

The concern I have is that there would need to be a way for Wikisources to read the DPI value. I'm not sure if structured data would do that, as I wasn't sure ti was possible for one wiki to read project data from Commons directly.

The team that maintains the software that would be used for the front end is https://www.mediawiki.org/wiki/Structured_Data_Across_Wikimedia . The Wikidata team at Wikimedia Germany can also answer your technical questions, it is lead by Lydia Pintscher. In the following text I am going to explain the basics.

Possibly related: T256959, as in the linked bug might be an subtask.

Last time I checked the deletion processes across WMF wikis, 5 years ago, they where like so:

As far as Lua Wikidata calls go, you want to avoid mw.wikibase.getEntity, or at least suffix it, so it only fetches badges or whatever you are after in each case (f.x. not local entity = mw.wikibase.getEntity()). That is because it, unsuffixed, fetches the whole item. For statements you can use either mw.wikibase.getBestStatements(id, property)[1] - which skips statements that are ranked as being outdated/incorrect or mw.wikibase.getAllStatements(id, property)[1] - which gives you all statements. Looking at Module:Wikidata on es.wikipedia, that does mean changing the calls to the module aswell.

For the time Lua uses see https://grafana.wikimedia.org/d/000000139/scribunto?orgId=1&var-wiki=commonswiki
It will propably peak after the save as the pages move over to the new version and then normalize. So, compare the time after the save to when it was last edited.

Modified from F34933267

In T275319#7947012, @Krinkle wrote:

Question: Is there specific and limited concrete use case here that happpens to require a slightly higher limit to work? That is, is there some new structure or content type that has evolved that basically always needs a larger size to work, but is limited?

Tech News has reported on things like these, hence adding.

Just to be clear, the expectation of Wikipedians is that maintainance categories are up to date with an low delay. The remaining categories can be less accurate, as long as changes to each categorylink changes the count eventually. So, like 10 categories should be really well up to date, the rest not. This probably should have been said a month ago.

Communication needs to be redone. Since you are going to request permission, the requests UOzurumba has done for this task are done on Village pumps, not user pages. See: wikitech:Wikimedia site requests and meta:Requesting wiki configuration changes.

Communication needs to be redone. Since you are going to request permission, the requests UOzurumba has done for this task are done on Village pumps, not user pages. See: wikitech:Wikimedia site requests and meta:Requesting wiki configuration changes.

Communication needs to be redone. Since you are going to request permission, the requests UOzurumba has done for this task are done on Village pumps, not user pages. See: wikitech:Wikimedia site requests and meta:Requesting wiki configuration changes.

Communication needs to be redone. Since you are going to request permission, the requests UOzurumba has done on Swahili and Icelandic Wikipedias for this task are done on Village pumps, not user pages. See: wikitech:Wikimedia site requests and meta:Requesting wiki configuration changes.

sources for the claims in description: https://acl-bg.org/proceedings/2019/RANLP%202019/pdf/RANLP160.pdf (for GreinirT2T) and https://www.ru.is/faculty/hrafn/students/IndependentStudy_ApertiumIceNLP.pdf (for Aprertium and GoogleTranslate).

In T93049#7381360, @Quiddity wrote:

@Snaevar Thanks for the report. Unfortunately, (per the comment above in T93049#6512485) the detailed-version of the server-side logs for this system are only retained for a week, so the devs cannot investigate this example.

Both myself and the original poster at enwiki can see the regional/state borders but not the China-India border. For me this is not a zoom issue, I can replicate it on any zoom level.

Those are two separate bugs then. One issue in each. Improving description as requested.

Another example at 7 september 2021, 2 minutes apart:

That the message was not edited when these old bugs where newly fixed probably has something to do with why this was an issue.

Ok, it is just a change I did not notice being added then.

Youtube has an Zotero translator at https://github.com/zotero/translators/blob/master/YouTube.js and in it title, url, duration, date, author and description are configured. It is expected that most of these are returned by Citoid, except description and duration, which are not configured in the en:Template:Citation TemplateData Citoid mapping.
Looking at ZoteroBib, it returns mostly the same information as Citoid, except that it does also show the website. For some reason citoid is excluding that.

Other examples:
*https://nl.wikipedia.org/wiki/Tramlijn_Ginneken_-_Breda (works for me tho, but not for De728631)
*https://nl.wikipedia.org/wiki/Tramlijn_Ginneken_-_Mastbosch
*https://en.wikipedia.org/w/index.php?title=Mercury_vapour_turbine&oldid=987894401

Jeblad is falsely assuming here that the Icelandic alphabet order is the same as in Norwegian. That is not the case, and even the Icelandic alphabet has some letters which are not present in Norwegian, and vice versa. I added the current table sorting on the Icelandic wikipedia after some talks with other wikipedians on the Icelandic wikipedia. The sort order configured in MediaWiki:Common.js on the Icelandic Wikipedia is completely in line with the Icelandic alphabet.

Proposed solution: An converter that uses the language that an user chooses in the Universial Language Selector (ULS) extension to convert cardianal directions both ways: both from the user language and to english, and from english to the user language. This would be used for two seperate usecases:

1. When adding/modifying an geo coordinate: The coordinate converter would convert the cardinal directions from the language that the user chose to English, which would then be stored in the database.
2. When viewing an geo coordinate: The coordinate corverter would convert the cardinal directions from the database in English to the language that the user chose.

I would also like to mention that I used some regex in the BWDS list, so "haha+" (for example) is intended to also match repetations of that pattern.

I have finished reviewing the BWDS list.

I found examples of this error on is.wikipedia by using Quarry on Labs. Those are:

Not an bug with the Proofread Extension, but a bug regarding an gadget called OCR.js and the OCR tool at labs, which is being used on most wikisource wikis.

I have seen DerivativeFX at http://tools.wmflabs.org/derivative/deri1.php
Currently the webservice of the tool is down, though.

More examples of duplicate massmessage posts:

Fixed in https://gerrit.wikimedia.org/r/#/c/230014/

as per my previous comment and due to the fact that Ricardisamoa has not repurposed this bug.

This should probably be closed.