在新的本地化项目中处理遗留的 django 项目
我现在正在计划一个主要包含遗留代码的 django 项目的国际化。旧项目本身有不同的应用程序，彼此之间有很强的依赖性，因此很难将它们分开。看看剩下的时间，根本不可能。
国际化的主要要求是：
- 为每个国家/地区提供单独的项目
- 每个国家/地区稍后将有不同的模板
- 每个国家/地区将引入其他国家/地区可能也想使用的新功能
- 主要的旧代码库仍将得到维护，并且应该与新功能一起使用/国家/地区项目的更改
您是否有任何想法/设置来处理旧代码并启动依赖于旧代码和新功能的新项目？我想就此展开讨论。
I am right now in the situation to plan the internationalization of a django project that contains mainly legacy code. The old project itself has different applications which have a strong dependency to each other, so it is hard to separate them. Looking at the time left it is impossible at all.
The main requirements for the internationalization are:
- Having separate projects for each country
- Each country will later have different templates
- each country will introduce new features which other countries may want to use as well
- the main old codebase will still be maintained and should work with new features/changes to the country projects
Do you have any ideas/setups to deal with the old code AND starting new projects with the dependency to the old code and new features? I would like to start a discussion about this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先尽可能解耦组件，如果还没有将遗留代码转换为（可移植）应用程序，并且遗留代码不应位于主项目树下。
任何新功能都应该有良好的文档记录，并解耦应用程序或通用库本身，即使它们覆盖/交互/依赖甚至猴子修补遗留代码。您希望项目的大部分内容位于主项目本身之外，并且可以通过 pip 安装，就像它们是 3rd 方应用程序一样。
主项目树应该不超过项目主项目模板、urls.py、settings.py、任何配置/部署模板和 fabfile，以及很少自定义的任何核心应用程序。
每个本地化定制都应该只是“定制”应用程序本身，或者是对主项目的小调整（应该通过 fab 或您选择的任何提供商以可重复的方式进行），
不用说，如果每个团队都可以致力于核心项目中，良好的 git/hg 工作流程至关重要，并使用具有良好测试套件的中央 CI 服务器。
Start by decoupling the components where possible, and convert the legacy code to (portable) apps if not the case already, and the legacy code should not live under the main project tree.
Any new features should be well documented and decoupled apps or generic libraries themselves, even if they override/interact/depend or even monkeypatch the legacy code. You want most of your project to live outside of the main project itself, and installable via pip as if they were 3rd party apps.
The main project tree should be not much more than the project main project templates, an urls.py, settings.py, any configuration/deployment templates and a fabfile, and any core apps that will be rarely customized.
Every localized customization should just be either "customization" apps themselves, or small tweaks to main project (that should be made in a reproducible way via fab, or any provider of your choice)
Needless to say, if every team can commit to the core project, a good git/hg workflow is essential, and use a central CI server with a good test suite.