On Thu, 13 Mar 2008 23:27:03 +0100, Nicolas Mailhot wrote: > Le jeudi 13 mars 2008 à 22:51 +0100, Michael Schwendt a écrit : > > > I'd like to understand the goal/the purpose of permitting unusual > > characters in RPM package file names and how it relates to i17n/l10n > > and file names in general. > > For the record: I care nothing for the rpm file name. The rpm file name is at the frontier. It is displayed to the user by the installer, by package tools, and it may need to be input at the command-line or in graphical apps. If the name of a package contains non-ASCII glyphs or consists solely of non-ASCII characters, there is no "name" the user can refer to. It is a serious usability regression. It also makes community support more difficult. Translation or transition is needed to turn it into something recognisable. See unreadable command file names in system scripts, e.g., would be a nightmare. > No upstream is > going to complain about the package file name. Upstreams are sensitive > to their project name, which we unfortunately map into filenames when we > generate rpms. If upstreams are "sensitive", they choose a project name which, at the implementation level, is compatible with their target group. If the underlying file-system supports UTF-8, hardly anyone would care about data files that use multi-byte characters. But the user interface is what matters. We do have policies already about using American English in spec files as opposed to British English and other languages. Package descriptions must be in US English, too, and other languages are secondary only. What would happen during package review with an application that is completely in German without any English message object files? > > I have the feeling that at first the door > > for package names with multi-byte characters is opened, and as a next > > step, file names in packages will use multi-byte characters, too. > > This ship has sailed long ago and our official policy already > explicitely allows this. In fact it goes further: filenames MUST be > UTF-8, so a latin-1 filename that goes beyond the core latin subset > common to UTF-8 and latin-1 is forbidden. Any ship can be sunk. A policy can be revisited/refined, because non-ASCII glyphs in file names are a problem in a default setup that doesn't display them correctly and that requires extra efforts to enter them. There are even characters that display as whitespace or boxes in various terminals/applications and turn into something else when using a different font: # service ŧŧŧŧ start Starting ŧŧŧŧ services: [ OK ] In xterm that name displays as white-space, in Emacs with interleaved white-space, in Sylpheed without white-space. > > One > > could also add non-English comments to spec files and source code > > and justify it with the number of non-English Fedora contributors. > > We already ship lots of code commented in other languages than English > (for example, OO.o IIRC) so this ship also sailed a long time ago. That's still only due to its Star Office history, isn't it? Proprietary code developed by the Lüneburg/Hamburg, Germany, based Star Division, and only much later open-sourced after the acquisition by Sun. Surely there are other projects, which had started with non-English comments and documentation before expanding to work with a global developer and user community and a common project language. If in the source code everything other than the reserved keywords (as defined by the programming language) is not in English, debugging and proof-reading becomes much more difficult for someone who doesn't understand the non-English words that are used. OSS projects are ill-advised if they hope for participation, but don't use an international language. > I'm quite surprised people have such an English-centric view of an > international project like Fedora. Keeping English (AE and/or BE) as the project language helps against community fragmentation. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
