On 7/2/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> This, I like. The function can originally be installed in
> django/conf/__init__.py (where the translation.install() call
> currently lives), and it can load from the django.utils.translation
> backend appropriately. It's actually not *too* h
On 7/2/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> How would you feel about making a requirement that settings must be
> configured prior to attempting to use translations. By this, I mean,
> Django must know that it is either using DJANGO_SETTINGS_MODULE or
> manual configuration prior to
On Sun, 2006-07-02 at 21:16 -0500, Adrian Holovaty wrote:
> On 7/1/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > So you could leave the strings in settings.py, providing you define a
> > function called gettext_noop. All this function does is return the
> > string passed to it (that is all
On 7/1/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> So you could leave the strings in settings.py, providing you define a
> function called gettext_noop. All this function does is return the
> string passed to it (that is all it does for real, anyway). Then the
> strings are marked with as
Hi Adrian,
On Sat, 2006-07-01 at 12:52 -0500, Adrian Holovaty wrote:
[...]
> The problem with this arrangement is that it causes any import of
> django.utils.translation to load django.conf.settings -- and the
> settings file in itself imports the translation hooks, because of the
> LANGUAGES set
I'm working on improvements to this new USE_I18N setting I added
yesterday, and I've run into a bit of a problem --
In my local Django sandbox, I've turned django.utils.translation into
a package that contains __init__.py, trans_real.py and trans_null.py.
The __init__.py contains this:
from
