Dealing with legacy django project in new localized projects

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 开发者_Go百科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.

---

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.