Hacktoberfest / hacktoberfest-2020

Hacktoberfest - App to manage the annual open-source challenge, used for the 2019 & 2020 seasons.

Home Page:https://hacktoberfest.digitalocean.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Move all strings to i18n data

MattIPv4 opened this issue · comments

Feature description

All strings show to the user within the app should be moved to i18n data.

This provides two key benefits:

  • Allows the DigitalOcean creative folks to easily see all messaging used within the app and suggest changes
  • Provides the ground-work within the app to allow us to potentially localise parts of (or the whole) app

Hello! I'd love to take a look at this one on stream tomorrow and work on the foundation for this. Seems like you've got a few problems to resolve here:

  1. Adding the gem and ensuring it's called during template render
  2. Determining and setting the User's locale
  3. Converting all strings in the application to keys in a yml config file
  4. Translating those keys into additional languages

I'd like to complete 1.
I would use params for 2. I'll build it so it can be swapped to a user config or domain later. I'll also ensure existing URLs don't change, so we don't break anyone's links, it'll just be extra params, and I'll set the default locale to 'EN'.
For 3, I would set up a few templates to demonstrate how to translate, but then there should be separate issues for different sets of views.
I cannot help with 4. 😄

If this all sounds good, let me know, if there are issues, definitely let me know.

I'm happy to chip in on 3. There are a few things to bear in mind with this, though:

  • Referring to i18n strings via keys means it can be harder to visualize how something's going to look when it's represented on the page. GetText is an alternative that allows you to keep strings in the view files and template them in for different locales - I've not yet used it myself, but it may be preferable.
  • i18n's strong in that you can refer to things relatively. Say you're rendering a template under home/index - if you call t('.hello_world') from in there, you're referring to the key en.home.index.hello_world. This can be costly if you're not raising errors on failed lookups - if you decide to move home/index to somewhere/else, you'll also need to change from:
en:
  home:
    index:

to:

en:
  somewhere:
    else:

. That can be easy to forget, and hard to catch unless you're raising errors for missed translations and testing that all your views render. Hope that's helpful!