Summary of the 2008-03-11 Packaging Committee meeting

[Toshio Kuratomi]

Ralf Corsepius wrote:
> On Thu, 2008-03-13 at 09:41 -0500, Toshio Kuratomi wrote:
>> Ralf Corsepius wrote:
>>> On Thu, 2008-03-13 at 01:25 -0500, Toshio Kuratomi wrote:
>>>> One of the problems I have with "ban packages with unicode names" is 
>>>> that it doesn't consider what to do when a package name upstream is 
>>>> non-ASCii.
>>> Transliterate/translate them to ASCII.
>>>
>> This is a proposal I am strongly -1 to.
> 
> IMO, you are making fuzz about nothing. For most languages such native
> transliterations exist.
> 
>>>>   My -1 vote is really a vote against having the Fedora 
>>>> packager make up a name for an upstream package which I very strongly 
>>>> oppose.
>>> Why would this be a problem? 
>>>
>>> May-be this is a problem with "pictographic" charsets (May-be
>>> traditional Chinese), but I am having difficulties to imagine this to be
>>> a problem elsewhere, because most (all?) languages have an nominal
>>> transliteration/translation to ASCII.
>>>
>> It is not as simple as you make out.  With "pictographic" charsets (not 
>> only traditional Chinese) different languages may pronounce a character 
>> in different ways. 
> That's why I mentioned them. It's a place I can imagine (I don't speak
> any Asian language nor can I write any of them),
> translation/transliteration could become problematic.
> 
>>  So the transliteration will depend on the language 
>> the naming author was envisioning when they created it.
> Yes - But ask yourself: What is better, naming a package "koji" or
> seeing an (In my locale) unreadable Asian glyph (rsp. a "boxed char"),
> probably only Asians are able to type?
> 
>> This isn't limited to pictographic languages.  For instance, look at 
>> wikipedia's current rules on transliterating Cyrillic:
>>    http://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_(Cyrillic)
> Yes, transliteration into latin/ASCII depends on the authors locale!
> 
> Sometimes it's simple (as with French accents: "é->e"), sometimes it's
> less simple (as with German umlauts: ß->ss, ä->ae), sometimes it's more
> complicated (as with Cyrillic, Hebrew, Arab, etc.), sometimes it's
> difficult (e.g. Asian).
> 
>> Other things to note from wikipedia are that they have multiple methods 
>> of transliterating from cyrillic within a language depending on the 
>> usage of the word and whether it currently has a common transliteration. 
>>   I think this is just too complex an issue for us to say there is one 
>> logical and right way to transliterate a name and expect every other 
>> distro to use the same conventions.  This needs to be done cross-distro 
>> at least, upstream if possible.
> I do not agree. We should not try to solve the world's problems. Instead
> we should (IMO can not avoid to) restrict ourselves to a smallest common
> denominator to keep Fedora going.
> 
> Dimitry will not be able to type my last name (contains an é), I won't
> be able to type your name in its Japanese writing nor Dimitry's in his
> native Cyrillic spelling.
> 
> This doesn't have any impact on our current lives, because
> transliterations/translations exist.
> 
So propose banning the package until upstream changes the name, gives an 
official transliteration to ASCII, or a cross-distro group decides on a 
transliterated name for it (It was just mentioned to me that there's a 
new mailing list and project for cross-distro collaboration.  It's early 
in its development so this may or may not develop into the kind of place 
where this kind of collaboration would take place[1]_).

My objection is not based on unicode==good; it's based on not wanting to 
do at the distro level something that should be done for all packagers 
in all distros.

.. _[1]: http://lists.freedesktop.org/mailman/listinfo/distributions

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080313/a11c33f5/attachment.sig>