Red Hat Bugzilla – Bug 442642
Hebrew release-notes are left-justified
Last modified: 2009-12-21 08:10:30 EST
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):
Generate html documentation and look at the resulting html.
Notice the numbering/bullets location and the paragraph justification.
1. A quick and dirty fix is to put a single line:
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.
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
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?
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.
1. Re: comment #1 above:
- You are correct, the original problem was indeed justification and not
- 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
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).
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.
Is this still an issue in the F11 Release Notes?
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).
I'm CCing Jeff who handles Publican. Maybe he can help us with seeing if this is something that can be fixed.
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.
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.
Created attachment 346747 [details]
Hebrew translation of Conventions.po
Created attachment 346939 [details]
Conventions.xml in Hebrew, made from submitted po file
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
Is this still an issue? Can we point this to Publican for remedy? Can we put the block on F13's release notes?
This ticket has been cloned and pushed to Publican.
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.