Also a somewhat similar goal would be to allow user pages to be made of abstract content.

Seems like this is now possible without a built-in function (not sure if this is intended behavior, but it works!).

• Does this operate at the whole-Function level, or is it a mode that the same Function can use and not use in some circumstances?

According to the proposal, this would be done by creating two new Z61s, so the latter.

• How does this apply to sub-Function calls (once re-entrancy is live)?

I guess you would be required to construct a ZObject to pass in (so if I wanted to use natural number addition as a sub-function, I would have to put {"Z1K1": "Z13518", "Z13518K1": {"Z1K1": "Z6", "Z6K1": "67"}} or something similar, if I had selected "python-raw" as my programming language)

• Does this only apply to inputs? To outputs? To only some inputs? Etc.

To both inputs and outputs.

• What test cases do we have beyond the Wikidata data model concern for non-simplified fractions

Basically any case where you want to operate on generic objects (or typed lists of them) without using a composition (and, even then it often breaks because of dependencies), take test Z17831, where you get "Could not serialize input Python object: 1" on the python implementation

The long name isn't allowed, you have to be exploiting a bug to have this seen.

@cmassaro one of the tasks I mentioned during the corner

@Sharvaniharan I'd like to stress again that this is very important for Wikifunctions and Wikidata access

Z22664 is a good complete example of using it to create text if that's what you are looking for.

This is an image from 99of9 on the Abstract Wikipedia Telegram of where it could go in the UI

In T383842#10505763, @DVrandecic wrote:

This can be done with a list, or an object -- no n-ary apply would be needed for that, I think

In T385250#10512371, @Feeglgeef wrote:

I bet it's a character escaping issue. That implementation has a lot of regex so it's likely that one of those is being incorrectly read.

I bet it's a character escaping issue. That implementation has a lot of regex so it's likely that one of those is being incorrectly read.

I think this would be fixed by switching to CPython

Also has speed implications, the current apply implementations are not efficient.

This is RustPython's fault (it's never not), inconsistency works fine in CPython.

In T383502#10451265, @mdaniels5757 wrote:

They appear to be separately handled in the backend code too, it just took longer to find...

Yes, but them being displayed is not the issue. The issue is that they are being referenced to at all. Sure, this bug could be fixed as a frontend bug, but the actual root error is then not, and the other issue I mentioned is not fixed. See T379873#10341096

This also happened in a composition definition with a reference to a configuration that I deleted, so I'm fairly certain this isn't just with test, implementations, and functions.

In T383502#10451183, @mdaniels5757 wrote:

1. You merged into the wrong bug.
2. The difference seems pretty important!
3. I doubt you know for sure that this is *the same* bug.

Why don't you stop touching things, and I'll try to clean this up.

In T383502#10451182, @mdaniels5757 wrote:

Stop.

In T383502#10451172, @mdaniels5757 wrote:

I think it's distinct: this bug is when you go to the implementation page after a testcase is deleted, the other is when you go to the testcase page after the implementation is deleted.

It's not distinct, it's the same bug

Duplicate :/

I've created a function that implements this, Z21583

In T382140#10450804, @GrounderUK wrote:

I have a problem with Z11.

I don’t think we want to specify a display function for this but can’t we generally treat this as a string? (Or it’s a string if its Z11K1 has a code that is in some list, but we won’t know this when filtering “usable” functions.)

Or should we specify a display function for Z11 that appends a language code that can be erased when it matches some other language code in context?

But if, in effect, we consider Z11 to be a string, then we might also consider Z12 to be a Z11, if it is implicitly wrapped in “select by language” logic.

I don't need the function anymore, and have posted a request for another admin on RFD. As for avoiding it, that sounds good to me.

Errors being hard to understand and annoying to work with in the UI has been a frustration for me and AFAICT others.

Just to clarify, for the functions that will be usable are Z20767, Z20756, and Z21121? Asking because I created them and feel a responsibility for maintaining them.

This is like complaining to the Wikipedia development team that the article on Earth contains incorrect information. Ffs this is not the place. I've pinged Denny on the Telegram to ask about a proper validator for rational numbers

I'm closing this as invalid because as far as I know this is not and will never be a Phabricator issue.

In T382981#10430800, @mdaniels5757 wrote:

I doubt this is needed currently. Do you have any objects in mind that would have benefitted from this?

(Also, I believe this would need on-wiki consensus.)

I've started a discussion on the project chat for a removal of the ban on the bot

Right, but Z101 is not bugged here. Z101 is only checking (and is only intended to check) if the object is egregiously invalid. If we want a validator for Z19677 that works properly, it must be above Z10000, so is not a phabricator issue.

In T382911#10429306, @J_GVaz wrote:

Thanks @Feeglgeef...
I wasn't able to find any task related to rational numbers, if there is a task for this, please would you mind to provide its info, otherwise we just wait for the triage

That's really really weird. Z6691 - Z6696 don't even exist.

I think the most useful of these is the language one. Perhaps we could have a function that doesn't fetch any information for languages not in a list?

This is because we don't have a validator for rational numbers yet. Z101 is the default validator and only checks if an object is in a valid format for Wikifunctions.

In T380229#10425888, @DMartin-WMF wrote:

The user guide (actually more like a tutorial) has been created here:
https://www.wikifunctions.org/wiki/Wikifunctions:Working_with_Wikidata_content

This is imho the correct output.

This is a dup :/

Could we instead have a typed list of a new type for sitelinks (with keys wiki and title)? This would also allow references to articles on other wikis in other ways as well. We may also want an enum type of Wikimedia wikis.

How did you write this 2 minutes before the error happened? Do you have the wrong time?

In T381972#10416899, @Jdforrester-WMF wrote:

I've made the edit to fix the Object. https://www.wikifunctions.org/view/en/Z10121 now works again.

In T376078#10413204, @AAlhazwani-WMF wrote:

following

Acceptance Criteria
Prototype 2-3 enhancements based on user feedback and design exploration into user education

this is the 1st suggested enhancement:

• display a help icon/button next to the bottom sheet title (or popup title on desktop)
• on tap (or click on desktop) open a dialog with FAQ-like information about this new feature (image/illustration TBD)

dialog full text proposal:

given the limited real-estate we also explored a full-screen dialog on mobile, thou this is blocked by T321893: Dialog: Evaluate fullscreen on mobile

---

design specs available at https://www.figma.com/design/NcbqS9U1Yyuc45BVGK7P8T/T376078-User-education?node-id=263-36953&t=m3iehh10XdgGOwBW-1

In T355951#10399965, @AAlhazwani-WMF wrote:

In T355951#10398845, @Jdforrester-WMF wrote:

Should it definitely be alphabetical? By label in current view? By language code? Or in descending likely priority based on user's location, like ULS?

i was updating the task description with the latest updates to the about widget because i thought this was fixed, but i later discovered that is fixed only under certain conditions.

for instance, if we check Z12812 with the UI language set to english everything appears to be correct:

• we have suggested languages
• we have other languages alphabetically sorted

but if we check the same object with the UI language set to lombard, this is what happens:

• we have suggested languages
• we have other languages that are alphabetically sorted except french

I've created a category for functions I have made that may be useful here: https://www.wikifunctions.org/wiki/Category:Dagbani_Wikipedia_functions
It currently has:

• age (Distance between two dates as number of years)
• date (Represents a Z20420 on dagwiki)
• intro for year (Returns an introduction for a year on dagwiki)
• dagbani possessive (Makes a dagbani word possess another)
• negate dagbani verb (Negates a dagbani word, reading becomes not reading)
• caesar cipher (does a Caesar cipher)

A few of these have Dagbani labels, a few don't.

Isn't this just T379100?

In T381207#10398260, @Jdforrester-WMF wrote:

I'd recommend against creating functions that need functionality before they're available.

In T381361#10374562, @Bugreporter2 wrote:

It's annoying when a minor error in a string throws a big red message that screams, "there's an error!!!"

In T378381#10364416, @Izno wrote:

Algebraic data type.

I've added a couple Z20289s in there as well to illustrate what I think the problem is.