On Fri, Oct 24, 2008 at 09:26:48PM +0900, Takao Fujiwara - Tokyo S/W Center 
wrote:

>> beadmin.py:
>>
>>   - line 434: why all the encoding support?  Will date_format ever be
>>     non-ASCII?  You don't catch UnicodeError here -- couldn't that be a
>>     problem when calling encode()?  Why is all the encoding stuff done 
>>     here and nowhere else?
>
> The current encoding is supported. Yes, date_format is none-ASCII.
> Currently I don't see other visible problems.  Internal encoding is UTF-8
> in GNOME applications and input/output encoding is the current encoding.
> strftime() needs current encoding.

So the translation -- the output of _() -- comes back in what encoding?
UTF-8?  Current?  Arbitrary?  If it comes back in UTF-8, then the
conversion to UTF-8 isn't necessary, and if it comes back in the current
encoding, then none of this is necessary.  So the translation must be
stored in an encoding that may or may not be UTF-8 or the current encoding?

> "utf-8").encode(locale.getpreferredencoding())

Will .encode() work?  That's supposed to use the current encoding by
default, but I haven't been able to determine whether
locale.getpreferredencoding() is the same thing.

>> image.py:
>>
>>   - line 495: Why is this the only place in all the code you make this
>>     change?  There are two other places in this file alone that have the
>>     same problem, and I'm sure there are tons of other places in other
>>     files.
>
> Because I don't see actual problems in other lines. Currently some
> translations are back and I noticed this line need to change the order.
> I don't notice your two places. I mind the problem when the string includes 
> more than two %s and gettext().

There's one with two %s in salvagedir() and one with a %s and a %d at the
bottom of check_cert_validity().

> Yes, potentially you may find other places but I'm thinking the problem 
> from the actual translations at the moment.

Okay.  It's reactive, but I guess that's fine for now.

>> misc.py:
>>
>>   - line 381: You shouldn't need this -- gettext.install() need only be
>>     called once for the process, so once it's in client.py and
>>     packagemanager.py, you're done.  In general, your code does a bunch of
>>     different things to try to get at the localized text.  In each
>>     program's main() or equivalent, you should call gettext.install() with
>>     the appropriate arguments, and use _() everywhere else.  But some
>>     places you use bindtextdomain() and textdomain() either in addition to
>>     or in place of gettext.install(), and you add a "_" member to objects
>>     pointing to gettext.gettext() rather than just using the builtin _()
>>     function, and in some places you create a N_() method ... it's all 
>>     over the place.
>
> However the function doesn't have self argument? in bytes_to_str(bytes)
> What is your suggestion to get self.parent._() something?

I don't understand the question.  My question is why not just use _() all
the time?  You install it once, with gettext.install() when the program
first starts up, and then you have _() in the builtin dictionary in all
modules from there on out.

>>   - line 384: Are these symbols really translated?  They're SI standard.
>
> Yes, it needs to be localized in GUI. If it's better to show ASCII in CLI, 
> another idea is to move the function from modules/misc.py to 
> gui/modules/foo.py

No, there's no need to make these strings ASCII in the CLI.  I was just
surprised that they ever ended up as anything other than B, kB, etc, since
those are standard SI units and prefixes.

>> packagemanager.py:
>>
>>   - line 99 et al: you don't need continuation characters inside of parens
>>     (or brackets or braces); please remove them in lines you're changing,
>>     and clean them up as you encounter them in future fixes.
>
> I may not understand your suggestion. Do you mean the following change?
>
> module.bindtextdomain("pkg", self.application_dir + \
>                             "/usr/share/locale")
> to
>
> module.bindtextdomain("pkg", "/usr/share/locale")

No, those are two different statements.  I'm simply saying that if you've
got an expression that's enclosed in parentheses, it can span multiple
lines without needing the backslash to indicate continuation.

>> updatemanagernotifier.py:
>>
>>   - I don't understand this change.  Why is it necessary (other than the
>>     /usr/lib to /usr/share change)?  Why is it not consistent across all
>>     the programs?
>
> Actually I needed gettext.textdomain().
> If it's not called, GUI doesn't show translations as the result.
> It seems _current_domain needs to be set with textdomain()

Why is it needed here and not everywhere else?  The lack of consistency is
incredibly confusing.

Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to