Bug 80732 - Help screens mostly empty - GUI
Summary: Help screens mostly empty - GUI
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: docbook-style-xsl (Show other bugs)
(Show other bugs)
Version: phoebe
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Mike McLean
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-12-30 15:58 UTC by Trond Eivind Glomsrød
Modified: 2007-04-18 16:49 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-07 12:56:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test xml file (326 bytes, text/plain)
2003-01-04 22:44 UTC, Jeremy Katz
no flags Details
stripped down stylesheet (465 bytes, text/plain)
2003-01-04 22:44 UTC, Jeremy Katz
no flags Details

Description Trond Eivind Glomsrød 2002-12-30 15:58:53 UTC
Most of the help text seem to go AWOL when doing GUI installs in Norwegian.

Comment 1 Bill Nottingham 2003-01-01 06:15:06 UTC
Do translations actually exist for norwegian?

Comment 2 Trond Eivind Glomsrød 2003-01-01 12:19:41 UTC
Yes, they're cut off mid-sentence so most of the content is gone. I'd guess it's
related to 8 bit chars wrt. UTF-8

Comment 3 Michael Fulbright 2003-01-02 22:53:25 UTC
Help me out - is this a rendering issue for anaconda or just bad translations?

Comment 4 Jeremy Katz 2003-01-03 00:24:53 UTC
docbook-style-xsl isn't following the specified encoding from the online.xsl
stylesheet.  In html/docbook.xsl, it has a hardcoded charset of ISO8859-1 which
is pretty bogus (and not present in 1.50.0 from 8.0)

Tim?

Comment 5 Tim Waugh 2003-01-03 09:01:11 UTC
Seems like it's been that way for ever.  1.50.0-3 has it.  I agree that it looks
suspicious.

Are you using xmlto for the conversion?  I made a change recently to do with
encodings that might be causing problems.  I can easily back that out as a quick
work-around.

Comment 6 Tim Waugh 2003-01-03 09:22:18 UTC
This seems to be a known problems with the stylesheets.  See:

http://lists.oasis-open.org/archives/docbook-apps/200301/msg00009.html


Comment 7 Jeremy Katz 2003-01-03 22:56:50 UTC
Backing down to the older docbook-style-xsl + xmlto works, but I can't just back
down xmlto due to requirements.  So I guess we need to make our own customized
output thing?

Comment 8 Tim Waugh 2003-01-03 23:03:00 UTC
Please try xmlto-0.0.12-2, which aims to restore the previous working state.

Comment 9 Jeremy Katz 2003-01-04 22:43:54 UTC
Still fails.  But, if I ignore the dep on newer docbook-style-xsl and back down
to the one we shipped in 8.0, it's fine.  Attaching a pair of simple files which
can be used to reproduce

xmlto -o test html -m test.xsl test.xml

Comment 10 Jeremy Katz 2003-01-04 22:44:28 UTC
Created attachment 89134 [details]
test xml file

Comment 11 Jeremy Katz 2003-01-04 22:44:53 UTC
Created attachment 89135 [details]
stripped down stylesheet

Comment 12 Tim Waugh 2003-01-04 23:14:26 UTC
I found that you can add:

<xsl:param name="chunker.output.encoding" select="'UTF-8'"/>

to get the right result.  I'll ask upstream why this doesn't default to
$default.encoding.

Comment 13 Jeremy Katz 2003-01-05 03:48:53 UTC
Added to the stylesheet used for the help and rebuilt with the change.  I'm
perfectly happy for now to just have something to get it working :)

Comment 14 Tim Waugh 2003-01-07 12:56:39 UTC
Apparently chunker.output.encoding is the new name, and default.encoding
shouldn't be used any more for chunking output.

Comment 15 Tim Waugh 2004-07-01 11:25:46 UTC
I'm taking out this patch in rawhide -- hopefully things have moved on
now and it won't cause problems this time.  xmlto-0.0.18-4.


Note You need to log in before you can comment on or make changes to this bug.