Bug 545982

Summary: Hebrew release-notes are left-justified
Product: [Community] Publican Reporter: eric <eric>
Component: publicanAssignee: Jeff Fearn <jfearn>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 1.6CC: eric, jfearn, mmcallis, nb, oron, publican-list, relnotes, r.landmann, rlandman, stickster, wb8rcr
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 442642 Environment:
Last Closed: 2009-12-09 21:49:53 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 442642    

Description eric@christensenplace.us 2009-12-09 13:43:17 EST
+++ This bug was initially created as a clone of Bug #442642 +++

Description of problem:
Some languages like Hebrew and Arabic are written Right-to-Left.
The HTML generated for the release-notes (and probably any other
docs generated from the same generation system) does not contain any
related instructions and therefore everything is wrongly justified
to the left (including numbering, indentation etc.)

Version-Release number of selected component (if applicable):

How reproducible:
Generate html documentation and look at the resulting html.
Notice the numbering/bullets location and the paragraph justification.

Additional info:

1. A quick and dirty fix is to put a single line:
   direction: rtl;
   in the fedora.css generated file.
   However, this should be done conditionally on the language.
2. A similar solution was done to the fp.o website (by ricky) and
   works really good.

--- Additional comment from kwade@redhat.com on 2008-04-15 20:47:34 EDT ---

Thanks for your report.  I wasn't clear if it were sufficient to just
right-justify the text as printed.  My understanding is that the text is read
right to left.  Do the words/characters appear in the correct order but with the
incorrect left-justification?

I am putting up a build here, should be live within the hour:


We have some ideas on a more permanent fix, but that won't appear until after
Fedora 9 is released; the better fixes might appear in a package update, for

Some questions then:

* Text that appears in a block representing what you seen on the screen of a
terminal (marked <screen> in the XML), should that be LTR or RTL?
  - The CSS fix makes those RTL

* Anything else that would remain LTR?  With or without characters reversed?

Thanks. :)

--- Additional comment from stickster@gmail.com on 2008-04-15 21:35:08 EDT ---

Doing this in CSS is not the right way to fix this IMHO.  We should do it with
an XSL fragment, because (1) there are a number of elements that need to
maintain LTR orientation, and (2) we need to fix this not just for site HTML but
for PDF too.  There's some introductory pointers at
http://www.sagehill.net/docbookxsl/Localizations.html that also refer to the
right way to do this.

In any case, I think it's unwise for us to monkey with this right before our GA
package drop.  Certainly we can look at it for the zero-day update; I might even
be able to construct something by then, but would encourage others to come up
with an XSL fragment we could put into docs-common/xsl/ that does the right thing.

--- Additional comment from oron@actcom.co.il on 2008-04-15 23:28:27 EDT ---

1. Re: comment #1 above:
   - You are correct, the original problem was indeed justification and not
     work/character order.
   - The code examples are RTL, but should indeed be LTR. In this document
     it's mostly a minor annoyance as most of them are one-liners, comparing
     with big paragraphs, bullets, etc. in the majority of text.

2. A (very simplified) explanation about ordering:
   - The order is generally OK because of the UNICODE implicit BiDi
     (bidirectional) algorithm.
     E.g: Normal ASCII is LTR, while Hebrew characters are RTL. So even if a
          sentence is mixing the two languages it's usually OK.
     When we have neutral characters (e.g: '-') their directionality depends
     on the surrounding characters.
     E.g: we would expect to have '-9' with '-' to the left of '9' even in
          a Hebrew paragraph (so its order is "reversed" in comparison with
          the paragraph) while the same character hyphenating two Hebrew words
          should preserve its original order.
   - Ordering glitches happen when the implicit BiDi heuristics are not good
     enough. E.g: we have several neutral characters separating Hebrew and
     English words...to which direction should they drift?
   - In these cases, the translator may insert (in UTF-8) special UNICODE
     characters that are used to explicitly mark LTR/RTL segments within the
     text [I used it on some translations to correct minor problems, but not
     yet in the release-notes].

3. Re: comment #2 above:
   - I agree it's better to do it right even if it takes longer to complete.
   - I was probably over-optimistic, because last week, ricky managed to
     help me have an RTL fix for fp.o website (I had a quick and dirty CSS
     solution and he helped me debug, test, and cleaned it up later). So we
     had in about an hour a very nice Hebrew site (including navigation
     bars, mirrored-arrow-icons, etc.) and when it was done, Arabic was
     good also... two for the price of one ;-)
   - I looked into the sagehill pointer. While it's a very nice ref. material
     their xsl fragment work by embedding the whole <html> document into a
     single template. This looks very different than our current xml structure.
     Since I'm far from XSL guru, if someone else can prototype just a single
     XSL snippet to fix only the toplevel direction (similar to my crude css),
     than I think I can continue from there and add the other snippets needed
     to LTR/RTL different element types.
   - Having some solution for zero-day update (even if it justifies correctly
     only 90% of the text) would be very good and a lot better than having 90%
     of the text with wrong justification.
   - If we don't have any solution for zero-day update, it may be better to
     totally skip Hebrew in the release-notes (for the time being) as it
     makes a really bad impression when everything is left justified.
     A later fix will still be valuable for anybody (almost everybody?) who
     read the release-notes via the web (although we would loose the "buzz"
     of the release date).

--- Additional comment from stickster@gmail.com on 2008-09-25 07:58:58 EDT ---

Now that we're moving to publican for the release notes and IG, have you tried building either in Hebrew to see the results?  If it comes out wrong still, we should probably reassign this bug to publican.

--- Additional comment from eric@christensenplace.us on 2009-06-04 13:26:52 EDT ---

Is this still an issue in the F11 Release Notes?

--- Additional comment from oron@actcom.co.il on 2009-06-04 16:04:41 EDT ---

Yes, nothing changed. In:

You can see few titles in Hebrew (left from my failed attempt during F9).
They are left justified, just like the rest of the document.

Does publican contain any support for LTR languages?
If the basic facility exist, I'll be happy to apply the relevant
changes and test them. This way we may have something ready for F12
(which would benefit Arabic and Farsi as well).

--- Additional comment from eric@christensenplace.us on 2009-06-04 16:51:24 EDT ---

I'm CCing Jeff who handles Publican.  Maybe he can help us with seeing if this is something that can be fixed.

--- Additional comment from jfearn@redhat.com on 2009-06-04 18:39:38 EDT ---

rtl was addressed in https://bugzilla.redhat.com/show_bug.cgi?id=486162 with patches from Muayyad Alsadi.

Fixing this for Hebrew would require Hebrew being added to publican and publican-fedora, translating the new po files, and copying the css file:


to the new Hebrew common content.

Rudi has been managing this kind of effort and is CC on this bug.

AIUI there has been little effort in DocBook to get RTL working in PDF, so this only affects HTML output.

--- Additional comment from oron@actcom.co.il on 2009-06-06 06:49:23 EDT ---

Created an attachment (id=346746)
Hebrew translation of Feedback.po

Hebrew translation of Feedback.po
After adding he-IL, it would be possible to
commit it directly via Transifex.

--- Additional comment from oron@actcom.co.il on 2009-06-06 06:50:24 EDT ---

Created an attachment (id=346747)
Hebrew translation of Conventions.po

--- Additional comment from rlandman@redhat.com on 2009-06-08 18:15:32 EDT ---

Created an attachment (id=346939)
Conventions.xml in Hebrew, made from submitted po file

--- Additional comment from rlandman@redhat.com on 2009-06-08 18:17:29 EDT ---

Created an attachment (id=346940)
Feedback.xml in Hebrew, made from submitted po file

Thanks Oron for your fast action on this! I've checked your translations into the Publican repo. The version of Transifex currently in use by the Fedora Project (0.5) does not support multiple PO files for the one module, but this will be fixed when the Fedora Project upgrades to version 0.6 sometime soon.

Until Hebrew support makes it into a released version of Publican, you can manually add Hebrew the way that Jeff outlined in #8:

1. create a publican/Common_Content/common/he-IL directory
2. copy the publican/Common_Content/common/ar-AR/css directory into the he-IL directory. The css directory should contain two files: default.css and lang.css
3. place the Conventions.xml file attached here into the publican/Common_Content/common/he-IL directory
4. create a publican/Common_Content/fedora/he-IL directory
5. place the Conventions.xml file attached here into the publican/Common_Content/common/he-IL directory

Output looks like: http://rlandmann.fedorapeople.org/Common_Content/he.html

--- Additional comment from eric@christensenplace.us on 2009-12-09 12:39:41 EDT ---

Is this still an issue?  Can we point this to Publican for remedy?  Can we put the block on F13's release notes?
Comment 1 Ruediger Landmann 2009-12-09 21:49:53 EST
This has been fixed in Publican for some time -- note, for example, the F-11 release notes http://docs.fedoraproject.org/release-notes/f11/he-IL/

Rebuilding any document that displays this bug with a current version of Publican will have the correct text direction in HTML output.