Make a language switcher for the site #428
Comments
|
This sounds awesome! |
DeeDeeG
added
help wanted
Hacktoberfest
|
This is finally in-progress! I am having trouble making hard-coded links behave themselves, they need to have a All that is left is fixing the hard-coded links, and then adding (not hard-coded) links to each locale in the footer! It won't be glamorous, but I think it will be nice. Hopefully it works as well as it seems like it will. (No promises, but I am definitely feeling optimistic about this.) See this branch for my work-in-progress: https://github.com/DeeDeeG/refugerestrooms/tree/language-switcher (and also here, where I'm currently a bit stuck: https://github.com/DeeDeeG/refugerestrooms/tree/language-switcher-stuck) |
|
I got this mostly working: https://github.com/DeeDeeG/refugerestrooms/tree/language-switcher-rebased I followed the examples here: https://api.rubyonrails.org/v5.2.2/classes/ActionView/Helpers/UrlHelper.html#method-i-link_to The homepage link is no-longer hard-coded, and it includes a The search bar is still sending me to the "Restrooms search results" page without including a cc @mi-wood @stardust66 would you be able to help with this? (Maybe this can be a "to do" item for the hackathon?) Adding the language links to the footer should be the easiest part, once the last hard-coded links are sorted out. |
|
|
One way to work around certain hard-coded links, is to maybe have a session or cookie storing the current preferred locale. We can save this between page loads. That way none of the hard-coded links will reset the locale to whichever the user's browser list of preferred locales has first. (Which defeats the purpose of the language switcher). I am going to make a Pull Request of my work in progress. It's better than nothing, and I would also like some technical feedback and reviews, etc., regarding how to implement this. |
|
Update for anyone following this: This feature was made working with URL parameters ( I'd still prefer to do this with URL prefixes, such as I do hope to/plan on re-merging this some time this calendar year with at least URL parameters ( |
Hi all,
In discussions about how best to show users the various languages we will have available, now that we are getting translations merged in, it was mentioned that a language switcher has advantages over purely automatic system. [1]
Basically, a user may be automatically detected as needing one locale, but they may prefer or be better suited by using a different locale. The language switcher allows them to pick the best language (of the ones we have) that suits their needs.
Technical plan
Language Selection Logic
I think our current logic for determining the locale to use should be expanded upon.
It currently just does this: "Check the user's accept-language HTTP headers", then "If we have one of those languages, or even their exact lang-REG locale, serve it." -- "Otherwise, serve the
enlocale."I propose we add a step, right at the beginning:
"Read the 'lang' parameter of the URL", then "If we have that locale, serve it", otherwise fall back to the previously described system.
(The other major option seems to be using different lang subdomains, e.g.
es.refugerestrooms.org,zh.refugerestrooms.org.) [2]The switcher itself -- Setting the "lang=" parameter of the URL
This means we have to add the switcher, in a way that can set the language parameter of the URL. We also need a way to persist or carry-over that language parameter of the URL when navigating to other sub-pages of the site.
Since the language switcher interface should always be visible, I propose we should add it in the footer. (We can make the switcher its own
_partial.html.hamland render it in that way.)I expect all the code for this would be either pure Ruby, or a mix of Ruby and JavaScript. JavaScript code can be embedded in Ruby code, so if it's mixed, I think the code would all be in a
.rbfile.We can then evaluate this from the
.html.hamlfile with= _lang_switcher, or something along those lines.User Interface
(Proposing a 'language' drop-down menu near the bottom (or top?) of the page. We can make it look nice with a flag image next to each locale, and format it with CSS, when the time comes.
But anything that works and looks nice or has a good user-experience is welcome as a suggestion.)
Open to discussion, and particularly if this sounds like a good plan, we may get going on an implementation.
The text was updated successfully, but these errors were encountered: