Add i18n RFC

[blittle]

No description provided.

[cbothner]

Super cool stuff. I think this RFC has some overlap with #146 which relates to my comment over there.

Basically, I'm starting from these principles: an H2 store should feel like an integrated part of the one and only Shopify product, and once a merchant gets set up with a Hydrogen store they should as rarely as possible need to make (or pay for) code changes just because they changed a setting in their admin.

I think the ideal is that Hydrogen and Markets have (by default, but overridable) bidirectional connection where config changes in Settings > Markets are reflected in H2, and even customized i18n routing configurations in H2 are legible and linkable by other Markets-aware services.

[cbothner]

As one good (maybe default) option I would love to see this pulling from the merchant's configuration in Markets settings. I think the aim should be that expanding into a new market is not something that should require code changes. Of course, I understand the benefits of having this static in the bundle in order to avoid extraneous API calls. How might a change to markets web presences "expire this cache"? For oxygen at least we might have the option of automating a no-op commit and triggering a rebuild/redeploy.

[wizardlyhel]

I like the no-op commit strategy.

The intention for this static localization mapping is so that page requests aren't behind a heavy merchant configuration api. This file can be generated on build process.

Other thoughts on where we can make this data available:

• Make the shop available countries available as a preloaded Oxygen variable - This would need a webhook from shopify admin that a new localization is available and that Oxygen is able to capture that and do a no-op commit to trigger a new deploy.
• Store the shop's available countries inside worker's durable KV - This allows no-code change reflects deployed h2 app.

(Other hosting platforms would need make that available countries query somehow)

[cbothner]

Maybe not the first iteration but we should leave ourselves open to a future where a merchant is able to use multiple H2 stores or H2 in concert with liquid to target different markets. Ideally SFR, Hydrogen, and our Geolocation app should be consistent whenever they want to direct the visitor to a certain page in a certain country and language context, even if that means dispatching French (Canada) to an H2 site with /ca/fr/produits/:handle and English (Austria) to the liquid online store with a cookie set.

Concretely I think that means that we should draw a distinction between the configuration that a single H2 site uses to build its own localized routes, and the shop-wide mapping between (country, language) <-> URL pattern used to actually move visitors between one localization and another. Keeping those as separate concepts preserves our ability to (optionally) derive one from the other or both from a centralized configuration.

[wizardlyhel]

Strongly feels that the routing manifest RFC can play super nicely here.

Routing Manifest RFC: #146

[cbothner]

For consistency with liquid, if desired, we might consider copying the interface of the analog in the online store: PUT /localization with country_code and language_code parameters.

[wizardlyhel]

This won't be an out-of-box component that we would provide to developers to use because there are too many customization potentials that a merchant may require.

However, we can document it as a special requirement for merchants going down the path of gradual Hydrogen adoption (Some pages hosted by Online Store and some pages hosted by Oxygen) where it does make sense to make this form action a PUT with country_code and language_code parameters .. or .. introduce the /locale route as H2 magic route where we define exactly what it is expecting

[cbothner]

My team has been thinking that we need to add an easy-to-use component that implements the recommendation pattern we've tested and had success with in the Geolocation app...

[cbothner]

A centralized mapping is also essential for enabling an SEO component that can automatically include bidirectional hreflang links to localized alternate pages.

[frandiox]

I believe the Remix team is working on optional parameters. Should we mention that here as a possible alternative in the future? With that, we wouldn't need to make hard copies for the files.

[wizardlyhel]

Ooops - I thought I did mention it but I guess I accidentally removed it

Yes - the $lang files and this build process are temporary until Remix team have the multi-routes definition to one route path merged

[frandiox]

It might be faster to use es-module-lexer instead of ESBuild for this task.

[frandiox]

Copying my comment from here:

As mentioned during the burst, we could inject lang/country in the storefront object and perhaps even pass those variables automatically to storefront.query(...):

import {getLocaleStrategyXYZ} from '@shopify/hydrogen'
...
   requestHandler(request, {
        env,
        context,
        storefront: {
          publicStorefrontToken: '...',
          storeDomain: '...',
          storefrontApiVersion: '...',
          i18n: getLocaleStrategyXYZ(request),
          // localeStrategy: 'domain', // alternative
        },
      });

const QUERY = `#graphql
  query layoutMenus(
    $language: LanguageCode
  ) @inContext(language: $language) {
    shop {
      description
    }
}
`

async loader({context: {storefront}}) {
  await storefront.query({
    query: QUERY,
    // This could be passed automatically to the query:
    // variables: {
    //    language: storefront.language
    //}
  });
}

This basically provides storefront.language and storefront.country in the loader context, and (optionally) pass those variables automatically to storefront.query which should be picked by queries that accept $language or $country.

Would that be good DX or too magical?