为什么Rails中的语言环境设置充当全局（使用Thin时）？

我刚刚意识到推荐的Rails方法可以在控制器中设置区域设置

before_filter :set_locale def set_locale I18n.locale = params[:locale] || I18n.default_locale end

全局设置区域设置。上面的代码有效，但我想知道如果你必须明确键入它， default_locale真的是默认的吗？

我期望的是每个请求都有一个区域设置（就像我们有每个请求的会话一样）并做类似的事情：

 def set_locale locale = params[:locale] if params[:locale] end

并且默认情况下使用I18n.default_locale 。这将理想地匹配路径中的可选区域设置：

 # config/routes.rb scope "(:locale)", :locale => /en|nl/ do resources :books end

目前，如果出于某种原因我在某些操作中跳过了区域设置，它会使用上一个请求中设置的区域设置，该区域设置可能来自其他用户！

并且不存在潜在的竞争条件，因为一个请求可以更改全局I18n.locale而另一个请求（在I18n.locale之前设置了另一个语言环境）处于渲染的中间？

更新：我现在发现的一些细节，来自I18n文件：

将当前语言环境设置为伪全局，即在Thread.current散列中def locale =（locale）

现在我想了解每个请求是否是一个单独的线程。

更新2：请参阅我的答案以获得解释。

所以现在最后的答案。 TL; DR设置区域设置仅在使用线程Web服务器（如Thin和Puma）时才充当全局。

正如我所提到的， I18n.locale=

将当前语言环境设置为伪全局，即在Thread.current哈希中

因此它应该是按照请求，并且它在Webrick和Unicorn中以这种方式工作。

但是，如果您使用像Thin或Puma这样的线程Web服务器，那么该线程似乎会存在更长的时间，并且会为将来的请求保留该值，直到明确更改为止。我从中学到的是来自新的Steve Klabnik的gem request_store ：

如果你需要全局状态，你可能已经达到了Thread.current。

<...>

所以人们正在使用那些花哨的线程Web服务器，比如Thin或Puma。但是如果您使用Thread.current，并且您使用其中一个服务器，请注意！值可能会比您预期的更长时间，这可能会导致错误。

上面的推荐代码不会全局设置区域设置，而是按请求设置它。

 before_filter :set_locale def set_locale I18n.locale = params[:locale] || I18n.default_locale end

代码通常放在BaseController中，因此在每个页面呈现之前，它会被触发并设置。没有竞争条件，因为每个页面都会触发此代码，并且将在那里计算I18n语言环境。您可以将此扩展为使用英语来查找用户区域设置，而不是会话区域设置，而不是请求参数。

 def set_locale I18n.locale = @user.locale || session[:locale] || params[:locale] || :en end

换句话说，如果你在一个页面上设置本地，让我们在家庭控制器中说德语，并得到仪表板控制器，你会看到默认语言（英语）。因为改变不是全球性的。这就是代码放在基本控制器中的原因。希望它有意义。