@SirHubalot
For the domain issue… I don’t believe there’s a UI mechanism for splitting in terms of pretty language trees for each domain. Its just adding language variations and setting the domain via the page settings I believe. But that’s odd the top of my head.
@SirHubalot wrote:
Also, could anyone confirm (at this point in time) if Hubspot as the ability to automatically direct a user to the correct language site based on browser language? I’ve seen multiple posts regarding this from last year and wasn’t sure if this has come to fruition.
Thanks!
This is just custom JS. I can’t comment on if hubspot does it automatically or not. From a development and technical standpoint which I can speak to and has better relevancy… Typically people do this by target a user with geolocation typically via IP Address / Accept-Language headers. Both of which are horrendous to do for any number of technical and accessibility reasons they violate.
IP (geolocation) is horrendous for obvious reasons… I’m travelling in Japan and only speak English and even if you did get a broad specturm region that doesn’t actually mean it’s accurate even if the indiviual is native to the region - See the latter point on BCP-47 / IETF language tags and the full spectrum of these.
Accept-Language just passes in whatever the "translation"of the page is which… per the BCP-47 / IETF reference above - doesn’t necessarily represent a true localization by region / variant.
So… returning this back to the JavaScript solution you would like to do. You can do by simply have a well formed i18n structure of your site whether it be via subdirectories or whatever else (so path/en, path/fr, … etc). But, this is flawed because of the above and coming points.
Browser settings aren’t deterministic. It’s a very naive way to do things riddled with problems even more than the above methodologies. Clarifying… it’s common for English speaking individuals (gb, au, nz, and other variants) to have an en-us version of their browser.
There’s a new JavaScript property introduced for an ordered *preference* of languages but still not great. For the browser settings / user preference determinations it’s akin to targeting by IP / geolocation. You’re just doing complete guesswork and hoping it’s right.
Maybe a user has keyboards setup for Russian, English, etc and their preferences are “ru”, “en”, … and you grab the wrong one / it’s not a good match. So then people say well… Wait what if I get clever and do something like this:
let lang = window.navigator.languages ? window.navigator.languages[0] : null;
lang = lang || window.navigator.language || window.navigator.browserLanguage || window.navigator.userLanguage;
For a cascade. Surely that works? Yeah, no dice. You’re just conflating things and assuming more is better. Personally, all of these things are anti patterns in my opinion. If you’re regionalization is sufficiently structured and targeted your users should be landing on those pages via natural methodologies such as searching The only real use case for this that’s *deterministic* is a re-ordering of drop-down to organize user inferred preferences first so they can select which one they actually want easier and similar other crafty tweaks such as removing broad spectrum redundancies.
Just for fun:
HubSpots internationalization features are subpar because they limit it to a restricted subset of BCP-47 / IETF language tags. Namely, (lang-region) when the true possibilities are (lang-extlang-script-region-variant-extension-privateuse)
So you could have Arabic as spoken in Italy written in Cyrillic script but with Gregorian calendars with private registry X for soem super niche use case.The above isn’t a real code but you get the idea. Real internationalization (or really globalization) is significantly broader than what hubspot supplies although in your use case I guess that’s good enough if your clients fine with hand wavy implementations.
Although, most people implement it as two-tag maxima variants anyways - full specificity is a nightmare with significant maintainability problems - and people just really don’t have the time or cash to do this. Automatic translations to do this degree don’t do much for you either, because bots and metrics will just penalize you for not having authored true content.
Then, you get into issues like… Well how do I present something so broad in a good UI with inudating options on the user much less having people be able to quickly find it and other considerations. All your standard dropdowns are “pick language X”. Rather than “pick X as spoken with Y script in region Z”.
@dennisedson
But, regardless I fundamentaly disagree with a platfom imposed restriction which inherently limits people’s potential globalization options etc. So, if you guys could fix that that’d be great. Or… Open up your sitemap to be dynamically adjustable so I can fix it for everyone, myself, and have some degree of actual development control when people ask me for things I can’t actually deliver outside of a hand wavy “sure that’s possible”