keep in mind i18n

[JohnRDOrazio]

A good thing to keep in mind from the start is i18n:
https://guides.rubyonrails.org/i18n.html

[JohnRDOrazio]

This will require deciding how we want the desired language to be detected:

• from a subdomain (such as en.marriagebooklet.bibleget.io)
• from a url parameter (such as ?locale=en)
• from a pretty url (such as marriagebooklet.bibleget.io/en)

Personally I prefer the third option, seems to me to be the cleanest. See https://guides.rubyonrails.org/i18n.html#setting-the-locale-from-url-params

[JohnRDOrazio]

I've started working on a PR (#11 ) to implement a simple translation of the initial "Hello world!" string

[kas-catholic]

I think I prefer the ?locale=en option, but it's not a strong opinion since I haven't had time to give it a lot of thought. If the user has an account, a user account preference (stored in the db) could control the language.

I think yet another option would be to use a cookie - which is nice in that you don't need to think about it in your URL params or paths.

Certainly a good thing to keep in mind. Fortunately, Rails I18n is pretty nice to work with.

[JohnRDOrazio]

Certainly cookies will come into play, to make the website play nicely with user preferences.
A couple reasons to use "/en" in the url path rather than in the request are:

1. it's prettier
2. generally makes for better SEO and for search engine analysis of the sitemap, such that English pages are crawled as English pages and Italian pages are crawled as Italian pages, each as their own page rather than the same page with a variable changing the language contents.
   Though I guess there might not be a whole lot of a sitemap for this website seeing that the "projects" will probably be all private pages (even if they start out as "public" pages because users don't have an account yet, we should still discourage search engines from crawling them).

[JohnRDOrazio]

A good flow is:

1. first time a user accesses the website, if they access the application root and there is no locale parameter: if there is no cookie present, the browser language (navigator.language) should be detected as the language preference: https://developer.mozilla.org/en-US/docs/Web/API/NavigatorLanguage/language
2. there can be a "language dropdown" so that the user can change the language for the website, and making a selection from the language dropdown will store a cookie to remember the user's preference
3. if the user navigates directly to a URL with the locale parameter in the path, the locale parameter in the path will determine the current locale; if instead the user navigates to the application root (so no locale parameter is present) and a cookie is present, the user will be redirected to a URL with the locale parameter determined by the cookie

[JohnRDOrazio]

That's how I handle it on my wordpress websites, and that's how we handle it on the Pilgrimage Office website.

See here: https://stackoverflow.com/a/57378358/394921
and here: https://github.com/svenfuchs/routing-filter

[JohnRDOrazio]

Also see here: https://guides.rubyonrails.org/i18n.html#setting-the-locale-from-url-params

You probably want URLs to look like this: http://www.example.com/en/books (which loads the English locale) and http://www.example.com/nl/books (which loads the Dutch locale). This is achievable with the "over-riding default_url_options" strategy from above: you just have to set up your routes with scope:

# config/routes.rb
scope "/:locale" do
  resources :books
end

Now, when you call the books_path method you should get "/en/books" (for the default locale). A URL like http://localhost:3001/nl/books should load the Dutch locale, then, and following calls to books_path should return "/nl/books" (because the locale changed).

[JohnRDOrazio]

Yet another way to handle this, if we are working with vhosts on third level domains, is have a separate third level domain for each language, such as:

• marriagebooklet.bibleget.io => English
• librettomatrimonio.bibleget.io => Italian
• libretedeboda.bibleget.io => Spanish
  Then they would almost act as separate websites, and there would be no need to have a language dropdown nor would we have to store any cookies.
  I do like the idea of having domain names that are "translated" just like the website is translated. It's like that extra touch of coming closer to people.