Internationalization framework

[aghassemi]

This is just a placeholder/discussion issue for internationalization work we need to do.

As we create more complex components, there is more default text that we need to include (e.g. labels and titles, whether visible or for screen readers). Allowing page authors to change these defaults (whether to translate them or simply to change them) is currently done through custom attributes on the elements but this approach is not very scalable and muddies the component's API.

We should come up with an i18n and text customization approach that

1. Allows us to ship translations for default text we have in components.
2. Allows page authors to override/translate any default text.
3. Support interpolation. (e.g. "page {{x}} of {{y}}")

We should research what a good existing approach for this is. A starting thought could be: a JSON based system which is just a map of <UniqueTextKey, Value> (e.g. "{amp.LightBox.nextButtonTitle": "See next Item"}). Components use the key instead of hardcoding the text and runtime does the repalcement and interpolation. We provide a translated map for English and a few other languages and page authors can override any key with their value of choice by providing a partial override map.

@cramforce @dvoytenko @rudygalfi @ericlindley-g

[ericlindley-g]

Excited about this one—will mean less trepidation around features that could use i18n :)

@aghassemi, I'm slotting in "pending triage" for now. please update the milestone when you have a sense of when work will start. Thanks!

[adelinamart]

Do we still need to work on this one?

[cramforce]

yeah

[aghassemi]

To @dvoytenko for framework. I believe @dvoytenko has a design for this as well.

[mpatnode]

It seems you're talking about forcing several languages into the same AMP document, rather than using a hreflang like mechanism to point or redirect to the correct version. Am I reading your intent correctly?

[aghassemi]

@mpatnode-si yes, but not necessarily forcing, rather providing an alternative to allow runtime support for different languages in a single doc instead of requiring multiple versions of the same doc in multiple languages.

[mpatnode]

Hmm. That doesn't work well for our model since we often work with partners to manage our international sites and we don't give them edit rights to the original article. Also, when an article is copied to another locale, they will often change the images associated with the article, or remove some images which we may not have rights to publish in that geography.

This feature does make sense in general, and would work fine for something like technical documentation that needed to be translated into multiple languages, but may not make sense for real-world publishing organizations. See: #8084

[mcmd]

I agree that this may not make much sense for most publishing organizations, but what about e-commerce ones? In that vertical it is much more common to serve content under the same URL in different languages based on the request coming from the user. Or is it considered that the better approach is to have different URLs for different locales, and then do the hreflang-based AMP internationalization?

[cramforce]

For now certainly the hreflang approach is the only supported method for doing locale based customization.

[dreamofabear]

Flagging that this may be needed at some future date for amp-story. Not blocking for now.

/cc @newmuis @flaviori

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.