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

Proposal: Lazy Loading on a Per Locale Basis #592

Closed
paarthmadan opened this issue Dec 15, 2021 · 2 comments
Closed

Proposal: Lazy Loading on a Per Locale Basis #592

paarthmadan opened this issue Dec 15, 2021 · 2 comments

Comments

@paarthmadan
Copy link
Contributor

Lazy Loading on a Per Locale Basis

In Shopify's Core monolith, we noticed that we were paying the price of loading all translations for all locales in the test environment, despite only using a subset of them.

We've patched i18n locally to lazy load translations on a per locale basis and have observed some resounding performance benefits (25% speedups to our entire test suite time on average).

We'd like to see this supported upstream and are willing to work together with maintainers of ruby-i18n/i18n to see this through.

Rationale

Usage of i18n is scoped to the currently set locale. That is, you only "care" about the translations for the given locale. It is counter-productive to require loading all translations for all locales when we only care about a subset of them. We can incrementally initialize and load translations per locale as required, as opposed to loading all translations in the load path that may not be relevant to the current locale.

Possible Approaches

  1. Patching the Simple backend

Here's an example branch that showcases a proof of concept of what this might look like (tests passing with minimal changes)

It uses a Regexp to filter on the load path, choosing all relevant files based on the current locale. This works in our Core monolith, because our locale files follow the convention to prefix with the locale identifier, but might not be a scalable approach for everyone.

Instead:

  1. Introduce a new backend (maybe: LazyLoadLocale)

This can be used as an opt-in backend, will maintain backwards compatibility, and will allow us to create a solution that makes more crude assumptions (such as: all load path files can be identified by their locale). We imagine most conventional Rails application whose translations files are specified using the pattern: config/locales/<locale>.yml will benefit from this.

Gauging Interest

I was hoping to start a discussion to gauge interest in supporting this lazy loading by locale strategy. I'm happy to further discuss the importance of this change, my commitment to owning this, the approach etc.

Excited to hear your thoughts @radar!

cc: @adrianna-chang-shopify, @casperisfine, @dirceu

@radar
Copy link
Collaborator

radar commented Dec 15, 2021

I'd be cautious with changing the behaviour of SimpleBackend here, as it may cause unintended side-effects for applications that rely on that one. So you've got my vote of confidence for the LazyLoadLocale option :)

@paarthmadan
Copy link
Contributor Author

Feature is now supported as a result of #612 being merged.

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

2 participants