Seems to work on Drucker now but still not on Windschutscheibe nor on https://hr.wiktionary.org/wiki/Trommel

Second example here: https://hr.wiktionary.org/wiki/Windschutzscheibe

Argh! Note that Z34148 passes, but Z33761 does not!

Might also be related to T423853 -- but notice that this one here seems to only appear in the test!

That seemed to have been a caching issue. I changed the implementation (added a description) to bust the cache, and that made them work.

So I wrote a SPARQL query to get all Bangla nouns that indeed have all the five forms. Turns out, it's only three of them: https://w.wiki/LJsC

Interestingly Z33244 works in this case:

OK, fixed that too. The JS float converter needed some more fixing as well:

• https://www.wikifunctions.org/wiki/Z28867?uselang=en&diff=265896&oldid=265889

On https://www.wikifunctions.org/view/en/Z20849 the test https://www.wikifunctions.org/view/en/Z21466 still fails for Python.

Well, here's the change that made all the tests on https://www.wikifunctions.org/view/en/Z21939 pass again.

Huh, Weird. I wonder why the output changed then.

That fixed the failing JS test on https://www.wikifunctions.org/view/en/Z20849

Implemented the suggestions from https://www.wikifunctions.org/wiki/Talk:Z16684

There have been no changes to the converters in the last few months.

The example page that @Redmin meant was this here:

Yes, indeed. What is the suggestion? There is both a project and a specific wiki.

Thank you for this estimate and plan! Between that and Arthur's suggestions, I think it covers the work comprehensively.

This seems fixed.

I think that's correct, it should just be persistent throughout

Component does not support that kind of flow

This seems to work fine now. Thank you for reporting!

Actually, I am just closing it.

This seems to be fixed by now, and the issues reported are not reproducible anymore. Closing.

I think this seems resolved. Moving to triage to get it checked and closed.

I hope I am not messing up the debugging effort, but I created a code implementation ( Z28931 ) that works much faster than the previous implementation ( Z28604 ).

I think here's another example of that not working:

A few tasks which might interfere with the confidence in the system if we don't improve them: T405477, T405461, T404581

Discussed this with @DSmit-WMF , and it might be a good idea to have T404195 in mind when doing that, as there might be synergy.

Here's an example of a community member reporting this: https://cs.wiktionary.org/w/index.php?title=Wikislovn%C3%ADk%3APod_l%C3%ADpou&dtnewcommentssince=c-Mykhal-20251005143000-Mykhal-20251005142500&dtinthread=1#c-Mykhal-20251005144400-Sannita_(WMF)-20251005135500

Here are a few more pages that can be checked for this:

• https://www.wikifunctions.org/wiki/User:Denny/Year/es
• https://www.wikifunctions.org/wiki/User:Denny/Year/de
• https://hr.wiktionary.org/wiki/Haus
• https://hr.wiktionary.org/wiki/Jahr
• https://hr.wiktionary.org/wiki/Feder

Once we have more memory, we should test this out with two or three big items, and if it works fine, switch it on.

Happy to call it closed!

Note that this is about implementation https://www.wikifunctions.org/view/en/Z28032 which is currently not connected.

Once it is fixed on Wikidata, we can also fix it on Wikifunctions, I hope (T405475)

I think that this seems to just take much longer than I thought, but eventually it does show up.

Same thing happens in the following flow:

• Edit with visual editor
• Insert or change a function call with values
• Look at the Preview, shows OK
• Click on "Apply changes" and the change never is displayed in the text

I would like to keep this, but will reduce priority to low and to "No current plans".

Raised priority as it is blocking the fragments work.

I think they fail because Z6821/Fetch Wikidata Item for both Virgil and Dante does not currently return any Date of Birth statement