Skip to content
This repository has been archived by the owner on Mar 29, 2022. It is now read-only.

Move all strings to i18n data #444

Open
MattIPv4 opened this issue Jan 6, 2020 · 2 comments
Open

Move all strings to i18n data #444

MattIPv4 opened this issue Jan 6, 2020 · 2 comments
Labels
feature-request Unaccepted user submitted new feature suggestion
Projects

Comments

@MattIPv4
Copy link
Member

MattIPv4 commented Jan 6, 2020

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
@MattIPv4 MattIPv4 added the feature-request Unaccepted user submitted new feature suggestion label Jan 6, 2020
@MattIPv4 MattIPv4 added this to Triage in 2020 via automation Jul 24, 2020
@ChaelCodes
Copy link

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.

@boardfish
Copy link

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!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature-request Unaccepted user submitted new feature suggestion
Projects
2020
  
Triage
Development

No branches or pull requests

3 participants