search

dbarnett / mumindme_web

Web app serving mumind.me
https://mumind.me/
0 stars 0 forks source link

Basic i18n support #7

Closed dbarnett closed 6 months ago

dbarnett commented 6 months ago

Add support for viewing some of the main pages in more than one language (Spanish in addition to English).

dbarnett commented 6 months ago

I don't really want to use sub-paths or subdomains like the Next.js i18n docs and a lot of popular libraries seem to prefer. Instead I want the home page for every supported language to live at https://mumind.me/, and determine which supported language to render based on this precedence:

  1. Default: English (en-US) — Used only if no other preferred language can be detected that the site supports
  2. Browser settings / HTTP Accept-Language — The user's preferences from browser/OS settings should be respected if they've configured a different preferred language that the site supports
  3. Manual selection (hl param, cookies) — Regardless of other settings, the site should offer a language selector for users to manually pick a different language, remembering that choice in a sticky hl param in the URL (and maybe cookies/storage so it will stick across site visits)

And I would like all locale-dependent content to update instantly, done in-place as much as possible, when the language preference changes.

dbarnett commented 6 months ago

Current implementation has a lot of rough edges, but covers most of the basics. Remaining TODOs:

  1. Not much actual translated content besides the main page
  2. The language selector is extremely basic, just two buttons at the top right of the header
  3. I might've seen an issue at one point where client nav to ?hl=en used my default locale of es-MX instead of the better match en-US
  4. Could probably also be more intuitive for someone with other en or es locales preferred (en-GB/en-AU, es-CO/es-AR/es-ES...)
  5. All the translation strings are dumped in one messy app-messages.js file for now
  6. Mixed-language pages could be cleaner: instead of top-level lang="es-MX" with most of the actual content wrapped in lang="en-US" on pages like blog posts where the majority of content isn't translated, it would probably be better to signal up to the page root to just call itself consistently lang="en-US"
  7. Not sure yet how I want to organize translations for entire pages, where forking the whole page seems cleaner than chunking into a bunch of strings to translate
  8. Probably a lot of brittleness in my one-off impl, could hit issues detecting the right locale, matching strings for translation, or otherwise just blowing up

Lots of potential cleanup to do as I give it more time to soak, finding libraries to clean up bits where I've reinvented the wheel and/or maybe publishing some self-contained valuable bits in libraries of my own.