Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate / Add internationalization features #164

Open
neagle opened this issue Oct 2, 2019 · 0 comments
Open

Investigate / Add internationalization features #164

neagle opened this issue Oct 2, 2019 · 0 comments

Comments

@neagle
Copy link
Collaborator

neagle commented Oct 2, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant