I think the description got messed up, as there is only 1 of the two options written and I'm not sure if it is actually what was meant to be written, or if it is a pro. Can you please review the description @bearND ?

@Jhernandez Thanks for spotting this. I've fixed the formatting.

@bearND @Dbrant for the localizable strings (and other information needed before rendering the article), could pagelib make initial network requests for configuration that the clients intercept and respond to? Could be one for localized strings and one for display preferences (table collapsing, margin width, reading theme). If we're intercepting the page requests to serve cached content anyway, this might be the easiest way to provide info.

Alternatively, could use some kind of templating {{variables}} in the HTML.

@JoeWalsh The apps already know the translated strings, which they pass in over the JS bridge. What I really want to accomplish here is to have these values already known on the server-side, so that we're getting the DOM rendered as much as possible on the server-side. The server already knows the main language from the wiki domain and any wanted language variants could be known on the server via the accept-language header.

According to the meeting we had last week it sounds like we would like to proceed with setting up I18N for the wikimedia-page-library.
Adding @siebrand to see what we have to do to get I18N and TWN sync set up for this JavaScript project.

In T205550#4650888, @bearND wrote:

Adding @siebrand to see what we have to do to get I18N and TWN sync set up for this JavaScript project.

Please see https://translatewiki.net/wiki/FAQ#How_do_I_start_a_new_project%3F

I think there is a benefit of doing I18N in the PCS layer instead of the wikimedia-page-library since then the page library wouldn't have to bundle the translatable strings. I'm going to change the task title and description accordingly. (OTOH we could also split up the wikimedia-page-library into a client bundle and a server bundle.)

My 2c, if the decision is still open:

Personally I'd prefer that we not introduce i18n as a concern of either PCS or the page library, and leave them both limited in scope to page (and page component) layout and transformation. Otherwise, we have two possible sources of string resources for both of the apps handled at two different levels of the architecture, which doesn't seem optimal from an architectural point of view.

There's also a product decision lurking here about whether the Android and iOS apps will use identical string resources in page components composed by the page library for the foreseeable future. The implicit answer here is yes. Are we sure about that? IMO the worst possible scenario would be to have PCS start taking on partial i18n responsibility, and then have to begin composing and storing separate responses for iOS and Android if they want to use different strings in the same components. (N.B. On the infrastructure side, we've been rapidly filling up our available Cassandra storage space, which is a significant concern for the Services Core Platform team at the moment.)

If we did want PCS to directly inject translated strings, maybe a good strategy to do that, rather than having PCS handle a portion of string i18n directly, would be to combine all of the string resources for both apps into a single, versioned, standalone module that could be shared among Android, iOS, and PCS. Then at least we'd have a single source of truth about string resources used in the apps.

Still, using an HTML templating scheme (as @JoeWalsh suggested above) seems to me like the approach that's most straightforward, easiest to implement, easiest for the apps to adopt, agnostic with respect to future client UI decisions, and therefore presumptively the best strategy for this.

I assumed we would not need to support different strings for Android vs. iOS inside the WebView content. It's probably best to ask the PMs. If this becomes a requirement then it would be best to have the clients pass those strings in since that would be bad for caching and storage to serve two different platform variants for each page, as you mentioned. It wouldn't be ideal from a performance aspect to have this done by clients, though, because that would add more client side DOM changes.

In the short-term we could pass the strings in as part of the initial call to the PCS JavaScript abstraction layer the app will make (setMulti()).

@Charlotte and @JMinor: Do you think we'll have different strings for same things in Android vs iOS?

Just talked with @JoeWalsh about this. For now we're planning on injecting the translated strings from the client. That should be easier to do than setting up I18N server-side and mapping accept-language header values to the right message catalog. Updating the description to reflect that.

https://github.com/wikimedia/wikimedia-page-library/pull/212

Mentioned in SAL (#wikimedia-operations) [2019-07-03T20:24:25Z] <bsitzmann@deploy1001> Started deploy [mobileapps/deploy@cf64319]: Update mobileapps to fdb0108 (T205550)

Mentioned in SAL (#wikimedia-operations) [2019-07-03T20:25:50Z] <bsitzmann@deploy1001> Finished deploy [mobileapps/deploy@cf64319]: Update mobileapps to fdb0108 (T205550) (duration: 01m 25s)

Mentioned in SAL (#wikimedia-operations) [2019-07-03T20:27:10Z] <bsitzmann@deploy1001> Started deploy [mobileapps/deploy@cf64319]: Update mobileapps to fdb0108 (T205550)

Mentioned in SAL (#wikimedia-operations) [2019-07-03T20:28:20Z] <bsitzmann@deploy1001> Finished deploy [mobileapps/deploy@cf64319]: Update mobileapps to fdb0108 (T205550) (duration: 01m 10s)

Mentioned in SAL (#wikimedia-operations) [2019-07-03T20:40:20Z] <bsitzmann@deploy1001> Started deploy [mobileapps/deploy@350e74b]: Update mobileapps to 94d0233 (T205550)

Mentioned in SAL (#wikimedia-operations) [2019-07-03T20:45:31Z] <bsitzmann@deploy1001> Finished deploy [mobileapps/deploy@350e74b]: Update mobileapps to 94d0233 (T205550) (duration: 05m 11s)