On 2011-02-17 22:52, Rob Crittenden wrote:
Pavel Zůna wrote:
On 2011-02-17 05:09, Rob Crittenden wrote:
Pavel Zůna wrote:
My efforts in fixing localization all around the framework and
preparing
it for localizing docstrings have resulted in a lot of patches. Because
I understand they have become a bit hard to track, I decided to post
them all together in this thread to make review easier.

After this is committed, there will be one more patch that switches
xgettext for pygettext. Then hopefully, we'll be pretty much set
when it
comes to i18n.

Pavel

Patch 81 isn't applying for me.

Help is not working for me either, this is due to patch 80.

$ ipa help user
ipa: ERROR: NameError: global name '_' is not defined
Traceback (most recent call last):
File "/home/rcrit/redhat/freeipa-version/ipalib/cli.py", line 1087, in
run
api.finalize()
File "/home/rcrit/redhat/freeipa-version/ipalib/plugable.py", line 619,
in finalize
plugin_iter(base, (magic[k] for k in magic))
File "/home/rcrit/redhat/freeipa-version/ipalib/base.py", line 397, in
__init__
sorted(members, key=lambda m: getattr(m, name_attr))
File "/home/rcrit/redhat/freeipa-version/ipalib/plugable.py", line 608,
in plugin_iter
plugins[klass] = PluginInstance(klass)
File "/home/rcrit/redhat/freeipa-version/ipalib/plugable.py", line 585,
in __init__
self.instance = klass()
File "/home/rcrit/redhat/freeipa-version/ipalib/plugable.py", line 184,
in __init__
self.doc = _(inspect.getdoc(cls))
NameError: global name '_' is not defined
ipa: ERROR: an internal error has occurred

Patches 69, 71 and 73 are still working fine.

What is switching from xgettext to pygettext going to do?

This was answered by John Dennis: xgettext doesn't parse python
docstrings.


rob

Rebased version of 81 attached. It should also fix the traceback you're
getting.

Pavel

Something is still not working. I'm having a hard time reproducing how I
got this but with LANG=es_US.UTF-8 for a while I was getting this with
every ipa user-* request:

ipa: ERROR: UnicodeEncodeError: 'ascii' codec can't encode character
u'\xf1' in position 20: ordinal not in range(128)
Traceback (most recent call last):
File "/home/rcrit/redhat/freeipa-version/ipalib/cli.py", line 1090, in run
sys.exit(api.Backend.cli.run(argv))
File "/home/rcrit/redhat/freeipa-version/ipalib/cli.py", line 917, in run
rv = cmd.output_for_cli(self.api.Backend.textui, result, *args, **options)
File "/home/rcrit/redhat/freeipa-version/ipalib/frontend.py", line 953,
in output_for_cli
textui.print_entries(result, order, labels, flags, print_all)
File "/home/rcrit/redhat/freeipa-version/ipalib/cli.py", line 346, in
print_entries
self.print_entry(entry, order, labels, flags, print_all, format, indent)
File "/home/rcrit/redhat/freeipa-version/ipalib/cli.py", line 378, in
print_entry
label, value, format, indent, one_value_per_line
File "/home/rcrit/redhat/freeipa-version/ipalib/cli.py", line 309, in
print_attribute
self.print_indented(format % (attr, text[0]), indent)
File "/home/rcrit/redhat/freeipa-version/ipalib/cli.py", line 232, in
print_indented
print (CLI_TAB * indent + text)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf1' in
position 20: ordinal not in range(128)
ipa: ERROR: ha ocurrido un error interno

I think it is blowing up on this user:

User login: jose
First name: Jose
Last name: contraseñas
Home directory: /home/jose
Login shell: /bin/sh
Account disabled: TRUE
Member of groups: ipausers

Then all of a sudden things started working fine, so I'm not sure what's
going on.

Is this traceback meaningful to you?

rob

This looks like a bug in the textui backend.

You get this error when you do something like this:

>>> a = u'\xf1'
>>> a.decode('utf-8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/encodings/utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf1' in position 0: ordinal not in range(128)

It means we're not handling encoding/decoding from/to the CLI right somewhere.

The character \xf1 corresponds to the small N with tilde in Jose's last name.

I'm going to look into it, but I don't think it's related to the localization patches.

Pavel

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to