Do you have a testcase for this? Looking at the code, it doesn't seem like displaytitle variants would work (but it's in Parser so I could easily have misread it).

An example of what you want would be helpful. Is it as simple as, for example, on a page titled "Foo bar" returning

"titlevariants": {
    "en": "Foo bar",
    "en-x-piglatin": "Oofay arbay"
}

? And then if clients want to turn that into a URL, they would generate those using the existing variantarticlepath property returned from action=query&meta=siteinfo (or by appending ?variant=$variant to an existing URL)?

perhaps by exposing the results of language->autoConvertToAllVariants for a given title string as a new titlevariants or some such page property in action=query&prop=pageprop?

That would be the wrong module, action=query&prop=pageprop exists to report what's in the page_props database table and only what's in that table. action=query&prop=info would be appropriate.

Also, which would be the correct conversion for "Talk:Foo bar": "Talk:Oofay arbay", "Alktay:Oofay arbay", or just "Oofay arbay" and let the client add the namespace prefix if needed?

In T178446#3693753, @Anomie wrote:

An example of what you want would be helpful. Is it as simple as, for example, on a page titled "Foo bar" returning

"titlevariants": {
    "en": "Foo bar",
    "en-x-piglatin": "Oofay arbay"
}

?

Yes, this is exactly what I had in mind.

And then if clients want to turn that into a URL, they would generate those using the existing variantarticlepath property returned from action=query&meta=siteinfo (or by appending ?variant=$variant to an existing URL)?

The use case we have in mind here is that the client already has the canonical page title and can use that to construct the variant URL, but just needs one or more display titles for the available language variants to display in native UI. In my patch for the parent task, for content URLs, I'm just returning w/index.php?title=$canonicaltitle&variant=$variant unconditionally since URLs of that form appear to work in all cases. @Jdlrobson suggested that w/index.php URLs aren't canonical, though, and I can imagine that a client using the variant article path where available would more likely result in a cache hit, so it sounds like checking variantarticlepath is the way to go.

(Would converted titles even work for constructing URLs? From casual testing (e.g., requesting https://zh.wikipedia.org/zh-tw/巴拉克·歐巴馬) it looks like there's some logic somewhere to redirect to the canonical title (https://zh.wikipedia.org/zh-tw/贝拉克·奥巴马), but I don't know if this works in all cases.)

perhaps by exposing the results of language->autoConvertToAllVariants for a given title string as a new titlevariants or some such page property in action=query&prop=pageprop?

That would be the wrong module, action=query&prop=pageprop exists to report what's in the page_props database table and only what's in that table. action=query&prop=info would be appropriate.

I see, thanks for the pointer.

In T178446#3693883, @Anomie wrote:

Also, which would be the correct conversion for "Talk:Foo bar": "Talk:Oofay arbay", "Alktay:Oofay arbay", or just "Oofay arbay" and let the client add the namespace prefix if needed?

Hmm, good question. As a consumer I'd expect to receive "Alktay:Oofay arbay," assuming that Alktay is an existing Talk namespace alias. In the event it isn't, I'm inclined to go with including the existing, unconverted namespace name ("Talk:Oofay arbay") to avoid technical confusion, although since I'm envisioning these titles as being for display purposes only, a case could be made for just converting everything (which is probably less confusing to an end user who isn't aware of the concept of namespacing).

In T178446#3692604, @Tgr wrote:

Do you have a testcase for this? Looking at the code, it doesn't seem like displaytitle variants would work (but it's in Parser so I could easily have misread it).

autoConvertToAllVariants looks like a general-purpose string converter but I could be off base here. I'll write up some code to clarify things.

Change 385011 had a related patch set uploaded (by Mholloway; owner: Mholloway):
[mediawiki/core@master] POC: Add varianttitles parameter to API query prop=info

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

Here's a proof of concept (no unit tests yet). It looks like the easiest thing to do is just to convert namespaces along with the rest, which seems reasonable to me.

In T178446#3694098, @Mholloway wrote:

(Would converted titles even work for constructing URLs? From casual testing (e.g., requesting https://zh.wikipedia.org/zh-tw/巴拉克·歐巴馬) it looks like there's some logic somewhere to redirect to the canonical title (https://zh.wikipedia.org/zh-tw/贝拉克·奥巴马), but I don't know if this works in all cases.)

Good point, I have no idea.

The logic you're referring to is probably implemented in LanguageConverter::findVariantLink(): if the specified title doesn't exist then it tries all variants of the title in case they do. It seems inconsistent whether it includes the prefix in that or not.

Hi @Mholloway is this actually blocked or should it be moved to Doing? Thanks!

@LGoto It could go in the Code Review column. Just waiting on a +2 or request for further changes to https://gerrit.wikimedia.org/r/385011.

Change 385011 merged by jenkins-bot:
[mediawiki/core@master] Add varianttitles parameter to API query prop=info

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