Hi im trying to make a simple widget where it would say “Delivery to (Country_flag) in 2 days” where Country_Flag would be dynamic field detecting visitors geo location and would return the country flag.
Currently i made a delivery-time-js.liquid snippet with code:
Using this updated code the flag icon is now working, but isn’t it true, that localization.country takes the store’s country and returns the flag for that? Not customer’s actual IP adress country?
If I to implement this, I’d output messages for each country with liquid with style="display:none", then use API from #2 to remove style attribute from one of these based on result.
Something like:
{% for c in localization.available_countries %}
<span data-country="{{ c.iso_code }}" style="display: none">
Delivery to {{c.iso_code }} is XXX days
</span>
{% endfor %}
<script>
fetch('/browsing_context_suggestions.json')
.then(r => r.json())
.then(r => r?.detected_values?.country?.handle)
.then(country => {
if (!country) return;
document.querySelector('[data-country="' + country + '"]')?.removeAttribute('style');
});
</script>
However looks like it’s about keeping TLD, not subfolders like /en-us/ or /fr-fr/?
Sure depends on your setup.
Then it depends no more testing results.
I’d say that Browsing context suggestions will give your “non-politicized” lower level info while localization should give your visitor a chance to manually select the delivery country.
IP geolocation is inherently imprecise. VPN users, corporate networks, mobile carriers that route through centralised servers, and shared ISP infrastructure all produce false location signals. VPNs are increasingly mainstream, not just a technical tool. A significant portion of ordinary consumers use them routinely, and their apparent location bears no relation to where they actually are.
Mobile networks compound this. Carrier-level NAT and traffic routing means mobile users often appear to be wherever their carrier’s gateway is, or where the traffic has been load-balanced to - which can be in a different country - especially in Europe. I’m in the UK and have been load-balanced to the Netherlands before.
The browser Geolocation API has always required explicit user permission, but what has changed is how aggressively browsers default to blocking or obscuring it. Firefox has offered resistance fingerprinting modes for years, and its stricter privacy settings return deliberately imprecise coordinates even when permission is granted. Safari on iOS uses a similar approach, rounding coordinates to reduce precision. Brave blocks geolocation by default and requires manual override per site.
Chrome is the outlier in being relatively permissive, but even Chrome has moved toward blocking geolocation on pages loaded over HTTP and prompting more assertively when a site requests it.
