MediaWiki:Sidebar in specific Wikibase Cloud instances can be edited, as far as I can see; e.g. I have edited the one in my instance, https://hypotheseis.wikibase.cloud/wiki/MediaWiki:Sidebar

Effectively no (at least as of now), the only problem I see is "IDs not being as predictable as they could be".

I confirm, it was my mistake; no triple is missing from the query service right now; thanks for the correct query and excuse for the disturb!

I have created https://hypotheseis.wikibase.cloud/wiki/Main_Page on 27/03/2024 and from that moment the issue has always been around.

After the solution of T347023 this seems solved too: in Wikibase Cloud the prefixes aren't removed, whilst in Wikidata they are removed and in the queries they are substituted by the full URIs; so in both the problem is fixed.

I confirm that the autocomplete (both in the search bar and while editing) of hypotheseis.wikibase.cloud has never had issues (as of now); the problem only affects Special:Search.

The service is not working perfectly: qualifiers and references aren't loaded in the query service.

Solved by T361551

I have edited the task to make it more general. I experience the same issue in https://hypotheseis.wikibase.cloud/query/ - I created the instance on 28 March 2024 and as of now the Query Service still has no triples in itself.

Although it is probably superfluous, I add that the same issue happens not only on English Wikipedia, but also on Wikidata, Italian Wikipedia and probably other wikis.

If I understand correctly, this would mean having e.g. https://database.factgrid.de/entity/ instead of wd: inside the queries, and no prefixes at the start of the queries; such a solution would not be an improvement, since it would make the queries much longer and, what is most concerning, much less readable, since prefixes significantly improve readability.
I think that the easiest fix should be simply avoiding that the "format query" button erases prefixes.

Thanks. I retried the previous one changing "query" into "sparql", but something is still mistaken: https://w.wiki/7NTz gives error 500 ... I don't have an answer from NLG yet.

Thanks! I checked with an easy one, https://w.wiki/7Mv3, and it fails due to

I edited the task to make it clearer. So, two statements X could be surely merged only if they have exactly the same qualifiers (e.g. X + qual. A with X + qual. A) or if one has qualifier(s) and the other has no qualifiers and no references (e.g. X + qual. A with X without qualifiers and references). Presently, the Merge process keeps X with qualifiers and X with no qualifiers and no references separated, which should be avoided.
Of course X with qualifiers should not merged with X with no qualifiers but one or more references, since the references could or could not support the qualifiers. I hope it's clear enough.

We need to reinforce our action to convince the most important databases in accepting, in a standard way, reports from Wikidata users. Recently, e.g., BNF started refusing any mistake report: https://www.wikidata.org/wiki/User:CaféBuzz/BNF. P.S. Today this ticket turns one!

In my opinion this is a serious problem, since it falsifies a relevant amount of the dates extracted from Wikidata items through queries; and it is impossible to extract native Julian dates, but they can only be extracted in their conversion to Gregorian dates (that, being automatic, can be sometimes faulty). The solution proposed, viz. keeping Julian date in psv: and adopting psn: for automatic Gregorian conversion, seems very good to me.
If there is no objection, I think this ticket should be raised to high priority.

Maybe this should be merged with T276876. I would suggest also adding T209559 as parent task.

Note: the problem of symmetric and inverse properties presently is solved through JS gadgets: https://www.wikidata.org/wiki/User:Magnus_Manske/consistency_check.js and many enlarged forks, most notably https://www.wikidata.org/wiki/User:Frettie/consistency_check_add.js, https://www.wikidata.org/wiki/User:JonnyJD/consistency_check.js, https://www.wikidata.org/wiki/User:Xmlizer/consistency_check.js.

Hi! I tried https://w.wiki/6i4V but I obtain the error "Service URI http://digitale.bncf.firenze.sbn.it/openrdf-workbench/repositories/NS/query is not allowed". I'm not sure about the reason.

See also https://www.wikidata.org/wiki/MediaWiki_talk:Gadget-Merge.js/Archive_6#Request_of_improvement:_merging_qualified_and_not-qualified_IDs (the problem affects also the gadget merge.js).

See this bot request, aiming to remove redundant aliases https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/Bitbotje_2.

As an example of massive removal of redundant aliases, see edits by user Bitbotje today (e.g. https://www.wikidata.org/w/index.php?title=Q1415472&diff=prev&oldid=1839731916, https://www.wikidata.org/w/index.php?title=Q1470646&diff=prev&oldid=1839734646, https://www.wikidata.org/w/index.php?title=Q1468693&diff=prev&oldid=1839734526).

Historical note: this develops an idea first proposed in 2022 for the Community Wishlist Survey (https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022/Wikidata/Dedicated_section_for_everything_meta_on_item_pages).

Historical note: this develops an idea first proposed in 2020 for the Community Wishlist Survey (https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Wikidata/Display_reference_in_edit_summary_when_a_reference_is_added).

Probably related with T327815.

On Wikidata lots of CSRF invalid token errors in these minutes.

Example: if the label is edited so that it becomes the same as an existing alias (https://www.wikidata.org/w/index.php?title=Q11906650&diff=1778265038&oldid=1604959354), we lose a valid name of the entity because the edit isn't rejected. In cases of massive edits through QuickStatements or OpenRefine, this could cause some damage.

Note: as of now MatSuBot (operated by @matej_suchanek) only merges claims of date of birth (P 569) and date of death (P 570); while the range of properties treated by the bot can be extended (see https://www.wikidata.org/w/index.php?title=Topic:Wxspna7q8jnn17u8), this means that as of now cases of duplication in other properties with datatype "time" (62 in total, so 60 properties) are remaining not treated.

See related T159160, mainly T159160#3096928.

This task was discussed in the Bug Triage Hour at the Wikidata Data Quality Days 2022.

Related task, specifically for the problem in merging items: T221610

Alternative version of points 2 and 3:

2. to automatically mark obsolete external IDs in a way different from other external IDs (e.g. some different color)
3. to give registered users the possibility to group obsolete external IDs in a subsection Obsolete identifiers of the section Identifiers and to autocollapse it through Preferences > Appearence (or > Gadgets)

Probably related task: T300201

Thanks, solved the case for P1476

I think that the violation message should be shown only if the property is used as main value, not when it is used as qualifier (see also https://www.wikidata.org/wiki/Q830798#P8189).

Are we sure that this is "Lowest" priority? Given that aliases which duplicate labels are an additional burden on WDQS (although probably not such a big burden), maybe we can raise a bit the priority of this ticket.

The task above could be updated: ISO 8601-2:2019 effectively supported EDTF (https://en.wikipedia.org/wiki/ISO_8601).

Update: https://www.wikidata.org/wiki/MediaWiki_talk:Common.css#Styling_Deprecated/Preferred_Ranks

Ongoing discussion about common.css at https://www.wikidata.org/wiki/MediaWiki_talk:Common.css#Styling_Deprecated/Preferred_Ranks

Maybe activating by default the gadget https://www.wikidata.org/wiki/MediaWiki:Gadget-SearchAll? It is already available in https://www.wikidata.org/wiki/Special:Preferences#mw-prefsection-gadgets. But it doesn't exactly correspond to this request, which I support, of course!

I reported a connected problem for the gadget Merge.js: https://www.wikidata.org/wiki/MediaWiki_talk:Gadget-Merge.js#Bug_with_aliases_identical_to_labels

Another problem of encoding: https://www.wikidata.org/wiki/Property:P2549 contains "&" in its IDs and due to encoding of "&" all the links are broken.

In a case like https://www.wikidata.org/wiki/Q191118, I tend to think a general label is not applicable (each language has its name for "tonne"); having "mul-lat" and "mul-cyr", I would set "t" as "mul-lat" alias and "т" as "mul-cyr" alias; having only "mul", I would set both "t" and "т" as "mul" aliases. Anyway, it is reasonable to start applying "mul" (or similar) with specific types of items (I tried to list them above; starting with some of them, as disambiguations, could work well).

If mul is in Cyrillic (e.g. it will probably be in https://www.wikidata.org/wiki/Q29652874), it will happen as follows in my opinion:

• "mul" label = Афанасий
• if a language code has no label, it will default to "Афанасий"
• if a language code has a transliterated label (e.g. "en" label = Afanasy), for this language code one of the aliases is by default "Афанасий"

This seems fine to me.

I think "the fallback to mul happens before the implicit fallback to en but after any explicit fallback" is preferrable (since I think Amphispiza bilineata is preferable to “Black-throated Sparrow”).

From Wikidata, I can say that having the possibility to filter out some tags from the watchlist (especially tags referring to semiautomatic tools such as QuickStatements and OpenRefine, which periodically flood the watchlist when big imports are done) would be much useful; selecting all other tags is very complex.
P.S. Maybe this ticket should be triaged?

There are at least 3 categories of items which strongly need this:

1. persons (https://www.wikidata.org/wiki/Special:Search/haswbstatement:P31=Q5, as of now 9.2M): in most cases the same label and the same aliases are repeated in different languages (e.g. in wikidata.org/w/index.php?title=Q19667413&action=history I can count 6 same-label additions: fr, nl, sl, ca, ast, sq; many other items are similar)
   • in the case of people, "mul-<script>" is required: names are the same only considering languages with the same alphabet, I'm mostly thinking about Latin alphabet
   • in some cases there could be the following problem: one Latin-script language may prefer a form (e.g. "Philip L. Brown"), another Latin-language script another form (e.g. "Philip Larry Brown" or "Philip Brown"); while the group of labels and aliases is the same for all same-script languages, which is the label and which is the alias may vary from language to language; of course, this problem occurs only when there is more than one form of the name, but in many cases this doesn't happen
2. given names and family names (https://w.wiki/3zWT, which counts Q202444 and Q101352 including subclasses, as of now 590k): in all cases the same label are repeated in different same-script languages (e.g. https://www.wikidata.org/wiki/Q21448867)
3. scientific articles (https://www.wikidata.org/wiki/Special:Search/haswbstatement:P31=Q13442814, as of now 37.3M): in most cases the same label is repeated in different languages (e.g. https://www.wikidata.org/wiki/Q27860672)
   • in some cases there could be articles with parallel titles in different languages (e.g. https://www.wikidata.org/wiki/Q59238742)

Considering also

4. asteroids (https://www.wikidata.org/wiki/Special:Search/haswbstatement:P31=Q3863, as of now 247k)
5. galaxies (https://www.wikidata.org/wiki/Special:Search/haswbstatement:P31=Q318, as of now 2.1M)
6. taxa (https://www.wikidata.org/wiki/Special:Search/haswbstatement:P31=Q16521, as of now 3.1M)

and still leaving out disambiguation pages (https://www.wikidata.org/wiki/Special:Search/haswbstatement:P31=Q4167410, as of now 1.3M), we obtain 52.6M items, out of 94.9M items, and probably the count could be further increased.

And now it seems solved; it lasted about two or three minutes.

I would suggest to set up automatically the expiring-watchlist not only for deleted pages, but also for pages which are moved (the watchlist adds the new title, but retains the old one): there can be a preference, enabled by default, that says that a redirect which is a result of a page move will automatically be un-watched after (e.g.) 1 year.

I report also https://www.wikidata.org/wiki/Property_talk:P9070#Backslash_decoding_problem, maybe it can be useful

Problem solved: edits weren't marked with "bot=1", now will be (see https://www.wikidata.org/w/index.php?title=Topic:W3feopgnunusmtn3).

I report here my issue: "As reported in https://www.wikidata.org/wiki/Property_talk:P9112#ID_IFLA_link_to_an_error_page, the link generated by https://www.wikidata.org/wiki/Property:P9112 always encodes # as %23 ( e.g. in https://www.wikidata.org/wiki/Q719309#P9112 links to https://www.iflastandards.info/unimarc/terms/key%23ab ), causing in fact a wrong link." Are we sure this is "low" priority? Thanks in advance!