For information: this should be done per property, as some properties is not appropriate to be archived (email, archive URL, irc, etc); by contrast, external IDs may be useful to be archived if the target page includes some useful information.

@Chicocvenancio, can you debug it? This impedes me from using the tool.

In T171648#3971534, @Aklapper wrote:

In T171648#3968816, @Bugreporter wrote:

Reopen.

1. "Search" button can not search indirectly related tasks in a task graph

And it won't as Phab won't display hundreds of tasks. Performance.

I'm not request to increase the size limit of task graph. This is said about if we can display a task graph within maximum size, it should not be truncated, or otherwise there should be a way to view it (which the search button can not).

1. Showing the full task name instead truncate it is more user friendly even if task graphs will have scroll bars

You can always zoom out in your browser.

Some browsers do not have this features, especially mobile browser which we can not append JS and CSS either. Hide the task graph is also not the optimal way to fix the problem - thebest way is always show the full task name and show a scroll bar if necessary.

Reopen.

1. "Search" button can not search indirectly related tasks in a task graph
2. Showing the full task name instead truncate it is more user friendly even if task graphs will have scroll bars

I don't think we have many votes, given the community is small.

I have instead posted my idea at T174874: Create a standalone Wikimedia CAPTCHA service.

See https://en.wikipedia.org/wiki/Wikipedia:Perennial_proposals#Use_reCAPTCHA and T34695: Implement, Review and Deploy Wikicaptcha

When this bug is just closed, viewing pages on a private wiki did redirect to login page.

We may introduce the concept of "virtual" site. There will still be one siteline per wiki, but some wikis don't have it's own site and exist on another site.

e.g. https://incubator.wikimedia.org/wiki/Wt/lus/la and https://incubator.wikimedia.org/wiki/Wt/diq/la will show a sitelink to https://en.wiktionary.org/wiki/la in sidebar, and vise versa.

You can enable Cognate there without excluding them from ordinary Wikidata links. For the case issue, the best approach is to set $wgCapitalLinkOverrides in these wiki, and manually fix remaining case issue (there're not too many to fix).

The patch introduced in T72855: Login as another user no longer works did reopen this task (per description), You may confirm it here: https://checkuser.wikimedia.org/wiki/test

I think we should remove the message keys about these extension names.

Note disabling adding link widget will make people confused. The better approach is lead them to a request page if their actions involve item merger.

For example in French version, The name of Global CSS/JS are translated as "CSS/JS global", where most extension names are untranslated and not translateable. I don't know whether it is the intended behavior to allow translation of extension names. (If Yes, why most extension names are not translateable? Should the extension list be sorted by translated names?)

more strange behavior are reported in T173662: Apply correct fallback for messages displayed on interface.

No longer needed, see T173383: Add Atayal (tay) to Names.php

However as qualifiers are unordered, if there're both multiple properties and multiple values, it will be unclear which property a specific value is applied.

In addition, the merge gadget should either 1. also support reporting a merger to a dedicated page (need small improvement) or 2. be usable only by (auto)confirmed users.

If non-confirmed users try to link two pages with merger needed, we need to display a new page with both old and new item IDs, and a page that merge can be requested (I have created Wikidata:Proposed mergers).

Probably I have also met this problem, though I don't know whether I can reproduce it again. Maybe related to T172776: Property labels missing on some items and T171460: Populate term_full_entity_id on www.wikidata.org

Duplicate with T167864: Enable support for the creation of new items?

Importer may be a bit dangerous. You may consider transwiki group instead once some transwiki sources are set up. See T63238: Remove ability of sysops on zh.wikivoyage to grant and revoke "importer" permission

See also my related idea at T170696#3484089.

Added some more users who should be aware of the issue. Feel free to remove.

I think we should replace the current "relation" property to two new properties A and B (don't know what's the suitable name)
A is like the 'instance of' property, B is like the 'subclass of' property. Item X is in class Y iff X <a> Y1 <b1> Y2 <b2> ... <bn> Y, where a is one of A's value (or X=Y1 if a=novalue), b1, b2, ... are one of B's value, n is non-negative integer.

I have fixed the interwiki link.

For example https://als.wikipedia.org/wiki/Wort:Houptsyte is the main page of Alemannic Wiktionary. (The actual Alemannic Wiktionary was merged with Wikipedia and closed, and is proposed for deletion)
And https://als.wikipedia.org/wiki/Wort:Haus is an entry for the term "Haus"

Yes, we need instance of animal or subtaxon of animal.

But we does not support this either.

Currently P569 have type=human (Q5), fictional character (Q95074), dog (Q144), horse (Q726), cat (Q146), giant panda (Q33602), gorilla (Q36611), chimpanzee (Q80174), elephant (Q7378), Pan troglodytes (Q4126704), polar bear (Q33609), killer whale (Q26843), American alligator (Q193327), Bonobo (Q19537), Ursus arctos (Q36341), Asian elephant (Q133006), orangutan (Q41050), Kodiak bear (Q237260), hippopotamus (Q34505), this is unmanageable if more values are added.
P570 have type=human (Q5), fictional character (Q95074), animal (Q729), which does not work as dog and cat is not subclass of animal but subtaxon of animal.

Project type: Group
Description: Project for the Meta-Wiki community.
Policies: Public

Should this still be fixed? see T160931: [Bug] language links show up on edit page with Cognate

This is unrelated to wikiba.se (the website that documents Wikibase). Instead we need a Meta-Wiki project.

Just a note: Only allow the users themselves to edit items about them is impractical, as properties and items is managed by community, and sometimes properties get deprecated or items get merged. Probably we need a new user group to manage them.