Rails app逻辑国际化

Kaz*_*min 10 ruby-on-rails internationalization

我正在开发一个rails应用程序,它将在不同的国家/地区运行单独的实例.国际化处理语言问题,但是当有一些小的逻辑变化时,我不确定如何处理.一个例子是支付方法 - 在每个国家,不同的选项将显示给具有不同集成的用户.另一个例子是工资 - 税收和社会保障在国与国之间完全不同,因此我们需要考虑到这一点.

差异并不是那么多,所以一般来说我不想为每个国家创建不同的git分支,但我可能错了.

我目前正在考虑的解决方案是为每个国家/地区设置一个不同的环境 - "production_germany","production_france"等等,并根据它来加载不同的yml文件,其中包含我需要的所有必要变量国家.然后创建一个"Manager"类,它将决定要加载哪些特殊类以及在视图上显示哪些内容(只要存在差异).例如,我可以在"salary_calculation/de"中获得德国的工资计算类,在"salary_calculation/fr"中获得法国的工资计算类,并仅加载我需要的工资计算类.

你的解决方案是什么?

ami*_*hle 7

我会尽可能地使用Rails来处理I18n.如果你还没有,还要看看rails-i18n.

对于Rails没有处理的特殊情况,我会像Rails一样自行解决.例如,在您config/locales的国家/地区,您可能需要对税收进行一些配置:

en:
  taxes:
    name: Tax
    rate: 0.065
de:
  taxes:
    name: USt
    rate: 0.19
Run Code Online (Sandbox Code Playgroud)

然后,您编写一个TaxesHelper模块,该模块将使用区域设置文件中的信息来显示税率.看看Rails NumberHelper包.

如果您实际上使用税率等计算,我会将该因子保留在您正在进行计算的模型中.这样,当税率发生变化时,您的计算就不会搞砸了.假设您有以下型号:

class Invoice < ActiveRecord::Base
  # Injected by AR
  # attr_accessor :net_price
  # attr_accessor :tax_rate
  def gross_price
    net_price * tax_rate
  end

  before_create do
    tax_rate = I18n.t(:rate, scope: [ :taxes ]).to_f
  end
end
Run Code Online (Sandbox Code Playgroud)

这样,在特定国家/地区的税率发生变化后,您的总价格不会因持续发票而发生变化.


bbo*_*ozo 5

Amiuhle就如何处理静态参数化提供了很好的建议 - 语言,税率等,

当你需要更多的业务逻辑时,事情会变得更加复杂,并且没有一刀切的解决方案,只要确保知道你可以使用的工具并确保你选择合适的工具,这里还有一个似乎是在ruby社区中有点未充分利用:

依赖注入

例如:http://solnic.eu/2013/12/17/the-world-needs-another-post-about-dependency-injection-in-ruby.html

例如,这种模式通常适用于管理支付提供商网关

class Transaction < ActiveRecord::Base
  def gateway_class
    I18n.t(:class_name, scope: [ :payment_provider ]).constantize
  end
  def gateway
    @gateway ||= gateway_class.new(self)
  end
end
Run Code Online (Sandbox Code Playgroud)

I18n根据国家/地区对支付提供商类进行参数化:

en:
  payment_provider:
    class_name: PaymentProvider
de:
  payment_provider:
    class_name: AnotherPaymentProvider
Run Code Online (Sandbox Code Playgroud)

并且您确保支付提供程序类回答相同的公共API,因此对于整个应用程序,不必知道使用了哪个支付提供程序,只需要连接支付提供程序类.

另一个好处是,您可以创建一个FakePaymentProvider用于测试和开发的类,这将大大加快您的测试速度 - 即使您通常使用Web模拟工具vcr,您仍然可以使用类似vcr测试集成的东西,并且只是集成,与应用程序架构的其余部分分离.

实际上,看看这里:https://github.com/activemerchant/active_merchant有人已经在该计划上做了很多工作:)

  • 在ruby vs yaml中,`payment_provider`与`payment_providers`.无法编辑,因为它必须至少6个字符... (2认同)