Danek - I'd like to get this wrapped up for 2008.11. Looking through your comments it looks as if there are no further changes required, but perhaps some clean up and rationalization post 2008.11 to reduce the inconsistency.
I'd like to get this landed, any objections? http://cr.opensolaris.org/~jmr/um_4126_v2_Oct24/ JR Danek Duvall wrote: > 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
