Danek Duvall-san wrote (10/25/08 06:46 AM):
> 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
The output of _() is expected UTF-8 in GTK with bind_textdomain_codeset(). The
part is needed because strftime() needs the current encoding.
> 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.
I think .encode() works and probably I don't understand your problem.
The default argument getpreferredencoding() is True so I think it returns the
current encoding even though you didn't call setlocale().
If you use UTF-8 locales, I think this part won't effect UI.
>
>>> 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().
I think it's a nice discussion.
emsg("\nWarning - directory %s not empty - contents preserved "
"in %s" % (path, salvagedir))
Currently we don't add gettext here. The message is a CLI warning and it's not
required i18n.
If we will add gettext(), I think using %(path)s may be a safety.
However probably this part will be ok with %s because of the same reason below.
emsg(_("Certificate for authority %s will" \
" expire in %d days" % (pfx, diff.days)))
Yes, it's potentially a problem but probably I think the order is not changed
in the most languages because %s is the nominative and %d is included in
the last. I don't see actual problems in the current translations.
If you will add the strings with multiple "%s", I recommend to use "%()s" +
vars() in Python.
Unfortunately C style "%1$s" doesn't work in Python.
>
>> 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.
Ah, thanks for pointing out this. Let's gettext.install() is removed.
--- pkg/src/modules/misc.py.orig
+++ pkg/src/modules/misc.py
@@ -38,6 +38,7 @@
import time
import calendar
import shutil
+import gettext
from stat import *
import pkg.urlhelpers as urlhelpers
@@ -45,6 +46,8 @@
from pkg.client.imagetypes import img_type_names, IMG_NONE
from pkg import VERSION
+_ = gettext.gettext
+
def time_to_timestamp(t):
"""convert seconds since epoch to %Y%m%dT%H%M%SZ format"""
# XXX optimize?
>
>>> - 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.
OK, I see.
>
>>> packagemanager.py:
> 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.
OK, I understood you're talking about the coding style which originally exists.
The backslash will be removed.
>
>>> 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.
I'd like to change all parts to gettext.textdomain().
The default _ is gettext.translation(domain, localedir).gettext and it's not
useful for me when I try to get the default domain with
gettext.textdomain(None)
gettext.textdomain (domain)
gettext.bindtextdomain (domain, localedir)
_ = gettext.gettext
fujiwara
>
> Danek
>
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
