http://bugs.linuxfromscratch.org/show_bug.cgi?id=1642





------- Additional Comments From [EMAIL PROTECTED]  2005-11-10 00:43 -------
(In reply to comment #11)
> Still slightly wrong.
> 
> "The glibc-&glibc-version;/localedata/SUPPORTED lists the locales officially
> supported by the Glibc developers. Install that file...". We don't install 
> that
> file, don't say that we do.

Whoops, when you said "Leave the upper part as it is." in comment 9, that's
exactly what I did!

> Also the "official support" status means absulutely
> nothing, there's at least one non-working locale listed there (vi_VN.TCVN).
> Please revert the text before the command to its original state. The text 
> after
> the command is good.

Done.
 
> "When trying such a fix, be sure to check that Glibc supports the newly chosen
> locale too, using the tests outlined earlier in this section."
> 
> Basically you currently just say that with both old and new locale, the 
> "locale
> charmap" command should give no errors. The actual requirement is more strict:
> it should print exactly the same.

Well, that text currently caters for both Glibc and BLFS packages failing.  If
Glibc fails, you obviously *don't* want the newly chosen locale to print exactly
the same for the Glibc based locale tests!
 
> The idea is to choose a locale name that is known good for glibc and matches 
> the
> user's expectations about character map and currency. Then, in the case Xlib
> fails to recognize this locale, find something that is treated 100% 
> equivalently
> by glibc, but recognized by Xlib.

Yep, understood.
 
> Also please change:
> 
> "using a real-world example that Xlib lacks support for" -> "using a 
> real-world
> locale example that Xlib doesn't recognize"

Done.
 
> As for the modifiers, "locale -a" does show some examples that contain 
> modifiers
> such as "@euro". So the task is to explain the fact that the "@" sign and
> everything after it form a modifier.

Hmm, couldn't see a decent place to put this.
 
> "If you suffer any of the symptoms shown above" -> never happens due to glibc
> test if the reader follows the book. But let it stay as it is, because I can't
> find any better wording to introduce glibc error message.
> 
> "Due to improper locale chioce, other packages may also fail to function
> correctly, with or without outputting any error messages" -> please put this 
> to
> a separate paragraph at the bottom. Otherwise, there's no good place for me to
> add other failure modes in the UTF-8 book.

Well, I can't see a decent way to deal with any of these other points, so I'm
going to have to request you come up with a patch yourself this time, Alexander.
 I'll then review it for spelling/grammar and that it flows OK.

Regards,

Matt.



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-book
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Reply via email to