Re: [counter-styles] i18n-ISSUE-285: Hebrew number converter inadequate for numbers >= 1000

On Wed, Oct 30, 2013 at 3:41 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>
> The Hebrew system was originally defined this way, as a custom system,
> as it can't be reasonably represented in the current algorithms the
> way you describe.  I was told by another Hebrew speaker (Aryeh Gregor)
> that the form the spec currently specifies, with repeated tavs, is
> acceptable.

I don't recall what exactly I said in the past, but to clarify: the
form currently specified is fine for any sane list, since it works
fine up to 1000.  It's also fine even for numbers that go somewhat
beyond that point, such as page numbers in long books -- just a few
days ago I saw a page number in a book that was something like תתתרחצ
(‎= 1498).  I think this is probably what the CSS spec's numbering
system will be used for, so I do think it's acceptable.  (I wouldn't
even call א'תצח correct for 1498 as a page number.  I've never seen
that convention used for page numbering.)

The system described by the spec is not acceptable for encoding
arbitrary numbers in arbitrary contexts, but there are other problems
with that anyway.  For instance, a number in running text has an extra
geresh (single apostrophe) or gershayyim (double apostrophe) inserted,
like כ"ו for 26 and נ'‏ for 50.  Only in a context like a page number
or list number where a number is the only expected thing do you drop
the geresh/gershayyim -- otherwise the extra mark is needed to alert
you to the fact that it's a number and not a word.  Also, the
convention for year numbers (the most common large numbers you find)
is most often to drop the thousands place entirely, so 5776 is
typically תשע"ד rather than ה'תשעד, except in historical contexts that
actually go back to the 4000s.

So the spec does not deal with Hebrew numbering perfectly, but I think
it's perfectly reasonable for the intended use-cases.  A one-line note
might be worth adding so people are aware this has been considered.

Received on Wednesday, 30 October 2013 11:50:52 UTC