Les grandes lignes sont semblables à tout autre grand projet de code. Les applications doivent répondre à une seule, clairement définis responsabilité. Le nom de "application" est un abus de langage; Django les applications doivent être considérés davantage comme des composants réutilisables qui peuvent être branchés ensemble pour créer une application réelle. Tests pour chaque application devrait être contenue à l'intérieur de cette application. Les applications doivent être découplés les uns des autres autant que possible, mais clairement, il y aura des dépendances, l'objectif doit donc être de garder le graphe de dépendance aussi simple et saine que possible.
Je préfère garder tous les modèles pour un projet dans le cadre d'un projet unique à l'échelle de répertoire de modèles, avec un sous-répertoire pour chaque application (à l'aide d'un modèle de sous-répertoire pour chaque app est un très fort convention dans Django, car il évite nom du modèle de collisions entre les applications). La raison pour laquelle un projet unique à l'échelle de répertoire de modèles est que les modèles, le modèle de l'héritage des arbres, et les noms des blocs peut être tout à fait spécifique à un projet, il est donc difficile de fournir "par défaut" application des modèles qui peuvent se brancher à n'importe quel projet. Il y a eu quelques tentatives pour établir des standards, conventions de nommage pour la base de l'ensemble du site, les modèles et les blocs qu'ils définissent, mais je n'ai pas vu un standard émergent encore (la manière de faire les choses plus à Pinax est probablement le plus proche que nous avons à une norme).
Re "chaîne de l'externalisation", si tu parles de l'i18n et l10n, Django a un soutien fort pour que les standard et les endroits où il met les .les fichiers po - vérifier les docs.
