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.

Sign up for GitHub

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

Jump to bottom

Allow fallbacks to be initialized at boot time #481

Closed
f1sherman opened this issue Dec 21, 2020 · 5 comments
Closed

Allow fallbacks to be initialized at boot time #481

f1sherman opened this issue Dec 21, 2020 · 5 comments
Labels
fallbacks_plugin feature

Comments

@f1sherman
Copy link
Contributor

First of all, thank you so much for this amazing library!

One thing I noticed recently, is that the I18n fallbacks instance that is created for each attribute is lazy loaded. This is great for development, but in production, particularly with forking appservers, this can lead to increased memory usage and latency for the first request.

I was able to work around this with a monkey patch, but it would be great if something like the railtie Rails uses to initialize i18n could be introduced.

Thanks again!
@shioyama
Copy link
Owner

There are a bunch of issues around fallbacks:

Now that v1.0 has been released and the basic framework has stabilized, I'd really like to solve them all for 1.1 because fallbacks is such a popular feature, but I'm not actually a user of fallbacks myself so have a hard time seeing these issues. 🤔

@shioyama
Copy link
Owner

Out of curiosity, what did your patch look like?

f1sherman added a commit to f1sherman/mobility that referenced this issue Dec 23, 2020
@f1sherman
WIP of initializing fallbacks on start
b811e7f 
As pointed out in shioyama#481, I18n fallbacks [are lazy-initialized by
default](https://github.com/ruby-i18n/i18n/blob/4709391dceab9096d5988576f93935843023a6ef/lib/i18n/locale/fallbacks.rb#L71).
This can be problematic in production environments, particularly with
forking appservers, since:
1. The first request pays the initialization cost
2. Memory usage is duplicated across appserver processes rather than
   taking advantage of copy-on-write

This is a draft of a way to mitigate these problems. Readability isn't
great since the `i18n` library doesn't seem to have an API to explicitly
initialize fallbacks. Instead we're just looping through each locale and
referencing it so that `i18n` will initialize it.

Considerations:
1. We probably don't want this behavior in development, how should we
   account for that?
2. Ideally this behavior would be configurable, what is the right place
   for that configuration to live? This could potentially address (1).
3. Would this be considered a breaking change to have turned on by
   default?
@f1sherman f1sherman mentioned this issue Dec 23, 2020
Closed
@f1sherman
Copy link
Contributor Author

@shioyama I'm not sure how helpful my patch would be and I'm not authorized to share our source code. Instead I put together a WIP branch to help anchor the discussion. Hope this helps!

#482

@eirvandelden
Copy link

I tested this out locally on our own project, where we are migrating from Globalize to Mobility 1.x during an upgrade to Rails 5.
The patch by f1sherman works in our case, what would be needed to get his PR merged?

@shioyama
Copy link
Owner

I don't have time to implement this, so closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
fallbacks_plugin feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@f1sherman @shioyama @eirvandelden