I could be off base here but in regards to the the execution of
translation initialization I believe that is occurring because the
django.core.management.base attempts to switch the translation to
english if the can_import_settings attribute is set:

if self.can_import_settings:
    from django.utils import translation

According to the docs this is done because django-admin (manage.py)
executes some database stuff related to permissions.  Since this is
set to True by the BaseCommand this is likely the cause.

You might try creating your own custom command that executes the test
runner but only after setting this attribute to false and checking
your results then.


On Nov 24, 2007 12:03 PM, Marcin Kaszynski <[EMAIL PROTECTED]> wrote:
> One more comment after a day of writing unit tests: installing
> coverage.py via a test runner is not a good idea.
> The test runner is executed pretty late and there is a chance that
> part of your code gets executed earlier.  I do not know if this is the
> only possible case, but I had the code in appname/__init__.py files
> executed during translation initialization, which is way before Django
> even looks at the command line passed to manage.py.
> Right now my code detects the --with-coverage option and installs
> coverage right in projectname/manage.py as the very first thing,
> before importing any other module.  This gives far more accurate
> results.
> I still believe it would be a good idea to add the --with-coverage
> option to Django, since it would make it a bit easier it for people to
> do proper testing (and one less excuse not to do it right).  If it
> sounds good to you I can create a patch for that, moving the code that
> installs coverage.py to django.core.management.
> -mk
> >

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 

Reply via email to