Last Comment Bug 53012 - <ol style="list-style-type: hebrew;"><li> Hebrew counting should avoid various numbers
: <ol style="list-style-type: hebrew;"><li> Hebrew counting should avoid variou...
: css2
Product: Core
Classification: Components
Component: Layout: Text (show other bugs)
: Trunk
: All All
P3 normal with 1 vote (vote)
: Future
Assigned To: Simon Montagu :smontagu
Depends on:
  Show dependency treegraph
Reported: 2000-09-17 23:39 PDT by timeless
Modified: 2008-07-31 02:33 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image timeless 2000-09-17 23:39:22 PDT
15, 16, 115, 116, 215, 216, 270, 272, 275, 304, 309, 315, 316.
The testcase is
from bug 44709.

Current status: x15, and x16 where x=0..3 are handled correctly. - kudos
The others [which are at least obscure :-) ] do not seem to be handled.

[For convenience and in the event the page changes] from the reference url:
The numbers 270, 272, 275, 304 and 309 are also numbers which are not written 
in the normal pattern, because the normal pattern would spell a word with 
negative connotations. 270 and 275 would normally be spelled raysh ayin and 
raysh ayin hey. These spell ra and ra'ah, both of which mean "bad". 272 would 
normally be spelled resh ayin bet which spells ra'av meaning "famine." 304 
would normally be spelled shin dalet which spells shaid meaning "demon." 309 
would normally be spelled shin tet which spells shat meaning "to go astray." 
Since the normal way to write these numbers spells words with negative 
connotations, these numbers are written in reverse order.

as of my 9/15-08 w32-talkback build we still don't default to including bidi 
which is necessary for these bugs to be seen correctly (instead you see them 
backwards which is I think the recommended output for these outliers), although 
we could and should fix them now...
Comment 1 User image Nisheeth Ranjan 2000-09-25 17:24:57 PDT
Re-assigning 7 bugs from Clayton's list to myself for triage...
Comment 2 User image Nisheeth Ranjan 2000-09-28 17:03:36 PDT
Marking future and re-assigning to the layout team's manager, Chris Karnaze.
Comment 3 User image karnaze (gone) 2000-09-28 17:36:15 PDT
Reassinging to Buster.
Comment 4 User image Simon Montagu :smontagu 2000-10-12 00:26:08 PDT
Reversing the order of numbers with "negative connotations" is not standard 
practice in Hebrew, and I have only seen it done in specifically religious 
contexts. I think this should be set to INVALID.

There are some other problems with Hebrew numbering (especially on a platform 
with Hebrew support) which will be fixed when the IBMBIDI code is checked in.
Comment 5 User image Hixie (not reading bugmail) 2001-01-29 10:15:33 PST
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
Comment 6 User image bsharma 2001-03-02 12:39:25 PST
qa contact updated.
Comment 7 User image Frank Tang 2001-05-17 18:02:25 PDT
I made the origional list-style-type: hebrew algorithm. See the "The Hebrew 
Numbering System" section for details.
Comment 8 User image Frank Tang 2001-05-21 06:03:51 PDT
assign future
Comment 9 User image Frank Tang 2001-07-18 12:17:07 PDT
reassign to
Comment 10 User image Zach Lipton [:zach] 2001-08-25 18:10:45 PDT
Mass-move all BiDi Hebrew and Arabic qa to me, 
Thank you Gilad for your service to this component, and best of luck to you 
in the future.

Comment 11 User image timeless 2002-03-04 15:31:21 PST
afaik using hebrew numbers > 100 is hardly standard practice anywhere, which doesn't leave many consumers. in my amused opinion the major consumers would be either people like me (ie those seeking amusement) or those intent on using the numbers for something akin to religious purposes.
Comment 12 User image Simon Montagu :smontagu 2002-03-04 17:00:23 PST
For comment 4 I based myself on some Hebrew books that used Hebrew digits for
the page numbers (the Koren edition of the Bible and (IIRC) the Shocken edition
of the complete works of Agnon). These both use the normal order for all numbers.

Where I have seen the reordering is in the paragraph numbers of various editions
of the Shulhan Aruch, Also in the names of years: e.g. 5698 (1937-8) was not
usually written as taf resh tzadi het, meaning "murder". However I hardly ever
saw reordering of 5744 (1983-4) from taf shin mem dalet, meaning "destroy".
Comment 13 User image Hixie (not reading bugmail) 2002-09-16 06:27:49 PDT
So what do we want to do here? Is this INVALID? Should we even bother with the
reordering of 15 and 16? I'd love to know what we want to do here since whatever
we do is what I intend to put in the CSS3 lists module as the official way of
doing hebrew list numbering...
Comment 14 User image Shoshannah Forbes 2002-09-17 07:59:44 PDT
I have never seen in any place that uses Hebrew numbering yod he and yod vav
used, but always tet zayin and yod zain (both as stand alone and as part of a
larger number).
So we should defininatly follow here.
Other "forbidden" combinations I have seen in use, albit rarely- so we do have
some slack here.
Comment 15 User image Simon Montagu :smontagu 2002-09-17 13:52:44 PDT
For the purposes of a spec I would say that x15 and x16 SHOULD be expressed as
x+9+6 and x+9+7 rather than x+10+5 and x+10+6; and other numbers MAY be
reordered if desired to avoid spelling out words with negative connotations.

For the purposes of Mozilla, if anyone wants to write code to implement the
reordering, they are welcome to, but I don't personally consider it a priority.
Comment 16 User image Hixie (not reading bugmail) 2002-09-18 01:25:06 PDT
Ok, cool. Thanks for the help!
Comment 17 User image Ilya Konstantinov 2004-08-28 21:53:03 PDT
It's about time this one disappeared off our radar. 
Comment 18 User image timeless 2004-08-29 12:23:42 PDT
this bug isn't invalid. if you feel it worksfor you then resolve it as such.
Comment 19 User image Anne (:annevk) 2004-09-13 01:00:33 PDT
Comment 20 User image timeless 2004-09-13 12:24:04 PDT
for the record it seems like the old url with the relevant information is gone
as the domain is for sale. note to self: use the "Create a New Attachment" link :(

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