[ python-Feature Requests-1649329 ] gettext.py incompatible with eggs

Thu Feb 8 20:09:31 CET 2007

Feature Requests item #1649329, was opened at 2007-01-31 18:20
Message generated for change (Comment added) made by jjinux
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1649329&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Shannon -jj Behrens (jjinux)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py incompatible with eggs

Initial Comment:
If you distribute your code in a zipped egg, you can't use translation catalogs stored in that egg.  That's because gettext.py only knows how to find the translation catalogs in the actual filesystem.

This wouldn't be so bad if the "find" function didn't serve double duty.  On the one hand, it implements the "find" algorithm to pick the right languages and fallbacks.  On the other hand, it actually resolves the files in the filesystem.  It would be nice if these were separate.  It seems like people in projects like Pylons are stuck copying code from the find function in order to work around this problem.

Perhaps gettext can be updated to know about eggs.  Perhaps setting localedir to something like "egg://..." would enable this functionality.

----------------------------------------------------------------------

>Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-08 11:09

Message:
Logged In: YES 
user_id=30164
Originator: YES

> What about translation() (which calls find, then also performs open())?
Wouldn't this need to be fixed as well?

Perhaps, but it's probably not as critical.  I.e. if the code gets
duplicated to deal with eggs, it's not as big a loss.  I really wish the
distutils guys would weigh in on this one.

> Also, what about os.path.join?

I think it's relatively harmless.  One can work around that.  One can't
work around os.path.exists.

> In principle, I'm willing to fix this. I just want to avoid adding a
hack.

I agree.  The patch isn't smelling too pretty.  Neither of us wants to
commit to a virtual filesystem layer which is how I've handled problems
like this in the past.  However, doing nothing results in a ton of code
being duplicated in any project that uses gettext and zipped eggs.  Should
we see if Phillip Eby has any ideas since he's Mr. Eggs?

> For example, it might be sensible to come up with a MOOpener interface,
that has an .exists method, taking a list of strings, a .join method,
taking a list of strings and returning something that can be passed to
the
.open method, which would take something that .join returned and
returning
a file-like object. It might be possible to extend the meaning of the
localedir parameter to be either a string (understood as a directory
name),
or a MOOpener object.

That's a light virtual filesystem layer ;)  If you want that, I have code
for that.

> In any case, people *will* have to duplicate find for the moment, as any
changes we discuss will only appear in 2.6.

True.  Alas, this may be a moot point.

Thanks for your time.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2007-02-08 00:27

Message:
Logged In: YES 
user_id=21627
Originator: NO

Ok, I see how this fixes find(). What about translation() (which calls
find, then also performs open())? Wouldn't this need to be fixed as well?

Also, what about os.path.join? It might depend on the structure of the
storage, as well (suppose you have the .mo data stored in a relational
database)?

In principle, I'm willing to fix this. I just want to avoid adding a
hack.

For example, it might be sensible to come up with a MOOpener interface,
that has an .exists method, taking a list of strings, a .join method,
taking a list of strings and returning something that can be passed to the
.open method, which would take something that .join returned and returning
a file-like object. It might be possible to extend the meaning of the
localedir parameter to be either a string (understood as a directory name),
or a MOOpener object.

In any case, people *will* have to duplicate find for the moment, as any
changes we discuss will only appear in 2.6.

----------------------------------------------------------------------

Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-07 16:52

Message:
Logged In: YES 
user_id=30164
Originator: YES

Ok, I've uploaded a patch with a possible way to refactor the code.  I'm
okay if you mark this bug as WONTFIX.  I'm raising it as a concern because
I know there are a lot of people out there using Web frameworks such as
Pylons, Turbo Gears, etc. that are going to have to duplicate the code in
"find" in order to use eggs.  I hate to have see them do that. :-/

----------------------------------------------------------------------

Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-07 16:49

Message:
Logged In: YES 
user_id=30164
Originator: YES

File Added: gettext.patch

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2007-02-06 22:45

Message:
Logged In: YES 
user_id=21627
Originator: NO

Do you have a proposal on how to do the refactoring? It would be fine to
split find into two parts; it would not be acceptable (to me) to teach it
egg: URLs.

----------------------------------------------------------------------

Comment By: Shannon -jj Behrens (jjinux)
Date: 2007-02-06 14:28

Message:
Logged In: YES 
user_id=30164
Originator: YES

Sorry, yes, this is a feature request.  The most important thing that I'm
requesting is to refactor the code.  That "find" function implements a
certain algorithm that has nothing to do with the filesystem.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2007-02-06 11:43

Message:
Logged In: YES 
user_id=21627
Originator: NO

I fail to see the bug. gettext.find behaves as specified; if you want
something else, don't use that function.

If you want to load a .mo file from a zip file, you should be able to
create a GNUTranslation object directly, from a file-like object.

I don't think that gettext should support eggs directly. If you want it to
do things other than loading from file systems, you should generalize that
appropriately. One appropriate generalization could be the introduction of
a directory-like object, where you can do .exists(relpath), and
.open(relpath). However, introduction of directory-like objets is PEP
material.

Reclassifying this as a feature request.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1649329&group_id=5470