Page MenuHomePhabricator

code implementations can't compare monolingual strings with different language representations
Closed, ResolvedPublicBUG REPORT

Description

Steps to replicate the issue:

What happens?:
Code implementations cannot de-reference language structures. So they cannot find equality to the same language with a different representation. So the wrong monolingual string was picked.

What should have happened instead?:
We need them de-referenced before they make it to code, whether they come from a Z11, Z31, Z60, ... etc

Then the JS implementation should pass this test.

We will be able to widely use code implementations to speed up natural language operations!

Details

Related Changes in Gerrit:
Related Changes in GitLab:
TitleReferenceAuthorSource BranchDest Branch
Support a special case for fullyRealize when resolving arguments.repos/abstract-wiki/wikifunctions/function-orchestrator!724apineapine-multilingualmain
Customize query in GitLab

Event Timeline

This is a tough one. We explicitly avoid resolving Z11s unless they are the top-level arguments to a function. If we were to resolve them all the time, we'd end up with some really untenable performance issues. As we see here, this comes at the cost of correctness.

I am going to raise this matter with the rest of the engineering team this week; we need a better strategy for these situations.

Change #1303567 had a related patch set uploaded (by Jforrester; author: Jforrester):

[operations/deployment-charts@master] wikifunctions: Upgrade orchestrator from 2026-06-16-183209 to 2026-06-17-182805

https://gerrit.wikimedia.org/r/1303567

Change #1303567 merged by jenkins-bot:

[operations/deployment-charts@master] wikifunctions: Upgrade orchestrator from 2026-06-16-183209 to 2026-06-17-182805

https://gerrit.wikimedia.org/r/1303567

Z35835 now reports the right result (albeit cached as a failure).