language switching in Preferences has no effect

[antonxx@…]

I just:

• upgraded a trac 0.11.7 to 0.12b1 (with mod_python) where I have a user login
• created a fresh trac 0.12b1 environment which I started as standalone (without user permission _> using only anonymous)

I can change the language in Preferences from default to German but nothing happens.

I have genshi 0.6 babel 0.9.5 installed.

My trac is istalled as:

/usr/local/lib/python2.6/site-packages/Trac-0.12b1-py2.6.egg

… so its still compressed and the localisation *.mo files are inside the egg.

Is this a problem for babel??

[anonymous]

Hi, after several attempts I managed to have trac user interface translated in my locale language (italian). In order to do that, I :

• installed Babel and Gneshi as usual (just typed easy_install Babel Genshi)
• installed Trac 12b1 from source as described here: ​http://trac.edgewall.org/wiki/TracInstall#Fromsource

Please pay attention to run the command

python ./setup.py compile_catalog -f

before the command

python ./setup.py install

[hope]

Replying to anonymous:

Hi, after several attempts I managed to have trac user interface translated in my locale language (italian). In order to do that, I :

• installed Babel and Gneshi as usual (just typed easy_install Babel Genshi)
• installed Trac 12b1 from source as described here: ​http://trac.edgewall.org/wiki/TracInstall#Fromsource

Please pay attention to run the command

python ./setup.py compile_catalog -f

before the command

python ./setup.py install

I forgot to say that after this procedure switching the language in preferences do work right!!

[Carsten Klein <carsten.klein@…>]

This is already documented on TracInstall.

Should we close this?

[Remy Blank]

I'd like to check first if installing via easy_install works as expected.

[antonxx@…]

OK I reinstalled from source, now it works.

To be mentioned:

• before reinstalling I had to delete Trac-0.12b1-py2.6.egg from the site-packages dir and delete the line "./Trac-0.12b1-py2.6.egg" from the Trac-0.12b1-py2.6.egg file.
  Otherwise the install aborts with an error.
• it would be nice to mention the python ./setup.py compile_catalog -f in the INSTALL file.

You can close it … I leave it open since you wanted to test something.

From my point of view its OK ;-)

[Christian Boos]

The .tar.gz and .zip files don't contain the .mo files. I'll regenerate them.

Besides, I've been suggested that we should make the compilation of catalog a more implicit step, triggered by an install.

Maybe a new build_mo command, which would do a compile_catalog if Babel is installed?

build_mo could not only triggered by an install, but also by an sdist.

[Christian Boos]

one more try… ;-)

[hope]

Replying to Carsten Klein <carsten.klein@…>:

This is already documented on TracInstall.

Should we close this?

You're right, it is already documented on that page but I think that it is a bit confused. For a user like me was not obvious the fact that to obtain the translation it's mandatory to install trac from source.

By the way right now i'm using the 12b1 and I have to say that it's great. Good job!!

[Remy Blank]

Replying to cboos:

The .tar.gz and .zip files don't contain the .mo files.

I can confirm that. Installing with easy_install downloads the .zip and runs bdist_egg, and the resulting egg doesn't contain any .mo files either.

[Christian Boos]

Replying to rblank:

Replying to cboos:

The .tar.gz and .zip files don't contain the .mo files.

I can confirm that. Installing with easy_install downloads the .zip and runs bdist_egg, and the resulting egg doesn't contain any .mo files either.

Even worse, I've not managed yet to convince setuptools to integrate the .mo files when they're present, it just ignores them even when there's an explicit trac/locale/*/LC_MESSAGES/*.mo pattern in install_data in setup.py…

[Christian Boos]

#9304 closed as duplicate.

Actually, rather than forcing the .mo files into the sdist, it should be better to make compile_catalog a dependency of the build step (or another custom command, like build_mo, see comment:7).

Any hint about how to achieve this would be welcomed.

[Christian Boos]

Triggering a compile_catalog as the first step of a build is easy:

setup.py

@@ -18 +18 @@
 
 try:
     import babel
+    from distutils.command.build import build
+
     extractors = [
         ('**.py',                'python', None),
         ('**/templates/**.html', 'genshi', None),
@@ -28 +30 @@
         'trac': extractors,
         'tracopt': extractors,
     }
+    build.sub_commands.insert(0, ('compile_catalog', lambda x:True))
 except ImportError:
     pass

With the above, bdist_wininst does the right thing, the .mo files are already there when build_py copies the package_data below build/.

But unfortunately, bdist_egg doesn't run a build command…

[Christian Boos]

ensure compile_catalog command is called before bdist_wininst and bdist_egg

[Christian Boos]

Please test the above patch. In particular, I'd be curious to know whether this works with Distribute or not.

[anonymous]

Two issues with this:

• The trac.log should contain hints that locale does not work due to missing catalogs.
• The install target should not install .po-files. In a release environment po files have no reason to exist.

[Remy Blank]

I can confirm that t9291-compile_catalog-first.patch​ works on Linux with Distribute:

• Created an .egg and easy_installed it. The translations work.
• Created a source distribution and easy_installed it. The translations work.

However, as mentioned in comment:15, the .egg contains the .po and .pot files, which are not needed. The following additional patch fixes that, and the resulting source and egg distributions still work correctly.

setup.py

@@ -61 +74 @@
     package_data = {
         '': ['templates/*'],
         'trac': ['htdocs/*.*', 'htdocs/README', 'htdocs/js/*', 'htdocs/css/*',
-                 'htdocs/guide/*', 'locale/*.*', 'locale/*/LC_MESSAGES/*.*'],
+                 'htdocs/guide/*', 'locale/*/LC_MESSAGES/*.mo'],
         'trac.wiki': ['default-pages/*'],
         'trac.ticket': ['workflows/*.ini'],
     },

[Christian Boos]

Ok, as long as the sdist keeps the .po files, it's fine.

Patch + addendum from comment:16 applied in r9638.

Keeping the ticket opened until the TracInstall doc is updated.

[Remy Blank]

Actually, the .pot file is not needed at run time either, that's why I removed the locale/*.* item in comment:16.

[Christian Boos]

Sorry, missed that one, committed in [9640].

[Christian Boos]

Replying to anonymous:

Two issues with this:

• The trac.log should contain hints that locale does not work due to missing catalogs.

That would be tricky to do, and is not really useful: if you have Babel correctly installed (as visible in the About Trac / Config view for example) but you don't have localization working, then it's because the compiled catalogs have not been installed… Which should be rare now, as the present issue has been fixed.

• The install target should not install .po-files. In a release environment po files have no reason to exist.

Besides, another nice effect of the changes from comment:14 is that the list of available languages is now restricted to the languages for which there is a compiled catalog…

E.g. Vietnamese, Farsi, Spanish and Greek are not listed, as they all have some fuzzy translations and hence were skipped by compile_catalog (which is good).

So if you don't have catalogs, you also don't have the possibility to select the corresponding language (this apply to post-r9640 versions, of course).

[Christian Boos]

Forgot to add: for those who have installed 0.12b1 via easy_install and can't wait for the next release (0.12rc1), simply do:

easy_install Trac==dev

[Carsten Klein <carsten.klein@…>]

Replying to hope:

You're right, it is already documented on that page but I think that it is a bit confused. For a user like me was not obvious the fact that to obtain the translation it's mandatory to install trac from source.

You are right, too. I for my part am working with a non translated version since I totally overlooked it on the wiki. Perhaps moving the paragraph up by one would do the trick, so that lazy people like us will eventually overread it ;)