You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Howard Landman has prompted a discussion of how/whether we could look at adding internationalization for at least some of the website. I'll quote his emails here for context:
9/29/2019: This seems to answer some of my questions.
We can get user-preferred languages from the HTTP Accept-Language header. This is more reliable than using their location (what if you prefer Chinese but live in the US?).
The gems globalize, route_translator, and friendly_id-globalize could do much of the work.
Each language should probably be saved in a separate Ruby file in each directory. So en.rb, cn.rb, etc. for each web page.
This approach can handle both static content (that is the same for all users and doesn't change unless edited) and dynamic content that is generated on the fly. It can also handle date formats, currency types, etc. automatically.
10/1/2019: The support for dynamic content wouldn't necessarily have to change much from year to year. Mostly it involves setting up translations for small words or phrases. These can probably be retained, since e.g. the word "account" is likely to be used every year.
The static content usually involves larger pieces of text, but we could use e.g. Google translate to get initial versions of those in other languages. We could get native speakers to tell us if those need adjustment. I guess the main drawback would be that if we changed the English source, we'd maybe have to re-translate and re-do the adjustments.
It would be possible, and maybe even desirable, to implement the Ruby on Rails methodology for globalization without actually supporting other languages. This means taking ALL text strings out of each web page and putting them in a separate English file. Once that is clean, the only thing needed to support a new language on a given page would be to add a text file for it and list it as supported.
This approach would also let us only support some pages and not others. For example, we could choose to only have the home page and the altitude safety warnings be multilingual, with everything else English-only. It's not all or nothing. This could be tried in the sandbox.
The Japan Go Congress website serves up English to me, so other people have managed to get this done. But their hostel's page is in mixed Japanese and (broken) English; I don't think we want to end up looking like that.
The text was updated successfully, but these errors were encountered:
Howard Landman has prompted a discussion of how/whether we could look at adding internationalization for at least some of the website. I'll quote his emails here for context:
The text was updated successfully, but these errors were encountered: