Bug 442642 - Hebrew release-notes are left-justified
Summary: Hebrew release-notes are left-justified
Alias: None
Product: Fedora Documentation
Classification: Fedora
Component: release-notes
Version: devel
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: John J. McDonough
QA Contact: Karsten Wade
Depends On: 545982
Blocks: F13RelNotesBlocker
TreeView+ depends on / blocked
Reported: 2008-04-15 23:25 UTC by Oron Peled
Modified: 2009-12-21 13:10 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 545982 (view as bug list)
Last Closed: 2009-12-21 13:10:30 UTC

Attachments (Terms of Use)
Hebrew translation of Feedback.po (2.62 KB, text/x-gettext-translation)
2009-06-06 10:49 UTC, Oron Peled
no flags Details
Hebrew translation of Conventions.po (21.37 KB, text/x-gettext-translation)
2009-06-06 10:50 UTC, Oron Peled
no flags Details
Conventions.xml in Hebrew, made from submitted po file (11.71 KB, text/xml)
2009-06-08 22:15 UTC, Ruediger Landmann
no flags Details
Feedback.xml in Hebrew, made from submitted po file (1.29 KB, text/xml)
2009-06-08 22:17 UTC, Ruediger Landmann
no flags Details

Description Oron Peled 2008-04-15 23:25:37 UTC
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.

Comment 1 Karsten Wade 2008-04-16 00:47:34 UTC
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. :)

Comment 2 Paul W. Frields 2008-04-16 01:35:08 UTC
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.

Comment 3 Oron Peled 2008-04-16 03:28:27 UTC
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).

Comment 4 Paul W. Frields 2008-09-25 11:58:58 UTC
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.

Comment 5 eric 2009-06-04 17:26:52 UTC
Is this still an issue in the F11 Release Notes?

Comment 6 Oron Peled 2009-06-04 20:04:41 UTC
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).

Comment 7 eric 2009-06-04 20:51:24 UTC
I'm CCing Jeff who handles Publican.  Maybe he can help us with seeing if this is something that can be fixed.

Comment 8 Jeff Fearn 🐞 2009-06-04 22:39:38 UTC
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.

Comment 9 Oron Peled 2009-06-06 10:49:23 UTC
Created attachment 346746 [details]
Hebrew translation of Feedback.po

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

Comment 10 Oron Peled 2009-06-06 10:50:24 UTC
Created attachment 346747 [details]
Hebrew translation of Conventions.po

Comment 11 Ruediger Landmann 2009-06-08 22:15:32 UTC
Created attachment 346939 [details]
Conventions.xml in Hebrew, made from submitted po file

Comment 12 Ruediger Landmann 2009-06-08 22:17:29 UTC
Created attachment 346940 [details]
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

Comment 13 eric 2009-12-09 17:39:41 UTC
Is this still an issue?  Can we point this to Publican for remedy?  Can we put the block on F13's release notes?

Comment 14 eric 2009-12-09 18:44:01 UTC
This ticket has been cloned and pushed to Publican.

Comment 15 Ruediger Landmann 2009-12-10 02:52:04 UTC
This has been fixed for some time in Publican; eg, the F-11 Release Notes do not display the bug. 

Correcting it for previously-published documents (for example, F-9 Release Notes) would mean rebuilding them in Publican, or just hacking the CSS manually to set the RTL text direction.

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