【问题标题】:Software architecture for localization本地化软件架构
【发布时间】:2015-05-08 13:30:47
【问题描述】:

我们目前正在向其他欧盟市场推出在线商业软件,在这些市场中,不仅语言而且规则和法规因国家/地区而异,这让我想知道,在软件中实施此类软件的最佳方式是什么?

UI 本地化并不是一个真正的问题 - 这样做的次数多到我可以数数,但例如,在开具发票的国家/地区往往需要不同的数据(虽然不是完全不同,但差异足以让您思考架构方面)意味着不同的输入、不同的验证以及对数据的不同处理。

哪种方式可以考虑更好?

  • 本地化 UI 和添加所需条件语句以在 Controller 类中显示和隐藏具有类似条件的非必要元素的标准方法
  • 为给定国家/地区创建应用的副本,并稍微更改控制器和视图(这将使不断更新成为一场噩梦,但代码更简洁)
  • 试图以某种方式围绕此创建工厂/构建器模式?

虽然最后一个对我来说听起来最合理,但它更让我沮丧,因为我不知道从哪里开始。有什么好的建议吗?

选择的语言是带有 Laravel 的 PHP

【问题讨论】:

    标签: php laravel architecture localization software-design


    【解决方案1】:

    绝对不要制作不同的副本。

    查看您当前的数据库架构,了解如何扩展它以满足您的要求。然后重写或更新应用程序的业务逻辑代码层。

    那么你只需要在前端做一些小调整。

    【讨论】:

      【解决方案2】:

      这个帖子有点老了,但标题很笼统,其他人可以通过搜索找到,所以我把我的答案写在下面:

      我认为这完全基于您的架构。近年来,人们遵循不同的原则将整个应用程序分解为具有特定任务和边界的有意义的微服务。这种思维方式将帮助您分析整个业务流程以及您可能需要为每个客户或国家/地区进行一些定制的地方。 例如,对于产品目录或库存管理,每个国家/地区之间的流程可能没有区别。但是在付款或订单管理中,您需要做一些小的修改,这在您遵循微服务模式时会更容易。此外,您可以拥有自己的插件加载器结构,通过在您的应用程序中使用过滤器/挂钩功能,您可以修改、覆盖和扩展每个实例,就像您在 WordPress 和其他开源平台中看到的那样。

      【讨论】: