Closed GoogleCodeExporter closed 9 years ago
One thing that seems odd is that the language prefixes ('ja' and 'en') do not
match the paths to the locales (ja_JP
and en_US).
This is probably why Rosetta can't find your po files, still I wonder how this
setup *does* work with Django.
Original comment by mbonetti
on 28 Feb 2010 at 11:13
Try it... it works. As far as I knew, that was how you were *supposed* to do
it. I see now that it's mentioned as just
"ja" in the localization docs:
http://docs.djangoproject.com/en/dev/topics/i18n/localization/#topics-i18n-local
ization
I'm not the only one who does it that way:
http://www.google.com/search?&q=django+%22en_US%2FLC_MESSAGES%22
http://blog.jeffbalogh.org/post/108035503/introducing-poboy
So I guess you're expecting my paths to be something like:
/locale/ja/LC_MESSAGES
In this kind of setup, how do people localize en_US and en_UK differently?
Oh here we go... (from
http://docs.djangoproject.com/en/dev/topics/i18n/deployment/#how-django-discover
s-
translations)
"In all cases the name of the directory containing the translation is expected
to be named using locale name
notation. E.g. de, pt_BR, es_AR, etc."
Original comment by paulosw...@gmail.com
on 28 Feb 2010 at 11:28
Cheers, thank you for your feedback.
Original comment by mbonetti
on 28 Feb 2010 at 12:10
So... a status of "invalid" implies that you don't intend to support this style
of naming directories even though the django docs say it's legit?
"In all cases the name of the directory containing the translation is expected
to be named using locale name notation."
http://docs.djangoproject.com/en/dev/topics/i18n/#term-locale-name
Original comment by paulosw...@gmail.com
on 28 Feb 2010 at 12:35
Rosetta *does* support this kind of naming directories, but you'll have to make
sure that the locale defined in
your settings matches the one in the path.
So, these are all supported: de, de_DE, de-ch, de_at ... but they *are all
different locales*: the path to the po file
must reflect (i.e. match) this.
Original comment by mbonetti
on 28 Feb 2010 at 1:28
OK, I see what you're saying. By "the locale defined in your settings" Do you
mean the LOCALE_PATHS and not the LANGUAGES setting?
http://docs.djangoproject.com/en/dev/ref/settings/#locale-paths
http://docs.djangoproject.com/en/dev/ref/settings/#languages
The LANGUAGES should be a "language code" (it, de-at, es, pt-br) whereas the
LOCALE_PATH specifies a "locale name" (it, de_AT, es, pt_BR). The LANGUAGES
setting is a list of
LANGUAGES you wish to explicitly support. If it is not set, it is assumed that
all of the django languages are supported.
The locale middleware itself compares the lang_code string from the browser
request to the installed languages (optionally filtered by the settings
LANGUAGES variable) to
activate the user's language preference using the utils.translation code.
Notably, if "en-us" isn't found, it falls back to just "en":
lang_code = lang_code.split('-')[0] # e.g. if fr-ca is not supported fallback to fr
http://code.djangoproject.com/browser/django/trunk/django/utils/translation/tran
s_real.py#L319
http://code.djangoproject.com/browser/django/trunk/django/utils/translation/tran
s_real.py#L34
This is why Django middleware works for me and django-rosetta doesn't
I see the fact that the Django localization middleware works with the
locale-based path structure and a default (empty) LOCALE_PATH and missing
LANGUAGES setting, but
django-rosetta doesn't as a bug. The django-rosetta code should also be able to
find the po/mo files without the LANGUAGES or LOCALE_PATHS set at all. The
LANGUAGES
setting only specifies that you want to offer a subset of the django languages
to your users. At the very least, the error message it gives is wrong.
As far as I know, this line of code is making an invalid assumption:
http://code.google.com/p/django-rosetta/source/browse/trunk/rosetta/views.py#240
This one too:
http://code.google.com/p/django-rosetta/source/browse/trunk/rosetta/views.py#263
The code is using a different algorithm to determine if there are localized
files than the django middleware is. Django will happily translate an
application without any
LANGUAGES set.
As an aside, I've remembered why I started doing it this way in the first
place... It's hinted this way in the manage.py help makemessages command when
using the --locale
option:
-l LOCALE, --locale=LOCALE
Creates or updates the message files only for the
given locale (e.g. pt_BR).
I hope this is helpful.
Original comment by paulosw...@gmail.com
on 28 Feb 2010 at 2:49
No, by "locale defined in your settings" I mean `[l[0] for l in
settings.LANGUAGES]` i.e. the "language code" as
defined in http://docs.djangoproject.com/en/dev/ref/settings/#languages
Based on that, Rosetta will look for a corresponding po files in several
directories (the app directories, the
project's main 'locale' dir, directories defined in LOCALE_PATHS, ...)
If the language code is composed (lang-ctry or lang_ctry) Rosetta does all kind
of tricks to pick up po files for
that locale: it'll look for pofiles in lang_ctry/, lang_CTRY/, lang-ctry/ and
lang-CTRY/ in all the locale
directories defined above. Look it up, the relevant code is in
rosetta/poutil.py
If, OTOH, you defined your locale to be ('ja', 'Japanese') in
settings.LANGUAGES, it will not go looking for a
pofile in ja_JP, only in ja/LC_MESSAGES, because ja_JP *is a different locale*
than 'ja'.
I hope this clarifies why I set this to be invalid.
Original comment by mbonetti
on 28 Feb 2010 at 6:33
Original issue reported on code.google.com by
paulosw...@gmail.com
on 27 Feb 2010 at 3:01