In most cases, if you just update your links to be to use Special:MyLanguage ala https://www.mediawiki.org/wiki/Special:MyLanguage/PageName, that should improve the situation...

I suspect the manual section hardcoding (which obviously breaks if the section is renamed in a language) like in https://github.com/wikimedia/wikipedia-ios/blob/cf64c862f70a4dd719223f2f35ba8cd55ab2e5e8/Wikipedia/Code/AltTextGuidancePresenter.swift#L62-L76 is similarly unnecessary, and using Special:MyLanguage with the English section name should work fine...

In T377887#10254625, @Reedy wrote:

I suspect the manual section hardcoding (which obviously breaks if the section is renamed in a language) like in https://github.com/wikimedia/wikipedia-ios/blob/cf64c862f70a4dd719223f2f35ba8cd55ab2e5e8/Wikipedia/Code/AltTextGuidancePresenter.swift#L62-L76 is similarly unnecessary, and using Special:MyLanguage with the English section name should work fine...

Checked with translatewiki.net

Indeed, all of the following can just be replaced

var url: URL?
switch wmfProject {
case .wikipedia(let language):
    switch language.languageCode {
    case "en", "test":
        url = URL(string: "https://www.mediawiki.org/wiki/Wikimedia_Apps/iOS_Suggested_edits/en#Alt_Text_Examples")!
    case "pt":
        url = URL(string: "https://www.mediawiki.org/wiki/Wikimedia_Apps/iOS_Suggested_edits/pt-br#Exemplos_de_texto_alternativo")
    case "es":
        url = URL(string: "https://www.mediawiki.org/wiki/Wikimedia_Apps/iOS_Suggested_edits/es#Ejemplos_de_texto_alternativo")
    case "zh":
        url = URL(string: "https://www.mediawiki.org/wiki/Wikimedia_Apps/iOS_Suggested_edits/zh#%E6%9B%BF%E4%BB%A3%E6%96%87%E6%9C%AC%E7%AF%84%E4%BE%8B")
    case "fr":
        url = URL(string: "https://www.mediawiki.org/wiki/Wikimedia_Apps/iOS_Suggested_edits/fr#Exemples_de_texte_alternatif")
    default:
        return
    }
default:
    return
}

guard let url else {
    return
}

with something variant of

var url = URL(string: "https://www.mediawiki.org/wiki/Special:MyLanguage/Wikimedia_Apps/iOS_Suggested_edits#Alt_Text_Examples")

And fwiw, for almost all links to wikis with translate (ie mediawiki.org) you can just put Special:MyLanguage into them. If there's no translation, you'll get the English... and if translation is added later, you magically benefit from the redirect without any further work on updating or maintaining lists like you are currently

@Reedy Thanks for the advice! I'm glad we have a special page that easily handles these situations.

The goal is to have the language of the MediaWiki page match the interface language of the App when possible.

This is a small if all goes well, but there's a chance we can't get this to work. I'm setting small as a way to timebox it to one day of trying things.

And fwiw, for almost all links to wikis with translate (ie mediawiki.org) you can just put Special:MyLanguage into them. If there's no translation, you'll get the English... and if translation is added later, you magically benefit from the redirect without any further work on updating or maintaining lists like you are currently

Hi @Reedy

Would a link like https://www.mediawiki.org/wiki/Special:MyLanguage/Wikimedia_Apps/iOS_Suggested_edits#Alt_Text_Examples only auto-redirect to the correct language & section for logged-in users? I was hoping to get this ability for logged out users too (like maybe if Special:MyLanguage could reference the browser interface language for logged out users), but it doesn't look like that's working in my testing.

Hmmm, sorry about that. I presumed it also worked for anon users too. That's annoying.

T110489: Multilingual wikis should show content in the language of the user's browser when available and T58464: Allow anonymous users to change interface language on Wikimedia wikis with ULS. Specifically like T216811: Special:MyLanguage should use browser defined language for anon users on multilingual wikis which was merged into the former (this really shouldn't require a user preference to be able to work).

Not the same, but also T5665: Auto-detect interface language for anonymous users on Wikimedia projects

Probably somewhat of a simplification, but... I understand there's a caching element to take into account, but that's what the vary headers are for, and could vary on language...

From T269492#8110881 too:

Similarly, the problem with using Accept-Language is that it's a noisy header, which makes using it for Vary: not really cache-friendly. E.g. my browser automatically adds Accept-Language: en-US,en;q=0.9,hu;q=0.8 to all AJAX requests. Someone who has configured their browser to accept English but not Hungarian would get Accept-Language: en-US,en;q=0.9 instead - a cache split, even though both responses are served in English.

(Maybe that's not that much of a problem in practice because few people customize their browsers' language settings? We can probably pull some stats on this from the analytics webrequest data. Also, I suppose Varnish could normalize the header, although that would still leave vanilla MediaWiki installations with not-so-useful API mechanics.)

I guess this suddenly becomes a lot more complex :/

Do we have reasonable numbers of anons clicking through on these links?

Obviously translations are dynamic, and more can/will appear... It's not overly maintainable to keep having to keep adding them.

To some extent, T331758: Special:MyLanguage/Page/fr should fallback to Page/fr rather than Page for logged-out users could be a simpler middleground solution here... If you're building a semi-dynamic URL, attempt to put the /langcode prefix onto the URL (based on the apps language), only if Special:MyLanguage didn't just override that and decide you want the canonical (usually English) version.

Notes on this task: the use of Special:MyLanguage only works for logged-in mediawiki users. Passing the interface language/locale/main app language leads to errors when the translated page doesn't exist.
It doesn't consider the browser language or system language.
Dynamically redirecting tho en when we build the URL with a language argument would be a significantly larger lift, as we would have to identify the redirect to a non-existent page and redirect to the 'en' page.

I added the Special:MyLanguage to the URLs, but that won't cover all use cases.

@Mazevedo I asked around and had this format suggested to me:

https://www.mediawiki.org/wiki/Special:MyLanguage/Wikimedia_Apps/iOS_Suggested_edits?uselang=es#Image_captions

From my (extremely brief) testing, it shows ES, even when logged out. If the translation doesn't exist yet, it shows English:

https://www.mediawiki.org/wiki/Special:MyLanguage/Wikimedia_Apps/iOS_Suggested_edits?uselang=de#Image_captions

@Tsevener cool! I haven't tried it with that format; I'll do some more testing

mazevedofs opened https://github.com/wikimedia/wikipedia-ios/pull/5106

Note: I'm not sure how well it'll work with Chinese variants. I might needsome help to test that