I find the middle-click paste and search now works. Thanks.

Thanks for the explanation.

If I use Ctrl+v I can paste the text fine, - but still has the T397506 problem.

I was copy-pasting with the middle mouse button on a Linux system. If I start at https://www.wikidata.org/wiki/Wikidata:Main_Page and copy-paste, then the text shortly appears before the "Items" dropdown" erases it.

And even if one repaste the text into the search field and press the search button one ends up on the front page instead of performing a search.

I do not see a User-Agent in my log. What I see is, e.g., something like:

[pid: 14|app: 0|req: 648/2912] 192.168.36.85 () {46 vars in 1028 bytes} [Mon Jun 23 13:56:07 2025] GET

Currently, I do not see far fewer failing requests now. Maybe the situation has improved. The author-disambiguator (at https://author-disambiguator.toolforge.org/ - not my tool) also had problem, but seems to work now, although it now has "Too many requests" on the main page.

I have got a problem again:

$ ssh toolforge
Connection closed by 185.15.56.62 port 22

I have been able to login to Toolforge and do become

Sometimes I can look into Toolforge. When then trying become I get sudo: a password is required.

There can be connections between forms and lexemes that are fairly complex. Selection between "c" and "k" are not the only ones. For instance, if you write a word with a latin-like inflection, say, coronavira (plural, indefinite) then you should probably write coronaviraene (plural) when you are using definite in the same text and you should not write cononavirussene or coronavirusserne. This could potentially extend beyond invidual lexemes in an editorial policy, e.g., use Danish inflections coronavirusser and kontoer, instead of foreign coronavira and konti. Mother is another interesting case. You would have two variations in singular "mor" and "moder" while one in plural "mødre". At one point I had "mor" and "moder" as two Wikidata lexemes if I remember correctly. Now they are one, see https://ordia.toolforge.org/L36819

@Ijon I am not entirely sure what you mean. L250372 - the Danish word "coronavirus" - is a lexeme with unusually many alternate forms. For instance, plural indefinite comes in six different forms: "coronavira", "coronavirus", "coronavirusser" (these forms are pronounced differently) and the forms with an initial "k" (they are not pronounced differently from the corresponding ones with "c"). Authoritative Danish sources regard them as one lexeme, see COR https://ordregister.dk/id/COR.53473.112.01 and DDO https://ordnet.dk/ddo/ordbog?query=wd&entry_id=49001914 . It is not clear to me what problems there are with re-use. Homographs and alternate forms are problems that we just have to live with.

I am not sure this is a problem. We now just make extra forms, see, e.g., https://ordia.toolforge.org/L250372 where there are coronavirus/koronavirus variations.

Some of the so-called open LLMs have a questionable license clause about non-competition. For instance, the LLAMA license https://github.com/meta-llama/llama/blob/main/LICENSE has "You will not use the Llama Materials or any output or results of the
Llama Materials to improve any other large language model (excluding Llama 2 or derivative works thereof)." I think such clauses are show-stoppers in a Wikimedia context. Much of Wikimedia content is used to train LLMs and output from an "Wikimedia-LLM" should have no such restrictions.

Thanks. I did not seem to have permission to edit the "Tool type" field.

I am not sure what that means. Is it something that I should do? https://tool-watch.toolforge.org/tools/1117 still shows unavailability.

A restart helped and it is also working from Ordia now. Thanks.

In regard to fallback ordering: In Scholia, I have tended to just use ISO alphabetic sorting with "en" as a priority, something like [AUTO_LANGUAGE],en,cz,da,de,es,fr,it,jp,nb,nl,uk,zh (the language in the list have tended to be rather random). Now that we have mul, this could be [AUTO_LANGUAGE],mul,en,cz,da,de,...

In T368816#10286507, @Gopavasanth wrote:

@Soylacarli, @Fnielsen, @Nux, thank you for highlighting the bugs and gaps in the tool! The issues have been identified, fixed, and deployed. Please let us know if the behavior has improved or if it continues to be the same moving forward.

The tool now exclusively tracks web-based tools, screenshot attached with new latest stats:
{F57671989}

Tool: https://tool-watch.toolforge.org/

As for the alerts on downtime, I’ll gather all the feedback mentioned above and develop a proper plan soon. Thank you for your advices and patience.

I works for me know again (in the meantime I have rebooted the computer). In "Network" it was all "200"s. I did unfortunately not grap the console output.

Yes. In Scholia, I have tended to use a lengthy list of languages, something like SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en,cz,da,de,es,fr,jp,nb,nl,uk,zh," . } to catch these situation. For instance, a lot of Czech books have been uploaded with only Czech label. For me, with a da or en environment, these would only show up as a QID. mul will to a certain degree help with the situation and @EgonWillighagen has been implementing [AUTO_LANGUAGE],mul,en as Scholia's default labeling service parameter now, but I think that [ANY_LANGUAGE] or similar would help

I am running Ordia at https://ordia.toolforge.org/. When I view the status at https://tool-watch.toolforge.org/search?search=ordia it says Unavailable, but the tool is available. For some reason the tool URL is https://github.com/fnielsen/ordia/wiki in tool-watch. Am I doing something wrong?

Fine. I haven't seen the problem for a while.

Thanks! I see that it works now.

I see

Error: Parse error on line 9:
... ?topic ?topicLabelWITH {  SELECT    
----------------------^
Expecting 'VAR', '(', 'WHERE', '{', 'FROM', got 'WITH'
    parseError https://query.wikidata.org/js/vendor.min.bdd0e0129540cadc7374.js:3
    parse https://query.wikidata.org/js/vendor.min.bdd0e0129540cadc7374.js:3

LineChart is also wrong: https://scholia.toolforge.org/event-series/Q7708376#acceptance-rate

Also reported for Scholia, where I first saw the problem https://github.com/WDscholia/scholia/issues/2539

I haven't seen the error in the last couple of days.

See also https://github.com/lucaswerkmeister/tool-lexeme-forms/issues/226

I has happened 8-9 September 2024. Sometimes the webpage shows ok. Could it be a load issue? It does not seem so according to the Wikidata log: https://www.wikidata.org/w/index.php?hidebots=1&hidecategorization=1&tagfilter=OAuth+CID%3A+2389&limit=500&days=7&enhanced=1&title=Special:RecentChanges&urlversion=2

I think it might have become faster.

Since 15 March 2024 the statistics for the Scholia Toolforge application has not been erratic.

I see that the property labels (sometimes) disappear.

There is a relevant diskussion for the enwiki here: https://phabricator.wikimedia.org/T6776

I now see that this is not just for a particular lexeme but for newly created (Danish?) lexemes, e.g., "dyreaktivist" https://www.wikidata.org/w/index.php?go=G%C3%A5&search=L%3Adyreaktivist&search=L%3Adyreaktivist&title=Special%3ASearch&ns0=1 see "dyreaktivist (L1326971)"

Now I see that this is not just for a particular lexeme, but for all (or at least those I have examined) newly created lexemes.

Thanks for the merge. I didn't see that issue.

I am no longer able to reproduce this issue.

I see the fix now. Thanks!

It is unclear to me whether the patch has gone into production, but as @Arian_Bozorg I also still experience the problem.

@Tarrow No, but I have not checked.

@Tarrow I have sampled a few items and could not immediately identify a problem.

It is probably the same. I am closing this issue. (is "invalid" appropriate)

The character is returned as "e1 b7 94" (U+1DD4, Combining Latin Small Letter Ae) in the CSV. The correct character should be U+00E6 or 0xC3 0xA6 (Latin Small Letter Ae)

I also added an issue in Ordia https://github.com/fnielsen/ordia/issues/172

This was probably a temporary issue. Now I see the page fine.

How do the WMF developers communicate? IRC, Phabricator, Slack, Wikimedia Chat?

In T335349#8836852, @Aklapper wrote:

Wikimedia Chat is an interesting approach, but it seems not to be directly supported by Wikimedia Foundation

Why does stuff need to be "supported by Wikimedia Foundation" (and what does that even mean specifically)? That's not realistic at all, ever.

I think that sticking to one in probably the best to avoid babelification. I would think that Mattermost is ok, - though I haven't tried it. Matrix.org could also be a solution.

For Scholia, we are tracking the problem at https://github.com/WDscholia/scholia/issues/2285

Wikimedia Chat does currently not work for me due to an email problem, see https://phabricator.wikimedia.org/T335471

I have tried with another email account, - a gmail-based account. That account does neither receives a verification email. And I still haven't received an verification email from my first try.

Yes, I tried after that, but no email came.

@Aklapper No, but according to https://wm-bot.wmcloud.org/logs/%23wikimedia-cloud/20230426.txt and https://openstack-browser.toolforge.org/project/chat he is the one assigned to the chat project. Should he not have been assigned?

I have rechecked my spam folder.

Thanks! I did not know or remember Wikimedia Chat. The sign up procedure is not documented though https://meta.wikimedia.org/wiki/Talk:Wikimedia_Chat#Registration

Currently it is not even clear how you log in. The page https://chat.wmcloud.org/login has no "Create account".

I haven't noted this since.

It works now. Thanks

Also tracked at https://github.com/WDscholia/scholia/issues/2237

I see a recovery now for mediawiki, wikidata and da.wikipedia.

This seems to be a general problem: https://www.wikimediastatus.net/#day The number of "Successful edits" have dropped.

Example

I have now edited the example I gave https://dreams.wikibase.cloud/w/index.php?title=Item:Q1149&diff=6989&oldid=6689 . That seemed to update the triple store.

This seems no longer to be a problem.

There is one here with 4 simultaneous queries: https://people.compute.dtu.dk/faan/dreams.html#projecttype/Q264

I can see the drop in the database:

MariaDB [s53734__toolviews_p]> SELECT * FROM daily_raw_views WHERE tool = "scholia" ORDER BY request_day DESC LIMIT 20;
+---------+-------------+--------+--------------+
| tool    | request_day | hits   | uniqueiphits |
+---------+-------------+--------+--------------+
| scholia | 2022-10-17  |     18 |            0 |
| scholia | 2022-10-16  |  68112 |         1411 |
| scholia | 2022-10-15  |  74693 |         1365 |
| scholia | 2022-10-14  |  72876 |         1382 |
| scholia | 2022-10-13  | 110044 |         2102 |
| scholia | 2022-10-12  | 147107 |         2228 |
| scholia | 2022-10-11  | 213019 |         2241 |
| scholia | 2022-10-10  | 109272 |         2113 |
| scholia | 2022-10-09  |     21 |            8 |
| scholia | 2022-10-08  |  50422 |         1581 |
| scholia | 2022-10-07  |     78 |            0 |
| scholia | 2022-10-06  | 101794 |         2028 |
| scholia | 2022-10-05  | 148375 |         2239 |
| scholia | 2022-10-04  | 109421 |         1940 |
| scholia | 2022-10-03  |  85109 |         1959 |
| scholia | 2022-10-02  |  50857 |         1645 |
| scholia | 2022-10-01  |  57698 |         1329 |
| scholia | 2022-09-30  |  56043 |         1332 |
| scholia | 2022-09-29  |  44681 |         1499 |
| scholia | 2022-09-28  |  90834 |         1861 |
+---------+-------------+--------+--------------+
20 rows in set (0,001 sec)

For Ordia at https://toolviews.toolforge.org/api/v1/tool/ordia/daily/2018-04-29/2022-10-16 I see that 9 October is entirely missing in the returned JSON (perhaps because of a zero in the database I could imaging) and so does quickstatements (https://toolviews.toolforge.org/api/v1/tool/quickstatements/daily/2018-04-29/2022-10-16).

The toolviews API now works again. There has not been any change drop since 9 October 2022

After a considerable time I get "502 Bad Gateway" from https://toolviews.toolforge.org/api/v1/tool/scholia/daily/2018-04-29/2021-11-18

I now experience complete lack of response from toolviews. Neither Scholia nor Ordia works (e.g., no response from https://toolviews.toolforge.org/api/v1/tool/ordia/daily/2018-04-29/2021-11-18)

Two issues:

• Would one be interested in linking senses rather than lexemes? A lexeme does not not necessarily correspond to one Q-item. For instance, Danish lexeme https://ordia.toolforge.org/L33929 would be a lighthouse (Q39715) or a heating unit (Q1409761). Is the sense the more appropriate level?
• Could the feature be implemented as just a Wikidata property that would link the lexeme/sense?

Graphana for Scholia seems not to reveal anything: https://grafana-labs.wikimedia.org/d/toolforge-k8s-namespace-resources/kubernetes-namespace-resources?orgId=1&var-namespace=tool-scholia&from=1665024544239&to=1665354435147

I would mean both UI and the database. It is a question of how series this is: there is already the labels and description for a large number of languages.

The items will have many links then. For water (Q29053744) there are current 849 language links (see https://ordia.toolforge.org/Q29053744). I think that will clutter too much.

I am not into the code, but the Wikidata Query Service code here seems quite innocuous: https://github.com/wikimedia/wikidata-query-gui/blob/master/wikibase/queryService/ui/resultBrowser/GraphResultBrowser.js#L218

In T317702#8251095, @Addshore wrote:

LIMIT 154 doesnt seem to work for me, but LIMIT 100 does.

I am under the impression that it is developed by @bd808.