Langauge.root_url returns wrong value

Markets
1 
{% for country in localization.available_countries %}
  {% for language in country.available_languages %}
    {{ language.root_url }}
  {% endfor %}
{% endfor %}

`language.root_url` always returns the root_url from the active locale. I would have expected to return the root_url of that country language.

We have lots of inconsistencies with the county and language object.

We’d like to create a localization dialog, but we can’t now since the returned values are incorrect

2

Hi @stijn_code, thanks for reaching out to report this.

Let me investigate what’s going on here and get back to you.

3

Hi @Paige-Shopify,

Any update on this? It takes a lot of time for our devs on our custom client theme’s.

4

Hi @stijn_code,

Sorry for the delayed response, had a classic case where I forgot to hit the ‘Reply’ button :woman_facepalming:

I was able to confirm what you’re seeing is expected behavior for root_url. It is always relative to the current browsing context, not the country being iterated over.

If you’re building a country/language switcher, I highly recommend using {% form 'localization' %}.

5

Hi @Paige-Shopify,

No worries, haha.

We use the {% form 'localization' %}, but that is not the issue. What we try to achieve is updating the language selector when changing the country. Each country can contain different languages, so that needs to be updated when changing the country.

Here is basically what we try:

  1. User changes country.
  2. Sections rendering API is fetching the new modal contact.
  3. We update the language selector with the new language selector
  4. User sees new languages

The whole section rendering does work, but for some reason market related objects are not locale aware, but point to the main url.

6

The root_url behavior causes Section Rendering API requests to render with the previous country’s context after selecting a different country without submitting the localization form. You can work around this by making a POST request to the localization endpoint before calling the Section Rendering API:

  1. When the country changes, submit the localization form via fetch (POST). Let it follow the 302 redirect.
  2. Read response.url from the resolved redirect. This returns a localized path (e.g., /en-ca for Canada).
  3. Use that localized path for the Section Rendering API call (e.g., /en-ca?sections=localization-footer).
  4. Parse the response and update the language selector.

This assumes the shop uses subfolders for markets and may not work for other market configurations.

7

Any news on this? TBH, markets is to important to work with workaround.

Others are also experiencing other issues/challenges around marktes specific fetching Fetch section in context of primary market

8

Thanks for following up here. At the moment this is working as designed: language.root_url resolves relative to the current browsing context rather than the locale you’re iterating over. I’ve submitted a feature request to have this changed.

With feature requests, we’re not able to share whether or when they’ll be implemented, so I can’t give you a timeline. In the meantime, the redirect-based workaround I shared above is still a reliable way to get the localized path for your Section Rendering API calls.