It looks to me as this is solved per https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-PermissionOTRS.js/Archive_1#Add_P6305_SDC_statement so perhaps we can close this?

This appears to be a past hackathon project that has now concluded, and as a goal outside the context of the hackathon (as it now is), it would be outside Phabricator's scope.

Change #595339 abandoned by Thiemo Kreuz (WMDE):

[mediawiki/extensions/AdvancedSearch@master] Make MenuSelectWidget non-namespace-specific

Reason:

Unfortunately Ib9ff8f0 added a bunch of namespace-specific code to this class. It's better to customize a copy.

https://gerrit.wikimedia.org/r/595339

@Gopavasanth Using this API shall we get autogenerated subtitles?
There are two other ways also via which we can add subtitles first one is using react library for parse subtiltles files,or second thing we can do is we have to write manually all the subtitles followed by the step of WebVTT,I know this will reduce the productivity,but let me know how we basically add,by typing manually and storing hem an in array or by using some sort of api?

Yes but this adds many constraints on talk pages (e.g. with archiving of discussions, or people attempting to talk and posting incorrect links to categories in these talk pages, that will become then hard to cleanup if everything is mixed (forcing to edit all these discussions, especially if they post contents with template calls). The alternative would be to use other talking systems, but LiquidThread for example is no longer maintained and has its problems.

The regular thing is to categorize the talk pages itself, instead of the pages.

Is there a way to categorize tabular data in Commons' "Data:" namespace?

I have asked one of the authors of the Module:NUMBEROF about writing something similar than can lookup for rows and columns: https://fr.wikipedia.org/wiki/Discussion_utilisateur:Verdy_p#Using_something_like_NUMBEROF_to_query_.tab_data_at_Commons

The OSM Sophox service, which is based on WDQS, has or had a SERVICE wikibase:tabular which appears to have providing this capability,
see https://wiki.openstreetmap.org/wiki/Sophox#External_Data_Sources
so there may be code already in existence that could be merged, or at least used as a basis

I wonder... would this work? https://en.wikipedia.org/wiki/Module:NUMBEROF

If it is running as an separate service and data would be queried via federation then SPARQL-anything could be used

• https://github.com/SPARQL-Anything/sparql.anything

Removing task assignee due to inactivity as this open task has been assigned for more than two years. See the email sent to the task assignee on August 22nd, 2022.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome!
If this task has been resolved in the meantime, or should not be worked on ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!

Removing task assignee due to inactivity as this open task has been assigned for more than two years. See the email sent to the task assignee on August 22nd, 2022.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome!
If this task has been resolved in the meantime, or should not be worked on ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!

Removing task assignee due to inactivity as this open task has been assigned for more than two years. See the email sent to the task assignee on August 22nd, 2022.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome!
If this task has been resolved in the meantime, or should not be worked on ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!

@Ainali the WMDE-TechWish team reviewed and updated the Kartographer documentation recently as part of our project to improve Kartographer in WMDE-GeoInfo-FocusArea. I believe all the open items in the ticket have now been added, with the possible exception of:

It sounds like Amazon are dropping mobi support for the email-to-device service: https://www.mobileread.com/forums/showthread.php?t=346616 https://news.ycombinator.com/item?id=32079175 (I can't find an official source).

About done with this for now. Result: thorough hate of react :)

Per comments on lack of clarity on what is being proposed and lack of continued interest from @Chtnnh. Feel free to reopen when and if a more concrete plan can be described.

I propose to decline this task per last comment. :-/

For COVID items, a workaround is spliting them to yearly items.

In T181319#7792296, @Mike_Peel wrote:

Just to comment that the example came from https://www.wikidata.org/wiki/Special:LongPages - you can see the first page of these is either COVID or journal article items. It maybe a case of changing the approach of an editor or two on-wiki to avoid these situations arising, more than it requires software changes, though.

Just to comment that the example came from https://www.wikidata.org/wiki/Special:LongPages - you can see the first page of these is either COVID or journal article items. It maybe a case of changing the approach of an editor or two on-wiki to avoid these situations arising, more than it requires software changes, though.

In T181319#7788961, @Manuel wrote:

Note from Wikidata Data Re-use Days: @Mike_Peel Q says some Items are huge (e.g. 4.3MB for Q87483673). This is problematic! @Mahir256 noted that this task might be a solution.

Note from Wikidata Data Re-use Days: @Mike_Peel mentioned that some Items are huge (e.g. 4.3MB for Q87483673). This is problematic! @Mahir256 noted that this task might be a solution.