在我的公司，我们有一个已经开发了5年多的web应用程序。我们仍然有一个包含PHP4的代码库，并且已经用PHP5的负载进行了扩展。LOC相当大，大约有471k。它不是基于框架、ORM等。
从这个项目开始的开发人员忽略了任何i18n和翻译。所有语言文本都在软件中进行了硬编码。是的，我知道这很糟糕。目前我们很好，因为我们只以软件编写的语言销售，但我们也在考虑向国外扩张。
我正在努力寻找处理翻译的最佳方法。你们会怎么做？使用框架重写会更好吗？因为这可能还会改进代码库并提供坚实的结构。或者你只是使用当前的软件过滤掉语言文本。
任何关于这个主题的提示和提示都将不胜感激！
我认为这两种变体都是可能的。你可以留下你的代码，或者重写。但正如你所知，重写是一个漫长的过程，尽管你已经写了5年多了。
如果它仍然稳定，运行良好，并且PHP4和其他你不需要的"美味的东西"，你可以离开，只需查看所有硬编码文本。i18n助手非常容易制作。你不需要做更多的事情：
- 选择适当的文本和翻译存储方式
- 已加载翻译的缓存机制
- 类和i18n操作的帮助程序
如果你决定重写你的代码，你应该好好分析你的商业计划。
仍然得到了额外的答案。翻译几乎相同的字符串是非常昂贵的。将其与语言数量相乘，人们就会意识到：共享相同字符串，也许还有格式的良好国际化确实更高效。
模板部分的第一次重写可能是有意义的。首先用手工，然后用您编写的自动转换工具。它应该准备I18N。
根据我的经验，一个项目有两个主要目标是不好的，尤其是从业务角度来看，这些目标几乎完全无关。我会有一个项目团队负责本地化（这可能不仅仅涉及翻译——不同的国家有不同的法律要求、货币、支付提供商等），还有一个团队负责"改进代码库"。
首先，我会让本地化团队为"你能做的最简单的事情"制定一个粗略的计划（和成本）——将本地化功能重新安装到网站中。除非从商业角度来看，这种成本是不可接受的——否则我会走这条路。
如果重构的商业案例还没有提出，我不会试图把它强行引入你的本地化项目——我以前也见过类似的事情发生，所有的开发人员都想研究很酷的重构东西，讨论各种框架的相对优点，以及使用哪种源代码控制系统，而企业关心的东西被推向了未来；最终，企业主对该项目失去了兴趣，并取消了它。
如果在不进行重构的情况下真的没有现实的本地化方法，我仍然会让两个独立的团队来运行它。本地化团队可以是重构团队的主要需求所有者，他们确实需要合作——但通过保持两个项目的独立运行，可以避免90%的重构完成，但只有10%的本地化完成的风险。
听起来你面前的不仅仅是翻译项目。如果你想把它带到国外，你必须重新设计系统的至少一部分。
如果你的预算允许，并且收益合理，你会想退一步，看看整体设计。保留你能保留的，但不要害怕拆除、重新设计、更换和升级它的主要部分
在过去的5年里，情况发生了很大变化，因此，如果你计划再销售多年的应用程序，那么重新设计它可能是值得的。
这取决于优先级，以及你应该做什么。
如果主要关注的是语言翻译，那么您可以从去掉硬编码的字符串开始，这样它们就可以国际化。
如果还有其他需求，比如希望轻松支持不同的数据库，那么这将有助于确定是否有更好的方法。