Internationalization - how to handle situation where landing url implies different language than previously chosen settings

Question

Well say I have a website example.com - it allows people (writers) to post their own content which they can link to later for readers: example.com/my-blog-title would be such a link.

Now in the process of internationalization the interface is adapted to the users (readers + writers) preferred language. This setting can be chosen done -when a reader is logged in- at their profile page (thus not having the limit to one device upon loggin in at another device the settings is correct).

Further if a language is chosen the url is changed to reflect that. This is done for SEO purposes: example.com/en-us.

Thus if a writer has his language set to french the url to his content would be example.com/fr-fr/my-blog-title. And if he changes his interface to english the content would still be there, also under example.com/en-us/my-blog-title. (I now realize blog seems to imply text, but it's important to remember that the content is always visible in any language - it's the interface that changes).

However this creates a weird situation, where (say) a reader has set his language to English. yet a reader is directly linking his post example.com/fr-fr/my-blog-title, what should then happen?

1. Redirect url to example.com/en-en/my-blog-title - but this might be confusing to readers that the urls don't match?
2. Ignore the language from the URL and use user's prefered language instead - but then the same url links to different languages, and what happens on links inside that page?
3. Ignore the user's prefered language and use the exact url. - But then the website might confuse readers as they can no longer find their familiar buttons when they don't understand the language.

What is the generally accepted solution for this?

Answer 1

You are trying to combine both the language of the interface and the path to an author's page in the URL. They are two separate things, and simply create confusion when combined.

If the entire site were translated, then yes the language in URL makes sense.
You're better of simply placing the preferred language in a cookie, and making it invisible to the user. This is exactly the kind of thing cookies are great for.

You could also do what medium.com does. Articles that are not related to blog posts have the language in the URL, such as this...

https://help.medium.com/hc/en-us/articles/360035241933-About-language-availability-on-Medium

Whereas articles by bloggers have the bloggers name as part of the domain name, like this...

https://sarahcottrell.medium.com/what-science-says-about-parents-who-swear-around-their-kids-5697c37cf77a

Alternately, you could just have the blogger's name be part of the URL and not the host name. But then make sure you don't let anyone have the user name that matches a language to avoid ambiguity.

That said, blogger name as part of (virtual) host name makes a lot of sense.

Answer 2

I like how google translate does it in Chrome. It alerts the user in a minimal disturbing way that the page she is viewing does not match with her language setting. The user can then choose to translate that page or read the original.

You could build something similar. Ask the user if she wants to be redirected to the English version (i.e. their preferred language) or if she wants to stay and read the article in the french version (i.e. the original version).

Answer 3

I think the solution is to separate the create / editing url from the reading url, actually there's no reason to keep them together.

Almost all online catalog's sites act in this way, when entering the page to insert the catalog and set the options, the user can choose the language. But for viewing/reading the catalog online, it shows the original url plus the user name and the catalog name.

In your case it would be:

• Editing page: example.com/fr (or example.com/uk, or example.com/es, etc)

• Reading page: example.com/username/my-blog-title

Example: publitas.com