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 setting in global_settings.py:
>
> from django.utils.translation import gettext_lazy as _
> LANGUAGES = (
> ('bn', _('Bengali')),
> ('cs', _('Czech')),
> ('cy', _('Welsh')),
> ('da', _('Danish')),
> ('de', _('German')),
> # ...
> )
>
> So, in order to make this work, I'm proposing that we *disallow*
> translation strings in settings files -- so that the
> django.utils.translation file can import from settings and we avoid
> circular import references.
>
> This leaves the problem: Where do we put the translation strings for
> the available languages? For that, we could put the translation
> strings in in django/utils/translation/trans_null.py and change any
> instance of LANGUAGES to apply the gettext call at runtime rather than
> compile time. Or is there a better way to solve the problem?
The way the translation extraction code (xgettext) works is to search
for particular keywords that are the names (or aliases) of functions
marking translatable strings. One of these keywords is gettext_noop,
which is the "mark for translation, but don't translate yet" function.
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 gettext_noop('Bengali'), etc, and it should
all Just Work(tm).
There are no namespacing issues here because xgettext just looks for
strings matching the keyword. So having a little
def gettext_noop(s): return s
in global_settings.py shouldn't hurt anything. You still need to then
wrap all uses of settings.LANGUAGES in a call to gettext() or _().
So does this help or hurt? For translators, it doesn't really matter
where these strings are, just as long as they are picked up by the
xgettext runs to generate the .po files. For i18n maintainers (Hugo),
they need to be able to find this list reasonably quickly for adding to
it. Splitting up the list so that two places have to be updated (the
list of codes in global_settings -- which I don't think you can remove
without making things awkward -- plus the mapping of code to translated
string) is not ideal (leads to mistakes).
Translatable strings in the project's settings.py are a small problem.
They would have to define their own gettext_noop() as above. Not a real
burden in those cases, I guess.
If the extra gettext_noop function in global_Settings.py doesn't offend
your sense of style too much, I would prefer that approach, just to keep
everything in one place.
Best wishes,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
