You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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.
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 :)
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
Simple
backendHere'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:
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
The text was updated successfully, but these errors were encountered: