ufw-gtk broken with Turkish locale

[baudm]

Original issue 19 created by baudm on 2012-03-13T12:23:53.000Z:

# LANG=tr_TR.UTF-8 ufw-gtk
Missing policy for 'input'

In ufw, locale is unset. In ufw code executed by ufw-frontends, code is set to system locale. If LC_CTYPE is tr_TR.UTF-8, bad string case occurs giving strings like "somethIng" - uppercase I.

A modification has been made into ufw itself which made it work with ufw-frontends (at first I, and another person I've asked about it thought it was a problem with ufw, filed a bug report and they've committed the change). But it turned out that this approach had caused a regression for them so it was reverted. (ufw bug #953372)

So, please take a look at it in ufw-frontends. The easiest approach that seems to work is to set LC_CTYPE to C.

ufw-frontends 0.3.1, ufw 0.30.1, ufw 0.31.1

--

How to test it:
in ufw's backend.py

--- backend.py
+++ backend.py
@@ -205,6 +205,7 @@

             orig.close()

+        print self.defaults
         # do some default policy sanity checking
         policies = ['accept', 'accept_no_track', 'drop', 'reject']
         for c in [ 'input', 'output', 'forward' ]:

a) correct output:
# LANG=tr_TR.UTF-8 ufw status
{'ipt_modules': 'nf_conntrack_ftp nf_nat_ftp nf_conntrack_netbios_ns', 'default_output_policy': 'accept', 'loglevel': 'low', 'manage_builtins': 'no', 'enabled': 'yes', 'default_input_policy': 'drop', 'default_forward_policy': 'drop', 'ipv6': 'yes', 'default_application_policy': 'skip'}
Status: active

b) incorrect output
# LANG=tr_TR.UTF-8 ufw-gtk
{'Ipt_modules': 'nf_conntrack_ftp nf_nat_ftp nf_conntrack_netbios_ns', 'default_applIcatIon_polIcy': 'skIp', 'loglevel': 'low', 'manage_buIltIns': 'no', 'enabled': 'yes', 'default_Input_polIcy': 'drop', 'default_forward_polIcy': 'drop', 'Ipv6': 'yes', 'default_output_polIcy': 'accept'}
Missing policy for 'input'

Thanks.

[baudm]

Comment #1 originally posted by baudm on 2012-03-13T12:25:52.000Z:

this snippet shows exactly what happens if "STRING" is not Unicode string, but operated on that locale:

python -c 'import locale; locale.setlocale(locale.LC_ALL, "tr_TR.UTF-8"); print "STRING".lower()'

[baudm]

Comment #2 originally posted by baudm on 2012-03-13T13:19:26.000Z:

Hi, could you try commenting out the call to ufw_localize() in ufw-gtk and check if that changes anything?

[baudm]

Comment #3 originally posted by baudm on 2012-03-13T13:28:52.000Z:

Hah, it does (ufw 0.31.1 and 0.30.1):

ufw-gtk

Traceback (most recent call last): File "/usr/sbin/ufw-gtk", line 9, in main() File "/usr/lib/python2.7/site-packages/gfw/frontend_gtk.py", line 744, in main ui = GtkFrontend() File "/usr/lib/python2.7/site-packages/gfw/frontendgtk.py", line 66, in init super(GtkFrontend, self).init() File "/usr/lib/python2.7/site-packages/gfw/frontend.py", line 39, in init super(Frontend, self).init(False) File "/usr/lib/python2.7/site-packages/ufw/frontend.py", line 162, in init self.no = ("n") NameError: global name '_' is not defined

[baudm]

Comment #4 originally posted by baudm on 2012-04-01T13:36:12.000Z:

Hello, it's been a while. Could you try applying the attached patch and test again? Thanks.

[baudm]

Comment #5 originally posted by baudm on 2012-04-01T15:26:02.000Z:

Hi! With this patch I also needed to add "import os" to l10n.py. I get the same error:

LANG=tr_TR.UTF-8 ufw-gtk

Missing policy for 'input'

[baudm]

Comment #6 originally posted by baudm on 2012-04-01T15:42:48.000Z:

Sorry about the missing import; I generated the patch too soon. Anyway, please test this new patch. I've removed the l10n stuff for ufw-frontends since it's not really needed right now.

[baudm]

Comment #7 originally posted by baudm on 2012-04-01T16:15:06.000Z:

Same thing happens.

[baudm]

Comment #8 originally posted by baudm on 2012-04-05T10:05:33.000Z:

Hmm, I'm stumped so I read about i18n in PyGTK's FAQ; hopefully, it helps. I can't reproduce this bug that's why I'm attaching 3 patches to possibly fix this.

Patch 3a sets the locale to the user's setting, binds a text domain to it, and uses both the gettext API and class-based API (similar to ufw).

Patch 3b is essentially the same as 3a except that it only uses the class-based API of the gettext module.

Patch 3c sets the locale to 'C' and uses the gettext class-based API (as per your suggestion).

[baudm]

Comment #9 originally posted by baudm on 2012-04-05T12:41:26.000Z:

Wow, nice! Patches "a" and "b" don't do the job, but it's OK with the "c" one.

• Works under Turkish locale.
• Translations provided by ufw (displayed on the status line) work. One remark here, on my system ufw translations are installed in a proper location, /usr/share/locale/*/LC_MESSAGES/ufw.mo. To have translations provided by ufw I needed to replace the gettext.install line with this: "gettext.install(ufw.common.programName)" so it looks for .mo files in the "standard" location. Just saying, it's not a business of ufw-frontends to adjust to such changes, I think. :)

Thanks for the good job.

PS This bug required some interaction. :) If at any point it'd be useful for you to contact with me directly via IRC, IM or mail, no problem.

Just tested, seems to work with 0.30.1 too.

[baudm]

Comment #10 originally posted by baudm on 2012-04-05T12:54:51.000Z:

Hmm, do those translations come from the ufw package itself? I'm actually confused because if you look at the ufw code, it uses both the gettext API and the class-based gettext API:

class-based API: gettext.install(ufw.common.programName)

gettext API: gettext.bindtextdomain(ufw.common.programName, \ os.path.join(ufw.common.transdir, 'messages')) gettext.textdomain(ufw.common.programName) = gettext.gettext

What's more confusing is that in the call to gettext.install(), the localedir was not specified (meaning the default localedir will be used). However, in the call to gettext.bindtextdomain(), a localedir was specified.

Anyway, I'll just commit patch 3c with your changes. Thanks a lot! :)

[baudm]

Comment #11 originally posted by baudm on 2012-04-05T16:28:37.000Z:

Fixed in commit af7b0fd01bca885d63b5c9b4ec320abcdb7881af

[baudm]

Comment #12 originally posted by baudm on 2012-04-05T19:09:14.000Z:

Hmm, do those translations come from the ufw package itself? In my case (Sabayon, Gentoo based, and the same is in Gentoo) they come from .po files shipped in ufw sources (using which .mo are generated). As far as I know, in Ubuntu ufw's translations are (also?) provided by language packs, but those aren't used on my system.

In ufw's build system installing of .mo is a bit borked (/usr/share/ufw/messages is not the best location :)). ref.: https://bugs.launchpad.net/ufw/+bug/626178

What's interesting is that if I do `strace ufw', I can see it doesn't even look for .mo files under /usr/share/ufw/messages despite the code you mention! On the other hand, ufw-gtk, after the last patch, looks into that directory. I have no idea why it works this way if set with gettext.install (your patch) but doesn't if set in gettext.bindtextdomain (ufw).

I'm actually confused because if you look at the ufw code, it uses both the gettext API and the class-based gettext API:

class-based API: gettext.install(ufw.common.programName)

gettext API: gettext.bindtextdomain(ufw.common.programName, \ os.path.join(ufw.common.transdir, 'messages')) gettext.textdomain(ufw.common.programName) = gettext.gettext

Maybe that's why they're lucky and the problem with Turkish locale doesn't occur with ufw itself? I don't know, it's just a guess. An interesting note, if I place "import locale; print locale.getlocale()" in ufw code, for example: --- backend.py +++ backend.py @@ -205,6 +205,7 @@

         orig.close()

• import locale; print locale.getlocale()

  do some default policy sanity checking

  policies = ['accept', 'accept_no_track', 'drop', 'reject'] for c in [ 'input', 'output', 'forward' ]:

it prints "(None, None)" if I use "ufw status"; and if "ufw-gtk" executed, it used to print a string like "('pl_PL', 'UTF-8')". However your last patch changes that and "(None, None)" is now printed as well. :) (locale.setlocale(locale.LC_ALL, 'C') - precisely this line changes the behaviour.)

What's more confusing is that in the call to gettext.install(), the localedir was not specified (meaning the default localedir will be used). However, in the call to gettext.bindtextdomain(), a localedir was specified.

(see above)

The text field to type the comment is way too small, I needed to help it using geany :)