Babel 2.3.2 ignores ungettext_lazy

[ajaeger]

With OpenStack Horizon, I noticed that the extraction of strings suddenly skips a lot of strings.

Just compare file sizes:
-rw-r--r-- 1 aj users 707 Apr 11 08:01 django232.pot
-rw-r--r-- 1 aj users 911 Apr 11 08:00 django2.pot

to reproduce:

1. Unzip the attached zip file
2. Run "pybabel extract -F babel-django.cfg --add-comments Translators: -o django232.pot -k gettext_noop -k gettext_lazy -k ngettext_lazy:1,2 -k ugettext_noop -k ugettext_lazy -k ungettext_lazy:1,2 -k pgettext_lazy:1c,2 -k npgettext_lazy:1c,2,3 test-babel"
3. Compare the above between Babel 2.2.0 and 2.3.2

the zip file contains my locally generated pot files using Babel 2.2.0 (django2.pot) and 2.3.2 (django232.pot).

babel232-bug.zip

[ajaeger]

Note pgettext_lazy strings have the same problem.

Just add somewhere:

pgettext_lazy('Default style theme', 'Default')

And it's not extracted with Babel 2.3.2 but is extracted with Babel 2.2.0.

[akx]

Would doing

[...] -k "gettext_noop gettext_lazy ngettext_lazy:1,2 ugettext_noop ugettext_lazy ungettext_lazy:1,2 pgettext_lazy:1c,2 npgettext_lazy:1c,2,3" [...]

work as a workaround? I.e. passing the keywords in as the space-separated string the command description mentions, instead of passing them as separate arguments.

I agree this is a regression though; it definitely makes sense for -k to allow multiple repetitions.

[ajaeger]

Aarni, yes, that works and we can easily change it.

thanks,
Andreas

[ajaeger]

Note that Babel 2.2.0 does not like the new syntax:

File "/home/aj/Software/vcs/OpenStack/openstack/horizon/venv/lib/python2.7/site-packages/babel/messages/frontend.py", line 1241, in parse_keywords
funcname, indices = string.split(':')
ValueError: too many values to unpack

No real problem, just wanted to point out that multiple values is a new feature of 2.3.

Andreas

[akx]

@ajaeger Yeah, that's entirely possible. Thanks for the note though :)

Versions < 2.3.0 had duplicate code for two different flavors of CLI utilities (distutils and standalone), and they probably did things in subtly different ways. #311 was the PR that removed the duplication -- and inadvertently also introduced this bug, #385, and #383.