Nano locale issues

DJ Lucas dj at linuxfromscratch.org
Wed Apr 12 20:50:58 PDT 2006


Alexander E. Patrakov wrote:

> Which of the following types of notes are considered stopgap solutions? 
> What's the proper place for each one in the released book (one of: the 
> main package page, Locale-Related Issues page, Wiki)?

I'm not completely up to speed on all of the locale issues.  What 
follows is my opinion only, for what I think is the right thing to do, 
without knowing a bit about how much work is involved to get this done 
before release.

IMO, we should put it all out there, right up front for everyone to see! 
  All known problematic packages should be mentioned on the Locale 
Related Issues page, including the reverse problems like ROX breakage in 
an 8-bit locale (if it were in the book).  We should warn the users 
before they get too far, only to find out that they have to change plans 
halfway through.

The local related issues page is the perfect place to put in a big 
warning before a user goes and does something that is not easily 
reversible.  It's also the place to let users know that Linux OSs in 
general, are in a state of transition but heading in the right 
direction.  A list of links to the affected packages' pages should work 
well to give users a heads up, but it should also continue to warn that 
it's not all inclusive.  "These are just the packages we know about."

Lastly, while still on the locale issues page, I'm not qualified to 
write the text, but I'd like to see some specific examples of the types 
of problems that may be seen, along with a short paragraph or two about 
the adoption of UTF-8 and it's use in other distro's as an example to 
prove (or disprove) it's future.  I can see that this page would be very 
valuable WRT education.

> 
> 1) "This package simply doesn't work in multibyte locales, don't use it 
> or downgrade to 8-bit locale. There is nothing functionally equivalent 
> in BLFS or beyond, so no other solution exists"
> 

Mention, with warning tags, immediately after the package description.

> 2) "This subcomponent of a package doesn't work correctly in multibyte 
> locales (e.g.: printing from Vim), but the rest of the package works 
> very well"
> 

Mention, with note tags, immediately after the package description.

> 3) "This package needs horrible workarounds, like post-processing the 
> output with a perl script, in order to produce the correct result"
> 

Mention, with warning tags, immediately after the package description, 
and point to the wiki for a workaround.

> 4) "This package simply doesn't work in multibyte locales, but there is 
> a nearly equivalent replacement in the book"

Mention, with note tags, immediately after the package description, and 
link to a well behaved package.

> 
> 5) "This package simply doesn't work in multibyte locales, but there is 
> a nearly equivalent replacement beyond BLFS"
> 

Mention, with note tags, immediately after the package description, and 
link to instructions in hints, wiki, or just to the package homepage if 
there isn't a complete set of instructions available (or interest/time 
to write a set).

> 6) "This package needs upgrading to a development version"
> 

Mention, with note tags, immediately after the package description.  If 
the instructions are unchanged for the development version, provide a 
link to the development version download and state that the existing 
instructions work fine, else link to the wiki with instructions (if they 
are available).

> 7) "This package needs a big patch that makes it work in both 8-bit and 
> multibyte locales"
> 
Assuming that the patch does not affect 8-bit locales, the patch should 
be put in the book unconditionally.

> 8) "This package has a patch available, but it breaks functionality in 
> 8-bit locales"

Mention, with note tags, immediately after the package description.  If 
there is no change in the build procedure, say so and link to the patch 
citing it as optional and warning that it breaks 8-bit, else point to 
the wiki (if instructions are available there).

> 
> 9) "This package needs one extra line added to its default configuration 
> file"

Again, if it doesn't affect the normal build, then it should go in 
unconditionally.  If it does affect 8-bit locales, then wrap the single 
instruction in note tags before the configure or before the make/make 
install.  If this means breaking screen tags, then it means breaking 
screen tags.

> 
> 10) [example: ROX Filer, if it were in the book] "This package authors 
> deliberately break functionality in non-UTF-8 locales. Don't use this 
> package in such locales"
> 

Mention, with warning tags, immediately after the package description.
If a patch exists to make it work in 8-bit locales, then make mention of 
it, though I doubt that this will ever be the case.

Again, I'll repeat that I'm not very well informed as to how much work 
is involved to get the above done as I've suggested.  Time permitting, 
this is how I think that BLFS should handle the locale related issues.

-- DJ Lucas



More information about the blfs-dev mailing list