Nothing to translate: error page is not helpful

[GoogleCodeExporter]

What steps will reproduce the problem?
1. installed django-rosetta
2. setup urls.py
3. created japanese

What is the expected output? What do you see instead?

I was expecting the page to load. Instead I get a message saying:

Nothing to translate!
You haven't specified any languages in your settings file, or haven't yet 
generated a batch of translation catalogs.

Please refer to Django's I18N documentation for a guide on how to set up 
internationalization for your project.

What version of the product are you using? On what operating system?

Mac OS X
Python 2.6.1
My Virtualenv contains:

pitseleh: poswald$ pip freeze
Django==1.1.1
South==0.6.2
distribute==0.6.10
django-debug-toolbar==0.8.1
django-profiles==0.2
django-rosetta==0.5.3
docutils==0.6
pysqlite==2.5.6
wsgiref==0.1.2

Please provide any additional information below.

The site switches and displays languages correctly. I have django.mo and UTF-8 
django.po files in the following dirs:

/Users/poswald/Projects/[django_project_name_here]/locale/ja_JP/LC_MESSAGES
/Users/poswald/Projects/[django_project_name_here]/locale/en_US/LC_MESSAGES

I tried setting LANGUAGES in my settings file (although I don't think I should 
have to, should I?):

LANGUAGE_CODE = 'en-us'
LANGUAGES = (
    ('ja', 'Japanese'),
    ('en', 'English'),
)

Please let me know what is going wrong or if there is more information you need 
to debug this. I'm out of ideas. At the very 
least, perhaps we can get a better error message that explains exactly how it 
has determined that I don't have a translatable 
site?

Original issue reported on code.google.com by paulosw...@gmail.com on 27 Feb 2010 at 3:01

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Cheers, thank you for your feedback. 

Original comment by mbonetti on 28 Feb 2010 at 12:10

• Changed state: Invalid

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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