The "locale related issues" page in BLFS is dummy

[alexander@…]

Currently, LFS says:

UTF-8 based locales are not supported well by many programs. E.g., the watch program displays only ASCII characters in UTF-8 locales and has no such restriction in traditional 8-bit locales like en_US. Work is in progress to document and, if possible, fix such problems, see ​http://www.linuxfromscratch.org/blfs/view/svn/introduction/locale-issues.html.

However, there is no progress, and no actual work. I think that the page was a bad idea (wiki worked better), and should be removed. The link in LFS should vanish too.

[dnicholson@…]

You're probably right. I still think this could be the place for the fixes when BLFS goes to release, but we'll cross that path when we get there. This note in LFS is not accurate right now and may be completely wrong by BLFS-6.2.

Alexander, if you have commit privelages and access, could you make the change? I'm trying to look through the rest of my emails to see if there were other overlooked issues.

[alexander@…]

How about the following diff:

Index: profile.xml
===================================================================
--- profile.xml	(revision 7740)
+++ profile.xml	(working copy)
@@ -162,10 +162,26 @@
 
   <beginpage/>
 
-  <para>UTF-8 based locales are not supported well by many programs. E.g., the
-  <command>watch</command> program displays only ASCII characters in UTF-8
+  <para>UTF-8 locales will be definitely preferred in the future, but right now
+  they are not supported well by many programs. E.g., the
+  <command>watch</command> program displays only ASCII characters in such
   locales and has no such restriction in traditional 8-bit locales like en_US.
-  Work is in progress to document and, if possible, fix such problems, see
-  <ulink url="&blfs-root;view/svn/introduction/locale-issues.html"/>.</para>
+  Programs with the opposite bug do exist (e.g., Nautilus CD Burner),
+  but they are a rare exception, not the rule. For non-English speakers,
+  bugs related to non-ASCII characters are usually showstoppers.</para>
 
+  <para>The key to a working UTF-8 based system is to avoid installing
+  broken programs such as A2ps, non-Bash shells, Enscript, GTK-1.2.10
+  (in this case, the bug is actually in Xorg),
+  Ispell, Links, Midnight Commander, Nano 1.2.x. The list above is incomplete,
+  in most cases there is no fix available.
+  Also, many programs for Microsoft Windows (e.g., WinEdt) create
+  interoperability problems because they cannot process
+  UTF-8 encoded text documents correctly.
+  These problems are documented in more detail in
+  BLFS Book Notes at
+  <ulink url="http://wiki.linuxfromscratch.org/blfs/wiki/BlfsNotes"/>.
+  If you depend on any of the broken-in-UTF-8 programs and libraries,
+  don't use UTF-8 based locales.</para>
+
 </sect1>

[dnicholson@…]

I like what you've written, but I think it's too specific for LFS. Why don't we leave the text in the LFS book alone and make the text you've just written the Locale Related Issues page in BLFS?

The documentation is more logical to me in that setup.

1. You're wrapping up LFS. This base system has been well described for any issues in UTF-8 and non-UTF-8 locales. More likely than not, you can use either charset.

2. A warning comes along (like is there now) mentioning that programs installed beyond the base can have issues with either type of charset. A link is given to a page in our de facto beyond the base book, BLFS: the Locale Related Issues page.

3. This page expands the examples of broken behavior as you've written above. Further, it shows the user where to find information for particular packages: the BLFS Wiki Notes. The user should also be told here that any package with known locale related issues will have a warning at the top of their respective page.

4. Then they can go to the BLFS table of contents and look for the things they want, e.g. nano, and see what the consequences are for the kind of system they want to build.

This would require only a minor change to the text in the LFS book. I'll attach what I think is appropriate soon.

What do you think about that?

[bdubbs@…]

We can always change the BLFS page, including placing a "User Notes" link to the wiki there. The text for LFS is OK.

[dnicholson@…]

Here's what I had in mind. Just mention that both kinds of charsets have issues and point the reader to the locale-issues page in BLFS. Then fix up that page to contain the more specific info you've written and pass the user on to the BLFS Wiki Notes. I think we can assume that anyone interested will follow the links.

Bruce, I'm going to submit this small diff if it's OK with you.

Index: chapter07/profile.xml
===================================================================
--- chapter07/profile.xml       (revision 7740)
+++ chapter07/profile.xml       (working copy)
@@ -165,6 +165,9 @@
   <para>UTF-8 based locales are not supported well by many programs. E.g., the
   <command>watch</command> program displays only ASCII characters in UTF-8
   locales and has no such restriction in traditional 8-bit locales like en_US.
+  Likewise, a few programs (e.g., Nautilus CD Burner) have bugs in the
+  opposite case where they only work correctly when using a UTF-8 based locale.
+  These cases are the exception, though.
   Work is in progress to document and, if possible, fix such problems, see
   <ulink url="&blfs-root;view/svn/introduction/locale-issues.html"/>.</para>

[alexander@…]

Here I have to agree with Bruce. The new paragraph of text that Dan pasted above doesn't hurt either, but I prefer to duplicate it in BLFS.

[bdubbs@…]

I'd prefer not to put this into LFS as it is getting too specific. The specifics can be handled in BLFS or the wiki.

[alexander@…]

OK, no changes to LFS are required. But ​http://wiki.linuxfromscratch.org/blfs/ticket/1957 must be re-examined then.

[dnicholson@…]

Moving on then.

As far as the BLFS ticket, it's an ongoing game. As long as we organize correctly so that any known issues point to further discussion on the Wiki, then that's the best we can do. If you happen to see that package X has issues when using KOI8-R (or whatever), add the info to the Wiki, ping me, and I'll make sure to add a warning to its page in BLFS. That's a pretty solid fix in my mind. Better than just having something languish in the bug database.