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.