Locale Related Issues

[Randy McMurchy]

On the 'Locale Related Issues' page there is some text that needs to be cleaned up in the opening paragraph. This ticket is just a reminder to do it. Some suggested text can be found here: ​http://linuxfromscratch.org/pipermail/blfs-dev/2006-May/015270.html

[dnicholson@…]

Alexander and I had a conversation about changing this page considerably. Here's what Alexander proposed to me originally.

Hello Dan,

The following Wiki pages are ready for inclusion in the book as warnings
(if not, criticism and questions are welcome):

http://wiki.linuxfromscratch.org/blfs/wiki/LinksBrowser
http://wiki.linuxfromscratch.org/blfs/wiki/A2PS
http://wiki.linuxfromscratch.org/blfs/wiki/Enscript

These all programs, and unpatched cdrtools BTW, fall into the common
heading "Can't configure the program to accept UTF-8, because it is not
in the list of valid options" (but really because the support is not
there). I think it would be a good idea to describe this common class of
problems as a class, not only as a collection of individual issues on
the BLFS "locale issues" page. Do you agree with this plan?

In my mind, the way these issues should be handled is like this:

1. Locale Related Issues page is changed to describe general problems like the "class" Alexander has described above. Mention that specific packages will have a warning that there are issues in certain locales.

2. Add warning/note boxes to the affected pages. I messed around with an xinclude, but it might be too simple.

3. If the fix can be concisely described and worked around, add it onto the page. Something that I consider concise to be the cdrtools patches or the links warning to use a different browser. More involved work arounds, like for Enscript would live on the Wiki and be pointed out in the warning box. This criteria probably needs a stronger definition.

Basically, I want it to be easy for Alexander or whoever to ping the list and say "Package A doesn't work because ... There's info on the Wiki." Then any editor can add the warning/note box and decide whether to include the fix on the page or leave it on the Wiki. Ideally, we should push to get as many fixes into the book as possible before 6.2.

Comments, please.

[dnicholson@…]

See my crappy attempt at an xinclude and the rendered book here:

​http://anduin.linuxfromscratch.org/~dnicholson/locale-warning.diff
​http://anduin.linuxfromscratch.org/~dnicholson/blfs-book-xsl/pst/ps.html#a2ps

[Randy McMurchy]

I'm really not qualified to comment as I use a native English locale which doesn't exhibit any issues, but the note on the a2ps page seems easy enough.

However, more importantly, this issue needs to be discussed on the -dev list (list geared to discussion of book development). We can't expect non-Editors to subscribe to -book, nor review the Trac bugs.

[alexander@…]

As for "more involved workarounds" on Enscript and A2PS pages, I would accept this wording plus a link to the Wiki instead of all the complexity:

This package accepts only a few input encodings. UTF-8 is not in the list of accepted encodings.
If you need to convert UTF-8 documents to PostScript, use PAPS instead. Convert documents in other unsupported encodings to UTF-8 and feed them to PAPS, too.

However, if Randy thinks that he can handle the original notes on A2PS page, he is welcome to do so. Testcases will be supplied either via private mail, or on the list, according to his preference.

The setlocale sed on Enscript page is required in all non-English (even non-UTF-8) locales, it should be in the book (testcase: LANG=fr_FR enscript --help, see question marks instead of non-ASCII characters, e.g., in the help for the --no-header option)

Also, maybe it makes sense to drop both A2PS and Enscript packages as "dead upstream" after BLFS-6.2.

[dnicholson@…]

Revised locale related issues page using generic classes. Based on NewLocaleRelatedIssues

[dnicholson@…]

Alexander has put together a newer version of the Locale Related Issues page here. This version focuses on describing classes of issues with a few examples showing these. The previous attachment is my first crack at putting into the book.

Still needed would be the actual descriptions sitting on the specific pages since they've been greatly removed from the Locale Related Issues page.

[alexander@…]

The NewLocaleRelatedIssues page has been updated, please take a look again.

[dnicholson@…]

Next try merging Alexander's fixes

[dnicholson@…]

After lots of procrastination, I've taken another stab at implementing Alexander's changes. Please comment, if just on the text/formatting. There are still other changes necessary, mostly merging in the other fixes Alexander's put on the Wiki. This attachment just gets the ball rolling.

The locale-issues page is redone with the text on the NewLocaleRelatedIssues page + a couple edits by me. And I updated the three packages that had fixes in the old page to work with the new page.

[Ag. Hatzimanikas]

Dan,I have noticed that you put a warning in the nano page. If we go in that route,the same applies with zsh see #1845 and dillo see #1981.

With regards to zsh,there will be a new version within the next few days as stated by Clint Adams. In anycase the development zsh version it's the only way for the shell to be quite usable in a multibyte environment.

As far it goes for dillo,although I don't use it anymore,the patch that is mentioned in the dillo ticket it was good enough,last time I tried it. Plus it was recommented by Alexander in a email in blfs-dev some time ago.

[alexander@…]

The link to ticket #1845 is irrelevant, please see (wontfix) #1957 and #1825

[alexander@…]

The patch itself is OK, but the pages which say that there are "some" issues while the issues really are classified as "critical" (nano and mc) are not. Please change the wording on these pages, e.g. s/some/major/ .

[Ag. Hatzimanikas]

Thanks Alex for the correction.

With regards to #1957 there is a condradiction,with what Bruce stated in that ticket and with Dan's patch (he put a <caution> tag in the nano page).

That means either the aforementioned ticket has to be reopen or the patch can not be applied.

I believe that after many months of testing there are very few applications that don't work in an acceptable way in UTF-8 locales.

What will be the reason for someone in multibyte environment to install e.g a2ps or enscript just to realize afterwards that don't work. We can easily say:Use paps instead.

[dnicholson@…]

ACKed the s/some/major on the nano and mc pages.

As for #1957, what I'm doing write now is in direct conflict with what Bruce said in that ticket. I actually forgot about that ticket and was going to ask Alexander again about which packages had issues and add that info to the book. That's exactly what he's asking for in #1957.

So, either I'm going to do what's in #1957 given the information supplied by Alexander and Ag, or the caution tags should be removed and all the package specific information put on the Wiki. There's no reason UnZip should have preferential treatment over the other packages.

[dnicholson@…]

Two things.

1. I'm going to commit the attached -2 diff in a few hours when I get home with the suggestions from Alexander.

2. I'm going to reopen #1957 because I think it needs more discussion and it's directly conflicting with what I'm doing here.

[dnicholson@…]

Added some text suggesting the Wiki for most recent locale fixes in r6447. Following the discussion below, this ticket is being closed.

​http://linuxfromscratch.org/pipermail/blfs-dev/2007-January/016187.html