Oh, I see. MF uses the en dash as delimiter for the language name. But the en dash is a perfectly valid character in page titles. In fact, there are roughly 73k articles on the English Wikipedia with " – " in their title. Lots of them are redirects, and while I don't know how many exactly (T204089), based on the first 5000 results it looks like roughly half of them are NOT redirects. All these pages are affected by this bug, and again, that's for enwiki alone.

The language links have a title with the format <page title> - <page language>

MobileFrontend splits to get the two. It hasn't factored in the edge case where the title also contains that character.
It should be updated to account for multiple delimiters. Patch very much welcome.

https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/0652ba81c60c25d7714b7e965c251cd415caedda/src/mobile.startup/PageHTMLParser.js#L243

@Daimona the title is generated here: https://github.com/wikimedia/mediawiki/blob/0258088e16489bd7c5cbdac8f25d64c346664244/includes/skins/Skin.php#L1301
Adding data-title as a key there should make it accessible to Minerva without the title. e.g. provide it without the message interlanguage-link-title
\

Change 968652 had a related patch set uploaded (by Jon Harald Søby; author: Jon Harald Søby):

[mediawiki/extensions/MobileFrontend@master] Fix en dash display in interlanguage link list

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

Change 968652 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Fix en dash display in interlanguage link list

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

Just to reiterate that the concerns I raised on gerrit were not purely hypothetical, https://es.m.wikipedia.beta.wmflabs.org/w/index.php?title=Misi%C3%B3n_imposible%3A_sentencia_mortal_-_Parte_1#/languages still shows a truncated title, suggesting that the patch above does not fix the issue.

@Daimona the title does not look truncated to me. What am I missing?

In T349000#9288680, @Jdlrobson wrote:

@Daimona the title does not look truncated to me. What am I missing?

It seems to depend on the interface language. I was reading the page in Spanish (default):

If I switch to English, then I get the dash as in your screenshot.

Interesting. In Spanish the language appears like so:

"Mission: Impossible – Dead Reckoning Part One (inglés)"

I guess there is some localization happening here so we will need to extract the language differently based on language using the message (interlanguage-link-title)

In T349000#9288717, @Jdlrobson wrote:

Interesting. In Spanish the language appears like so:

"Mission: Impossible – Dead Reckoning Part One (inglés)"

I guess there is some localization happening here so we will need to extract the language differently based on language using the message (interlanguage-link-title)

Indeed, there are quite a few languages that have customized that message so it doesn't contain the hard-coded delimiter: https://translatewiki.net/wiki/Special:Translations?message=Interlanguage-link-title&namespace=8 . The way I see it, there are two ways forward:

1. Extract the necessary components from the message using the message and some regex.
2. Like you suggested in T349000#9254760, add a data-title attribute to the a element so we can use that.

I already have a prototype for the first one working, but it feels a bit messy, so I feel like the second one is cleaner and more robust. What do you think?

Yeh I think #2 seems like the right solution here.

Actually, I thought of a 3rd way to do it: Use the href attribute and use mw.util.percentDecodeFragment() to get the title from that. I can upload a patch for that, but the one I have doesn't get the langname (i.e. translated language name) for the return object in getLanguages, which might be a problem.

In T349000#9299931, @jhsoby wrote:

Actually, I thought of a 3rd way to do it: Use the href attribute and use mw.util.percentDecodeFragment() to get the title from that. I can upload a patch for that, but the one I have doesn't get the langname (i.e. translated language name) for the return object in getLanguages, which might be a problem.

I think this would be fine. I was wonderiong how this works with display title e.g https://en.m.wikipedia.org/wiki/IOS#/languages but it seems like the existing interface does not consider that (possibly another bug?) If we want to fix that bug perhaps the 2nd way is the better approach.

Change 973890 had a related patch set uploaded (by Jon Harald Søby; author: Jon Harald Søby):

[mediawiki/extensions/MobileFrontend@master] Make getLanguages() more robust

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

What are the downsides of using a data-title attribute ?

In T349000#9328711, @Jdlrobson wrote:

What are the downsides of using a data-title attribute ?

That would certainly be easier, but we'd also need a data-langname attribute for the localized language names.

That does sound like it would be useful to have?

Indeed. Where would those need to be added? Core?

Yes inside core when rendering the language link: https://gerrit.wikimedia.org/g/mediawiki/core/+/4610171913c4b1947f4da7ff7e402e3e576a31e7/includes/skins/Skin.php#1318

Change #973890 abandoned by Jdlrobson:

[mediawiki/extensions/MobileFrontend@master] Make getLanguages() more robust

Reason:

Sorry for dropping the ball on this. I can't reproduce the issue any more but if it's still occurring I think it would be better to fix this in a more future-proof way via a core change if possible https://phabricator.wikimedia.org/T349000#9338056

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

Thanks for the URL update! @jhsoby are you still interesting in helping get this fixed?