Moving an internal comment here, which might lack some context, but for discussion, makes sense to chat here.
I think we should start with the "shell" i18n concerns, and not seek to do any automatic content translation— Mostly because I think that's a task pretty decently handled by the browser. If we wanted an optional "translate all content" or even just "translate this content" button that would be more an end-user thing than a site structure thing.
So if we started with "shell" i18n, added the browser preference header as a variant in all cache keys, I think that's the place to go. This at least gives us the option to let forem creators start thinking in terms of a default language other than english.
In terms of the language subfolders and SEO.... We could make dev.to/es/... aways use the spanish shell, and only display spanish articles. Root dev.to/ can show any language, but the shell defaults to the forem admin's settings (english in our case).
Any individual article would be accessible at its usual path dev.to/ben/... but if it's a spanish post, the canonical url could be dev.to/es/ben/.... which would then also use the spanish shell, for the robots to use.
I don't think we need this entirely figured out right now, but if we're going to use language subdirectories we need to reserve those directory words right now so that forems don't start filling up with usernames and orgs with those names. I think the first step should be getting the i18n shell MVP worked out. I think most of the Rails i18n functionality should be usable to us, as long as we make it compatible with how we're reading headers for caching and stuff.
added the browser preference header as a variant in all cache keys
@ben
that will be a stretch at the moment. We can do that with Fastly, Nginx won't have the same functionality set up to do that approach yet (using keys, vary headers to lookup tags/keys in cache, etc.). Nginx only has the power to handle paths. Are you suggesting we wait until we get there with Nginx? That would be a future cycle to get Nginx to that level.
If not, it's easier with regards to caching, to not mess with vary and cache keys. By using just the subfolder approach, /es/, Nginx/Lua can re-write a request at the edge based on settings (cookie or headers). This approach also avoids having to do a separate implementation for Fastly.
I'll have to look more into service workers and our setup. Won't doing something like this change that whole approach since the shell content would be dynamic with i18n? The content could change anytime based on settings and not just on deploys. Don't we bust that service worker cache on deploys by Heroku slug?
Let's keep in mind that locales are comprised of two parts: country code and language code. A Spanish article written by a person from Colombia is not going to be exactly the same as if that person were from Spain could write and viceversa. French in Canada is not exactly the same French for France or Senegal. So we might want to take countries into account as well.
Not sure if we should differentiate those or not, maybe not from the start, but we should take into account that the full locale is de-AT, de-CH, de-DE, not just de and some products simply read what the browser locale and "route" the user to the strings translated in the specific locale.
A possibility would be to have it-it from the start in the URL and serve the same Italian to both it-IT and it-CH so that when we'll have a reason to translate to it-CH that won't change.
I guess this decision has to be made for the caching keys as well ahead of time
I think if country and sub-region is something we want to support, it's common to do something like /us/en (Ikea is one example). We definitely should make a call on this upfront.
It seems a lot of the "large" companies go as far as changing the domain itself (i.e. adidas.de, airbnb.de, airbnb.com.co). That approach has advantages, including SEO and code implementation. That will be much tougher for Forem since we're talking about infinite communities and domains to manage.
For further actions, you may consider blocking this person and/or reporting abuse
Moving an internal comment here, which might lack some context, but for discussion, makes sense to chat here.
I think we should start with the "shell" i18n concerns, and not seek to do any automatic content translation— Mostly because I think that's a task pretty decently handled by the browser. If we wanted an optional "translate all content" or even just "translate this content" button that would be more an end-user thing than a site structure thing.
So if we started with "shell" i18n, added the browser preference header as a variant in all cache keys, I think that's the place to go. This at least gives us the option to let forem creators start thinking in terms of a default language other than english.
In terms of the language subfolders and SEO.... We could make
dev.to/es/... aways use the spanish shell, and only display spanish articles. Root dev.to/ can show any language, but the shell defaults to the forem admin's settings (english in our case).Any individual article would be accessible at its usual path
dev.to/ben/...but if it's a spanish post, the canonical url could bedev.to/es/ben/....which would then also use the spanish shell, for the robots to use.I don't think we need this entirely figured out right now, but if we're going to use language subdirectories we need to reserve those directory words right now so that forems don't start filling up with usernames and orgs with those names. I think the first step should be getting the i18n shell MVP worked out. I think most of the Rails i18n functionality should be usable to us, as long as we make it compatible with how we're reading headers for caching and stuff.
@ben that will be a stretch at the moment. We can do that with Fastly, Nginx won't have the same functionality set up to do that approach yet (using keys, vary headers to lookup tags/keys in cache, etc.). Nginx only has the power to handle paths. Are you suggesting we wait until we get there with Nginx? That would be a future cycle to get Nginx to that level.
If not, it's easier with regards to caching, to not mess with vary and cache keys. By using just the subfolder approach, /es/, Nginx/Lua can re-write a request at the edge based on settings (cookie or headers). This approach also avoids having to do a separate implementation for Fastly.
I'll have to look more into service workers and our setup. Won't doing something like this change that whole approach since the shell content would be dynamic with i18n? The content could change anytime based on settings and not just on deploys. Don't we bust that service worker cache on deploys by Heroku slug?
On additional aspect, related to subdirs.
Let's keep in mind that locales are comprised of two parts: country code and language code. A Spanish article written by a person from Colombia is not going to be exactly the same as if that person were from Spain could write and viceversa. French in Canada is not exactly the same French for France or Senegal. So we might want to take countries into account as well.
Not sure if we should differentiate those or not, maybe not from the start, but we should take into account that the full locale is
de-AT,de-CH,de-DE, not justdeand some products simply read what the browser locale and "route" the user to the strings translated in the specific locale.A possibility would be to have
it-itfrom the start in the URL and serve the same Italian to bothit-ITandit-CHso that when we'll have a reason to translate toit-CHthat won't change.I guess this decision has to be made for the caching keys as well ahead of time
I think if country and sub-region is something we want to support, it's common to do something like
/us/en(Ikea is one example). We definitely should make a call on this upfront.It seems a lot of the "large" companies go as far as changing the domain itself (i.e.
adidas.de,airbnb.de,airbnb.com.co). That approach has advantages, including SEO and code implementation. That will be much tougher for Forem since we're talking about infinite communities and domains to manage.