Working with the django project legacy in new localized projects

I am now in a situation planning to internationalize the django project, which contains mostly outdated code. The old project itself has different applications that are highly dependent on each other, so it is difficult to separate them. Looking at the remaining time, this is not possible at all.

Basic requirements for internationalization:

  • Separate projects for each country
  • Each country will have different patterns.
  • each country will introduce new features that other countries will also want to use.
  • the main old code base will be supported and should work with new features / changes in country projects.

Do you have any ideas / settings for working with old code AND launching new projects depending on the old code and new functions? I would like to start a discussion on this issue.

+4
source share
1 answer

Start by decoupling the components where possible, and convert legacy code to (portable) applications if that is not the case, and legacy code should not live under the main project tree.

Any new features should be well-documented and decoupled by the applications or by the shared libraries themselves, even if they override / interact / depend or even render obsolete the code. You want most of your project to work outside the main project and install through pip, as if they were third-party applications.

The main project tree should not be much larger than the main project project templates, urls.py, settings.py, any configuration / deployment and fabfile templates, and any main applications that will rarely be configured.

Each localized setting should be either the "settings" of the applications themselves or small changes in the main project (this should be done in a reproducible way via fab or any provider of your choice)

Needless to say, if each team can complete the main project, a good git / hg workflow is needed and a central CI server with a good set of tests is needed.

+1
source

All Articles