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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
