[relnotes] [Bug 442642] Hebrew release-notes are left-justified

Wed Apr 16 03:28:28 UTC 2008

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Hebrew release-notes are left-justified

https://bugzilla.redhat.com/show_bug.cgi?id=442642

oron at actcom.co.il changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW
               Flag|needinfo?(oron at actcom.co.il)|

------- Additional Comments From oron at actcom.co.il  2008-04-15 23:28 EST -------
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).

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.