On Mon, 2007-06-11 at 05:03 -0700, sandro dentella wrote:
> > Firstly, trying to do that works for me. So there's something else
> > going wrong. Are you running under psyco or something?
> 
> no. Simple python2.4. I'll investigate that further.

Very strange. :-(

> 
> > not something Django supports in general. So one solution is to use
> > two different settings files if you want to test two different
> > LANGUAGE_CODE
> 
> that's  a possible solution indeed.
> 
> > way that needs LANGUAGE_CODE changed? Maybe there's another approach
> > we can suggest.
> 
> i guess so...
> 
> What I'm trying to do is just some tests for templatestags and I'm
> calling
> the functions directly. They produce text that is normally localized.
> I
> didn't want to put dependency on the LANGUAGE_CODE in the test but I
> don't
> have a good idea apart what you suggested (useing a different
> settings).

Okay, if you're calling functions directly, you can probably use
activate() and deactivate(). Something like

        >>> from django.utils.translation import activate, deactivate
        >>> activate('en')
        >>> # Do tests here
        >>> deactivate()
        
Or am I misunderstanding?
        
In the unicode branch, we needed something even stronger:
deactivate_all(), which ensures that any strings are not translated at
all, into any locale -- the normal deactivate() method restores the
default locale(), which is not the same as "do nothing". So soon (for
some definition of "soon" that probably means "in a couple of weeks")
that will be available on trunk as well, but might be a little longer
(the Oracle branch is ahead in the queue).

> By the way I realize now that running django test suite on my settings
> file raises some errors for the same reason, but only in few places:
> defaulfilters (maily dates) and Humanize. Forms for example behave
> correctly. I dont'understand how they prevent translation to happen in
> newforms tests...

There are a few interesting bits of broken handling of translations in
newforms that normally mean strings aren't being translated at the right
time (they are translated on construction, rather than rendering). You
might just be getting lucky and the bugs coincide with what you want to
happen in this case. Don't rely on that staying true, though. :-)

Regards,
Malcolm


--~--~---------~--~----~------------~-------~--~----~
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 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to