Wikidata:Report a technical problem

(Redirected from Wikidata:DEV)

Report a problemHow to report a problemHelp with PhabricatorGet involvedWDQS and Search
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2022/10.

Start a new discussion

Misleading red error messageEdit

I've started seeing a big red error message "IP information for this address cannot be retrieved since no edits have been made from it." at the top of IP contributions when all of their contributions have been deleted. This is unhelpful and misleading. Bovlb (talk) 15:30, 11 September 2022 (UTC)

@Bovlb Thanks for bringing this to our attention. I could not find an example IP address whose contributions have all been deleted to look at. However, following the related conversations at mw:Talk:IP_Editing: Privacy Enhancement and Abuse Mitigation/IP Info feature changes, this message can be changed at mw:MediaWiki:Ipinfo-widget-error-ip-no-edits. In case there is something deeper to this IP info feature, the community can ask WMF to change it for all their wikis. Mohammed Sadat (WMDE) (talk) 08:08, 19 September 2022 (UTC)
Here are three examples for you: Special:Contributions/, Special:Contributions/, Special:Contributions/
So, do you plan to make it possible to investigate IPs in this scenario? Bovlb (talk) 15:36, 19 September 2022 (UTC)

Adding a new language code, ISO 639-3: ldn (followup)Edit

Previous discussion: Old revision of wikidata:report a technical problem (archive)

Requesting a status report of where in the process ldn is currently. — Arlo Barnes (talk) 07:49, 17 September 2022 (UTC)

Thanks for the reminder, and apologies that it's taken very long. I've pinged folks in the language committee (Amire80, Jon Harald Søby) who can okay the request so that we can move it forward. — Mohammed Sadat (WMDE) (talk) 08:20, 19 September 2022 (UTC)
Yeah, this is fine – sorry about the delay!
Sorry, I spoke too quickly (I mixed it with another language). According to the enwiki article on the language, it is a constructed language that is an "experiment in feminist linguistics" – i.e. it doesn't seem to be a general-purpose language with general use outside of hobbyist communities. I would therefore like to know more about what the intended use of the language on Wikidata is. That being said, it should still be fine at least for lexemes, and probably also for monolingual text.

user:Jon Harald Søby, phab:transactions/history/PHID-XACT-TASK-ktk5tmtioyycgnr#T302705-8244649

Regarding the quoted post in the phab thread by @Jon Harald Søby: I presume the other language in the mixup was Ladino (Judaeo-Spanish)? Láadan is indeed quite different from Ladino; as an artificial / constructed / artistic / planned language, ldn has 0 native speakers compared to lad's estimated 137 000. However, this is the case for several conlangs and extinct / classical literary languages already supported by Wikimedia projects, although I understand both categories are increasingly coming into disfavour for new proximate goal is not to start a new project, though (incubator:wp/ldn exists but is hampered by the creation of new pages being disabled) but instead merely to add & translate strings (including any or all of: content, UI strings, and lexemes) in existing projects, for the benefit of non-native users of the language — of whom a census has to my knowledge never been surveyed.

I would also like the state that the English Wikipedia page for the language is rather poorly structured, a lacking which I hope to remedy such, it doesn't clarify that the once-experimental status of Láadan and its framing within a field of feminist linguistics each have historical and culturo-critical relevance, but don't reflect the current state of things. I am also not sure what is meant by 'general-purpose'; as one might expect, any concept expressible in another language can also be expressed in Láadan, with more or less compactness (in some cases circumscription might be needed, but in others Láadan will tend to be terser than the compared language)...this concept is rather analogous to equivalence (Q65074105) in the context of programming languages.

For additional clarity on my aims, see betawiki:thread:support/Adding a new language, ISO 639-3: ldn (Request) and betawiki:thread:user talk:Álo/Laadan dictionary.

Arlo Barnes (talk) 06:50, 25 September 2022 (UTC)

Arbitrarily behaviour of the fast 'single entry' item mergerEdit

When I implicitly merge two wikidata items such that each is associated with just one wikipedia language version article, by using the only reasonably simple standard procedure, I would expect the older (and lower-numbered) item to be retained, with the recent item becoming a redirect. This is the natural procedure, which in general preserves most of the history; and it is the standard behaviour of the "merge with" tool, which I mostly use for merging wd items with several entries each. However, this is not the ways the simple entry item merger works. I suspect that it simply merges the item from whose single entry the merge is requested into the other entry, without any check whatsoever (except the demand of confirmation of the merge).

A concrete example: The items Q15757292 and Q65335706 had just one entry each, en:Saga (journal) and is:Saga (tímarit), respectively. Thus, I could initiate a merge by clicking the Add links button in either; but had no access to any Edit links button. (At least as most wp's are displayed for me, the Edit link button simply is replaced by an Add links button, if the article as yet has no recognised iw.) This starts 'the single entry item merger'—or whatever its technical name may be. I directly get up a dialogue box asking for a language version and an article to associate with; but no way to influence how the behind-the-scene wd item merge is to be performed. Well, I did this, starting from the short enwiki stub, instead of the longer iswiki article. (I didn't recognise that the enwiki stub was the older article; but I also didn't know that this was to be recommended.) As you can see, this turned the older item (history of Q15757292) into a redir to the new one (history of Q65335706); a not very nice outcome.

Now, I suppose that this situation should be common enough, when wd items for disparate language versions of the same subject start to be united. After all, uniting two of them logically is the first step. Hence, I think that it would be good to tweak the single entry item merger for the special case that also the target is 'single-entried', by in that case always merge the more recent item into the older one, without considering from which article the merge request was made. If a single entry item is merged with one with multiple entries, then you could argue that the multiple one in a sense already is the more complex one, even if it happens to be younger; but I can find no such mitigating circumstance when each item has just one entry each.

Regards, JoergenB (talk) 18:22, 20 September 2022 (UTC)

Interesting, I didn’t realize that this feature can merge items at all. Apparently it compares the number of sitelinks to decide which item to merge into which one (and has done so since 2013); that certainly doesn’t match the recommended practice on Wikidata, you’re right. Lucas Werkmeister (WMDE) (talk) 09:06, 21 September 2022 (UTC)
Hm, or does it? Help:Merge#Select recipient item (collapsed by default) says that The recipient item is usually the item that is used more often (possible indicators are the quality of sitelinks or the number of sitelinks and statements), and When in doubt, it's best to choose the item with the lowest Q#### (emphasis added). Lucas Werkmeister (WMDE) (talk) 09:11, 21 September 2022 (UTC)
FWIW, of the first 488k merged Q items (by whatever index Blazegraph's slicer uses), 99.88% involve merges into the earlier QId, 0.12% into the later QId - - which tells us nothing much w.r.t. Help:Merge's view, but was an interesting query to write. Yay PageConnector for doing it by the book, even if we might have doubts about the book. --Tagishsimon (talk) 10:07, 21 September 2022 (UTC)
You can get a better sample for the statistics by using only redirects whose latest revision has the tags "Sitelink Change from Connected Wiki" and "New redirect". I think it is possible to incorporate in the query using MWAPI with parameters prop=revisions and rvprop=tags. --Dipsacus fullonum (talk) 13:10, 21 September 2022 (UTC)
@Lucas Werkmeister (WMDE): Just a check of whether or not I understand the technical matters here: Would the site link count for 'single-entried' items automatically return 1? If that is the case, for the merge of two 'single-entried' items, we would always get equality in the crucial count comparison
if ( firstSiteLinkCount <= secondSiteLinkCount ),
and thus the value true of the test, shouldn't we? JoergenB (talk) 17:45, 27 September 2022 (UTC)
@JoergenB: I’d need to look into this feature some more before I could answer that question, sorry. If you think the merge behavior should be changed, please file a Phabricator task so it can be prioritized. Lucas Werkmeister (WMDE) (talk) 08:45, 28 September 2022 (UTC)

Search of structured discussionsEdit

Many users and some central noticeboards are using structured discussions. As I understand it, these are invisible to search, which seems like a problem. I am informed that the configuration parameter $wgFlowSearchEnabled might resolve this, but it's technically experimental. What do people think? Bovlb (talk) 15:35, 26 September 2022 (UTC)

I’m afraid it’s not that simple – the experimental code for supporting search in Flow was so badly broken that it was recently removed entirely (T317513). Lucas Werkmeister (WMDE) (talk) 16:02, 26 September 2022 (UTC)
@ Lucas Werkmeister (WMDE): That's a pity. Is there any way to boost the priority of resolving this? Bovlb (talk) 16:26, 26 September 2022 (UTC)
I understand that Flow was dropped in favor of the new talk page interface, but there are several use cases where Flow is more practical (especially in entreprise wiki). +1 on my part for resuming development on that wonderful extension. We're even willing to devote some coding resources to it if the WMF is on board with the project. Tinss (talk) 17:55, 26 September 2022 (UTC)
@Lucas Werkmeister (WMDE) 2600:6C5D:200:6C83:5E0:C5BC:1003:57FB 04:54, 3 October 2022 (UTC)
As far as I’m aware, mw:Extension:Flow is considered a technological dead end (you can see traces of this on-wiki too, e.g. in how Topic histories and diffs look nothing like those of other pages). I wouldn’t expect anyone at the WMF to be excited about putting more work into it, to be honest. (As someone who’s previously converted his own talk page to Flow, I hope that there’s some kind of plan for the longer-term future of existing Flow pages, perhaps by converting them back into regular wikitext pages, but I don’t know anything about that.) Lucas Werkmeister (WMDE) (talk) 12:35, 4 October 2022 (UTC)
Technological dead end it may be, it is in use in many places. We either need to support it or to have a transition strategy.
While we're at it, it appears that structured discussions may not generate appropriate variables for the abuse filter, making it impossible to apply abuse filters to all user talk pages. Bovlb (talk) 15:37, 4 October 2022 (UTC)
Indeed, it may be dead to the WMF, but it's user-friendliness (it uses patterns that are commonplace elsewhere on the web) makes it a very good choice for enterprise wiki. At least it works for now so the status-quo can be maintained. If support for it ends up being dropped entirely, coding a conversion maintenance script would not be too difficult for me. @Bovlb, if you are willing to get the search and abuse filter working again on Structured Discussions, I can be your code reviewer on gerrit. Tinss (talk) 16:01, 5 October 2022 (UTC)

CIDR notation in deleted contributionsEdit

With Special:Contributions, we can use CIDR notation, e.g. Special:Contributions/, but with SpecialDeletedContributions we cannot (e.g. Special:DeletedContributions/ This would be extremely useful for tracking spammers. Would it be hard to make this work? Thanks, Bovlb (talk) 22:03, 1 October 2022 (UTC)

Having dealt with a similar question recently, I think this is not easily possible. CIDR searching works via mw:Manual:Ip changes table which does not hold information about deleted revisions as much as I am aware. —MisterSynergy (talk) 18:09, 2 October 2022 (UTC)

iOS Safari or Chrome cannot add statementsEdit

Using a iOS mobile device; using either Chrome or Safari browsers, the option to add statements to a wikidata entry is not available- no "+" sign or whatever. Can create an entry but once created I cannot add statements. I can modify the description, but no way to add properties.  – The preceding unsigned comment was added by Muell132 (talk • contribs).

This might explain why we see so many empty items being created. Bovlb (talk) 15:23, 5 October 2022 (UTC)

Changes in search result displayEdit

There is a discussion at Wikidata:Project_chat#changes_in_search_result_display that would benefit from input from technical staff. Please discuss there, not here. Bovlb (talk) 16:29, 7 October 2022 (UTC)