[Bug 545982] New: Hebrew release-notes are left-justified
by Red Hat Bugzilla
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(a)redhat.com
ReportedBy: eric(a)christensenplace.us
QAContact: extras-qa(a)fedoraproject.org
CC: stickster(a)gmail.com, oron(a)actcom.co.il,
relnotes(a)fedoraproject.org, jfearn(a)redhat.com,
nb(a)fedoraproject.org, eric(a)christensenplace.us,
mmcallis(a)redhat.com, wb8rcr(a)arrl.net,
rlandman(a)redhat.com, r.landmann(a)redhat.com
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(a)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:
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(a)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(a)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(a)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(a)christensenplace.us on 2009-06-04 13:26:52 EDT
---
Is this still an issue in the F11 Release Notes?
--- Additional comment from oron(a)actcom.co.il 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(a)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(a)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:
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(a)actcom.co.il 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(a)actcom.co.il 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(a)redhat.com 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(a)redhat.com 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(a)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?
--
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.
14 years, 5 months
[Bug 546049] New: Release notes do not mention that ABRT grabs core files
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Release notes do not mention that ABRT grabs core files
https://bugzilla.redhat.com/show_bug.cgi?id=546049
Summary: Release notes do not mention that ABRT grabs core
files
Product: Fedora Documentation
Version: devel
Platform: All
URL: http://docs.fedoraproject.org/release-notes/f12/en-US/
html/sect-Release_Notes-Changes_in_Fedora_for_Desktop_
Users.html
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: release-notes
AssignedTo: relnotes(a)fedoraproject.org
ReportedBy: jjcogliati-r1(a)yahoo.com
QAContact: kwade(a)redhat.com
CC: eric(a)christensenplace.us, wb8rcr(a)arrl.net
Classification: Fedora
Description of problem:
Basically, if you are trying to debug a program, it is useful to be able to
find the core file. ABRT grabs core files and store them in /var/cache/abrt
The release notes make no mention of this.
Version-Release number of selected component (if applicable):
0.11 Fri 20 Nov 2009 John McDonough
How reproducible:
Very.
Steps to Reproduce:
1. Create a program that causes a seg fault.
2. Compile program.
3. Run program.
4. Read Segmentation fault (core dumped)
5. Look for core dump. Hm. Not in current directory.
6. Look at release notes.
Actual results:
4.1.3. ABRT
The ABRT automatic bug reporting tool replaces bug-buddy and kerneloops in the
Fedora 12 desktop. ABRT has an extensible architecture and can not only catch
and report segmentation faults and kernel oops, but also python backtraces. In
contrast to bug-buddy, it can catch segmentation faults in any binary, not just
GTK+ applications.
If you have manually modified the GConf settings for the bug-buddy GTK+ module
before, you may see warning messages like the following from GTK+ applications:
Gtk-Message: Failed to load module "gnomebreakpad":
libgnomebreakpad.so: cannot open shared object file: No such file or directory
To stop these messages, run the following command in a terminal in your
session:
gconftool-2 --type bool --set
/apps/gnome_settings_daemon/gtk-modules/gnomebreakpad false
Expected results:
4.1.3. ABRT
The ABRT automatic bug reporting tool replaces bug-buddy and kerneloops in the
Fedora 12 desktop. ABRT has an extensible architecture and can not only catch
and report segmentation faults and kernel oops, but also python backtraces. In
contrast to bug-buddy, it can catch segmentation faults in any binary, not just
GTK+ applications.
If you have manually modified the GConf settings for the bug-buddy GTK+ module
before, you may see warning messages like the following from GTK+ applications:
Gtk-Message: Failed to load module "gnomebreakpad":
libgnomebreakpad.so: cannot open shared object file: No such file or directory
To stop these messages, run the following command in a terminal in your
session:
gconftool-2 --type bool --set
/apps/gnome_settings_daemon/gtk-modules/gnomebreakpad false
The ABRT tool captures debug information (including coredumps) in the directory
/var/cache/abrt.
Additional info:
This may arguably be a bug in ABRT as well since a coredump from a non-system
executable (i.e. something where rpm -qf ../foo reports
file /home/username/foo is not owned by any package) is not something that
should be ABRT should be doing anything special with.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
14 years, 5 months
[Bug 500474] New: F12DocsTarget
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: F12DocsTarget
https://bugzilla.redhat.com/show_bug.cgi?id=500474
Summary: F12DocsTarget
Product: Fedora Documentation
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: urgent
Priority: low
Component: release-notes
AssignedTo: relnotes(a)fedoraproject.org
ReportedBy: eric(a)christensenplace.us
QAContact: kwade(a)redhat.com
CC: wb8rcr(a)arrl.net
Classification: Fedora
This is a blocker to all issues regarding the F12 Release Notes.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
14 years, 5 months
