"Mark J. Nelson" <Mark.J.Nelson at Sun.COM> writes: > I added back scm-migration-dev to the cc list, for the Python compilation > question. > >>> So the .py.po rule is my only question, mainly because I haven't used >>> Python for anything with localization. >> >> Deltas on last delta (on top of "webrev-mjn"), showing removed .py.po: >> >> http://zhadum.east/ws/carlsonj/perl-rule/webrev-mjn-2/ >> >> Updated full webrev: >> >> http://zhadum.east/ws/carlsonj/perl-rule/webrev/ >> >> &^%& Python. :-/ > > Indeed. > > I think I'm OK with this, in that it works (I believe correctly) for a > script that is meant to be invoked (using python as an interpreter) as a > top level program. > > For something that would be imported as a module by another Python > program, we probably also need a .py.pyc suffix rule, but that's not the > bug you're fixing now. > > Sadly, "541 # Rule for Python (no i18n supported yet)" makes it sound like > Python doesn't support i18n, instead of "we don't support extracting > messages from Python code." That might actually be correct, because the > gettext.py folks seem to have completely punted on using portable message > objects (.po), and on the Solaris message catalog format (.mo), and gone > straight to GNU-only message objects (.mo). You know, why use existing > tools like xgettext and msgfmt, when you can reinvent them instead? :( > > For Jim: I'm done ranting now. Your changes look good. > > For scm-migration-dev folks: do we need a .py.pyc suffix rule?
We have one in onnv-scm. -- Rich
