Le mardi 16 décembre 2008 à 22:02 +0200, Nikolay Vladimirov a écrit : > 2008/12/16 Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx>: > > Le mardi 16 décembre 2008 à 20:38 +0200, Nikolay Vladimirov a écrit : > > > >> >> > Currently, I'm opposed to having a Guideline that mandates UTF-8 over ASCII. > >> +1 > >> > >> It's not piles of quirks it's a simple parser. > > > > ROTFL. Sorry. > > uh? > It's a development discussion forum if you think I said something > stupid or plain braindamadge. Explain why it's stupid. Don't ROTFL and > stuff, please. There are not enough hours in my free time to expand on all the problems trying to work around 7-bit encoding limitations without going Unicode causes. There is abundant literature about it (both in paper and digital form). It's all “simple” problems with “easy” solutions and when you pile up all the resulting quirks you put the Egyptians pyramids to shame. As a bonus this stuff is highly non-standard and incompatible by contruction. So when you claim this is a “simple” problem-space I'll ROTFL. Better people than you and me hit a wall trying to solve it properly. In the end after many failures they wrote the Unicode standard. > >> Take wiki syntax for example. All wikis(i know) rely on simple syntax > >> that uses ASCII characters to display somewhat structured and > >> formatted content. > > > > Wiki support UTF-8 just fine > > yes. i ment the actual syntax like it uses "*" to mark unordered list > but it displays "unicode bullet" ( i can't find it on my layout) > Like it detects depth with ident and replaces '*' to look nicely. You are free to write specs using wiki, tex, or sgml entities markup. You are free to use a text editor, a word processor, an hexadecimal, or whatever. We expect you to convert this syntax to correct plain text in UTF-8 encoding before publication by Fedora. This is the common ground all our package manipulating tools understand and there is no way we're going to teach them some other markup just because you can't find some UTF-8 symbol in your layout. If you can't write UTF-8 bullets, and can't be bothered to launch something like gucharmap, use a sed of awk or whatever converter on your spec files before pushing them Fedora-side, don't ask others to add code to many tools to workaround your problems. > >> And it's common to use "*" to mark unordered list. > > > > And it's common to use xml tags and all kinds of other stuff but that's > > irrelevant because spec syntax is plain text not wiki markup. > > > > I'm not talking about syntax in specs, The discussion is about the human text found in spec files. > So if i'm using some really outdated client to connect to my fedora > host ( like telnet or serial or something) > And I use command-line tools to browse packages and read summaries I > will not see these UTF symbols. So what? Your choice. The distro English encoding is UTF-8. If you want things to work perfectly in the default locale use UTF-8 aware tools. We can't be responsible for your choice to use buggy, legacy, outdated tools. Any ASCII-oriented tool will mostly sort-of work, and anything outside the mostly sort-of perimeter is the price you pay for using limited tools. If you want an ASCII-only mode (a real one, not the “I know it's UTF-8 but please use only ASCII so I don't hit bugs in my tools”) open an English ASCII localization group. > As I understand the problem is that PackageKit can't display stuff. The problem is people wrote garbage in some spec files using ASCII-limited tools, and the PK maintainer would like this garbage corrected so normal users are not exposed to ASCII quirks. > So > let's make stuff more standard and leave PackageKit to do all the > friendly displaying. PK is not the only tool involved, the standard already exists, and is feature-complete without needing workaround code. > >> And also different languages have different types of quotes for > >> example in Bulgarian the quoted text looks like this : ,, quote " . > > > > Converting text to the appropriate typography rules and symbols is part > > of the job of the translator (just like applying the correct grammar and > > syntax ordering rules). Translating has never been limited to > > word-by-word conversion. > > > > Yes. But why do I have to do all the stuff when a machine can do it. If a machine can do it get a machine to output proper UTF-8 encoded specfile text your side. > It is representation since the encoding will be changed The encoding won't be changed > mainly because > in the current summaries don't look so great Because they have mistakes. Their authors just have to correct their mistakes. This is no different from grammar errors and you don't expect PK to fix the text grammar errors don't you? > and are pretty chaotic in > style. Using UTF isn't going to make them more structured and > standard. Maintainers will. Which is the whole point. This is not a technical problem. The current UTF-8 technical infrastructure is sufficient and there is not need to write magic text correcting code. People just have to do some editorial work and proof and correct their text themselves, making sure it displays fine using simple standard UTF-8 text rendering engines. -- Nicolas Mailhot
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
