Hi - new webrev that simplifies things further. If we want to make RC1 
this would need to land on Monday our time or else it will have to go 
into RC2.

I have smoke tested this with the PM, UM and CLI. I have brought up the 
BE Management in the PM to exercise the bytes_to_str call in misc.py and 
I have done a full Update All from b99 -> b100 to exercise the UM and 
the libbe code that was failing due to lack of _() in the global namespace.


Webrev: http://cr.opensolaris.org/~jmr/pm_4126_v10_Nov01
Stopper Bug: http://defect.opensolaris.org/bz/show_bug.cgi?id=4126

CLI: uses set_locale and gettext.install, has _() available in the 
global namespace and is the recommended way to l10n enable python apps.
Python l10n Docs: http://docs.python.org/library/gettext.html
"The class-based API of the gettext module gives you more flexibility 
and greater convenience than the GNU *gettext* API. It is the 
recommended way of localizing your Python applications".

GUI: uses set_locale, bindtextdomain and textdoamin to setup glade so 
widgets are instantiated with the correct textdomain and is the 
recommended approach for l10n enabling of PyGTK apps, see faq below.
PyGTK Faq: http://faq.pygtk.org/index.py?req=show&file=faq22.002.htp 
<http://faq.pygtk.org/index.py?req=show&file=faq22.002.htp>

Problem: several modules used by the GUI need _() in the global 
namespace which is not provided by using just bindtextdomain and 
textdomain. Solution is to alias __builtin__._ = gettext.gettext in the 
top level GUI module, so any modules it uses that need _() in the global 
namespace are happy, namely misc.py and installupdates.py (calling libbe 
that needs _() via beadm.py).

Builtin and PyGTK: 
http://lucumr.pocoo.org/articles/internationalized-pygtk-applications


One query remains, use of N_(). I understand the usage but just don't 
think we need it at present.
Use of N_: http://docs.python.org/library/gettext.html#deferred-translations

When I search for N_ I see it defined in packagemanager.py but not used 
anywhere. It is also defined and used in l10n.py, but the comment is 
talking about categories such as l10n08 = N_("RasterGraphics") which are 
not used in the GUI anywhere. Is this a hold over from some old 
translation? It looks to me like l10n.py should be removed and the 
definition of N_ removed from packagemanger.py. Fujiwara what do you think?

Fujiwara can you please review the pkgdefs/SUNWipkg-gui/Makefile to make 
sure it is ok for your purposes. There where conflicts between your diff 
and what was in the gate, so I took the gate.

Post 2008.11: GUI should be modified to use _() as opposed to self._() 
and self.parent._(). No functional difference, just keeps things consistent.

JR


jmr wrote:
> Doing some more digging and seeing examples like the following for gnome 
> pygtk apps, so perhaps this approach of using:
>
> locale.setlocale(locale.LC_ALL, '')
> for module in (gettext, gtk.glade):
>         module.bindtextdomain("pkg", self.application_dir + \
>                             "/usr/share/locale")
>         module.textdomain("pkg")
> gettext.install("pkg", self.application_dir + "/usr/share/locale")
>
> Is what's needed after all. If we do this then we do not need to have 
> self._ = gettext.gettext and self.parent._ through out the GUI code, the 
> addition of _ = gettext.gettext could be dropped from misc.py as well. 
> Then _() will be in the global python namespace for both CLI and GUI.
>
> JR
>
> http://kefir.sourceforge.net/tepache/SimpleGladeApp.html
> def bindtextdomain(app_name, locale_dir=None):
>     try:
>         import locale
>         import gettext
>         locale.setlocale(locale.LC_ALL, "")
>         gtk.glade.bindtextdomain(app_name, locale_dir)
>         gettext.install(app_name, locale_dir, unicode=1)
>     except (IOError,locale.Error), e:
>         print "Warning", app_name, e
>         __builtins__.__dict__["_"] = lambda x : x
>
> ||
>
> http://www.pointy-stick.com/lca-2005/
>
> import gettext, locale
> ...
> def main(name, version):
>     gettextName = 'debuggerDemo'
>     localeDir = '%s/locale' % _currentDir()
>     gettext.bindtextdomain(gettextName, localeDir)
>     gettext.textdomain(gettextName)
>     gettext.install(gettextName, localeDir, unicode = 1)
>
>
> http://www.pixelbeat.org/programming/i18n.html
>
>     Python:
>
>         import gettext, locale
>         gettext.bindtextdomain("fslint", "/usr/share/locale") #sys default 
> used if localedir=None
>         locale.setlocale(locale.LC_ALL,'')
>         gettext.textdomain("fslint")
>
>         #Note if you initially do the following, it is much
>         #faster as lookup for mo file not done for each translation
>         #(the C version automatically caches the translations so it's not 
> needed there).
>         gettext.install("fslint",localedir=None,unicode=1) #None is sys 
> default locale
>
>
> jmr wrote:
>   
>> New webrev:
>>
>> http://cr.opensolaris.org/~jmr/pm_4126_v9_Oct31/
>>
>> Moved the gettext.install() in client.py back into main_func()
>>
>> Tried experimenting with dropping the gettext.install from installupdate 
>> and setting _ = gettext.gettext in beadm.py, this did not help when I 
>> tried to do an update all and I get an error from libbe about _ not 
>> being a global name. So put it back.
>>
>> In the end we might just have to settle on adding gettext.install() for 
>> any underlying python module support in the GUI which cannot use the 
>> self._ setup in the PM or UM, as well as the textdomain for the glade 
>> support. If we did that then we could drop the _ = gettext.gettext in 
>> misc.py and the gettext.install() in installupdate.py as well.
>>
>> Let me know what you want us to do.
>>
>> JR
>>
>>
>> jmr wrote:
>>   
>>     
>>> Yep - I also wanted to generate a new one but am not able to as I've 
>>> exceed my disc quota and cannot move any old webrevs to the .trash 
>>> folder as per instructions on cr.opensolaris.org. Michal has the same 
>>> problem so assume this is a problem with the machine.
>>>
>>> I've attached rev8.
>>>
>>> JR
>>>
>>>
>>>     
>>>       
>> _______________________________________________
>> pkg-discuss mailing list
>> [email protected]
>> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
>>   
>>     
>
> _______________________________________________
> pkg-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
>   

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

Reply via email to