Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Hebrew release-notes are left-justified https://bugzilla.redhat.com/show_bug.cgi?id=545982 Summary: Hebrew release-notes are left-justified Product: Fedora Version: 12 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: publican AssignedTo: jfearn@xxxxxxxxxx ReportedBy: eric@xxxxxxxxxxxxxxxxxxx QAContact: extras-qa@xxxxxxxxxxxxxxxxx CC: stickster@xxxxxxxxx, oron@xxxxxxxxxxxx, relnotes@xxxxxxxxxxxxxxxxx, jfearn@xxxxxxxxxx, nb@xxxxxxxxxxxxxxxxx, eric@xxxxxxxxxxxxxxxxxxx, mmcallis@xxxxxxxxxx, wb8rcr@xxxxxxxx, rlandman@xxxxxxxxxx, r.landmann@xxxxxxxxxx Blocks: 442642 Classification: Fedora Clone Of: 442642 +++ 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): Fedora-9 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@xxxxxxxxxx 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: http://docs.fedoraproject.org/release-notes/f9preview/he/ 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 example. 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@xxxxxxxxx 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@xxxxxxxxxxxx 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@xxxxxxxxx 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@xxxxxxxxxxxxxxxxxxx on 2009-06-04 13:26:52 EDT --- Is this still an issue in the F11 Release Notes? --- Additional comment from oron@xxxxxxxxxxxx on 2009-06-04 16:04:41 EDT --- Yes, nothing changed. In: http://docs.fedoraproject.org/release-notes/f11/he-IL/ 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@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxx 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: publican/content/common/ar-AR/css/lang.css 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@xxxxxxxxxxxx on 2009-06-06 06:49:23 EDT --- Created an attachment (id=346746) --> (https://bugzilla.redhat.com/attachment.cgi?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@xxxxxxxxxxxx on 2009-06-06 06:50:24 EDT --- Created an attachment (id=346747) --> (https://bugzilla.redhat.com/attachment.cgi?id=346747) Hebrew translation of Conventions.po --- Additional comment from rlandman@xxxxxxxxxx on 2009-06-08 18:15:32 EDT --- Created an attachment (id=346939) --> (https://bugzilla.redhat.com/attachment.cgi?id=346939) Conventions.xml in Hebrew, made from submitted po file --- Additional comment from rlandman@xxxxxxxxxx on 2009-06-08 18:17:29 EDT --- Created an attachment (id=346940) --> (https://bugzilla.redhat.com/attachment.cgi?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@xxxxxxxxxxxxxxxxxxx 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? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. -- Fedora-relnotes-content mailing list Fedora-relnotes-content@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-relnotes-content
