Change to "From [Language Wikipedia]" as a phrase to translate, since gender endings aren't currently an option for iOS strings.

@JoeWalsh: Wanted to confirm if this was the suggested path forward you mentioned last week or if I'm misunderstanding: because of our unique multilingual challenges, create new localization keys per language for strings that use the From (Language) Wikipedia pattern. So, for the string in this ticket's screenshot, something like:

"in-the-news-sub-title-from-en-us-wikipedia" = "From English Wikipedia";
"in-the-news-sub-title-from-pl-wikipedia" = "From Polish Wikipedia";
...
"in-the-news-sub-title-from-uz-wikipedia" = "From Uzbek Wikipedia";
...

Then, when requesting the string key value in app, use the requested language code to know which key to pull from. Is that right or am I misunderstanding? It seems like there are many keys that use that From (Language) Wikipedia pattern that would require duplication/rework:

explore-nearby-placeholder-sub-heading-on-language-wikipedia
explore-nearby-sub-heading-your-location-from-language-wikipedia
explore-most-read-sub-heading-on-language-wikipedia
explore-random-article-sub-heading-from-language-wikipedia
in-the-news-sub-title-from-language-wikipedia
on-this-day-sub-title-for-date-from-language-wikipedia
talk-page-info-active-conversations
top-read-header-with-language

@JMinor A solution to this ticket is up here: https://github.com/wikimedia/wikipedia-ios/pull/3644. We had a chance to talk about this a bit more in engineering sync though, and none of us feel good about it.

To 100% safely and correctly solve the problem this ticket describes, we need to be sure translators have full per language control of the ordering and translation of any strings with this pattern ("From (language) Wikipedia", "On (language) Wikipedia", etc.) We can't safely concatenate two strings translated in isolation (some are patterned a bit differently than just "From (language) Wikipedia") without potentially running into this issue or other corner cases in some languages. So for full correctness, we need to add ~1600 new localized strings to be translated just to solve this issue. For context, that's about twice the number of strings the entire app currently uses. That feels like a huge lift for translators. And a heavy burden to carry in perpetuity in the app just to resolve this issue.

It's not clear to me how Translatewiki's Magic Words could obviate the translator burden - in my understanding it only moves the complexity. I looked into how Android solves this problem, but it doesn't appear that they even have this problem to begin with. So one alternate solution would be for us to do something similar: change or remove this string pattern to also not have this problem in the app. Any other solution requires us to have linguistic knowledge comparable to a native speaker/reader of every supported app language, which I think is untenable.

Unless you're aware of some special magic on the Translatewiki side that would save us from introducing ~1600 new localized strings to solve just this problem, or you strongly feel the current PR solution is worth it, what do you think about backlogging or declining this ticket for now?

Sigh... yeah, I can see what you are saying about intervening words, word order and other complications making the "naive" solution not much of a solution at all. I certainly agree this is not worth 1600 new strings being translated/maintained!

Let's talk in our sync today about where this string is used and what alternative(s) strings might work for those contexts.

If we can't find anything satisfactory, I'm okay to decline this, unless/until Apple and/or Translatewiki provide additional agreement coordination support.

@JMinor another option for this occurred to me - what if there was one string per-language Wikipedia in the language of that wiki? So for example, English Wikipedia would show "from English Wikipedia" no matter what the user's UX language preference. The localization language for this string would match the wiki language.