[Chandler-dev] Re: EggResourceManager ready for review
Phillip J. Eby
pje at telecommunity.com
Tue Aug 1 07:55:58 PDT 2006
At 02:42 AM 8/1/2006 -0700, Andi Vajda wrote:
>On Mon, 31 Jul 2006, Brian Kirsch wrote:
>>Can you elaborate more, -1 is not very descriptive.
>Indeed, it's not. It was getting late here and I was responding to the
>statement saying "However, requiring only ASCII file paths in the egg is
>fine. I think anything beyond that is merely a nice to have feature and
>not a must have feature."
>It's not fine and not just a nice to have feature. If this topic is all
>about doing good on the i18n and l10n promises then requiring ASCII paths
>seems to be going against that idea. ASCII-only paths are a US-only feature.
>But maybe I misunderstood the context of the conversation and my comment
>is off the mark ?
We were talking about source code and resource filenames only. For source
code, file names are already effectively limited to ASCII since Python
identifiers are strings, so the issue there is moot.
It could perhaps be argued that resource filenames (files containing
images, HTML, etc.) should allow non-ASCII characters in the file names,
but the problem is the lack of a universal file encoding across
platforms. Ironically, to ensure cross-platform internationalizability,
filenames for localizable resources may need to be ASCII only. That is, if
you create a plugin that has a resource with a non-ASCII filename, a user
on another platform might not be able to create a localization for it.
It's not solely an issue with zip files, since the user must be able to
create filesystem files in order to build an egg in the first
place. Currently, such files will be zipped with 8-bit paths using the
default filesystem encoding -- which of course may not match the encoding
on another system where the zipfile is used.
More information about the chandler-dev