Bug Hunting Session
Bug 66212 - Hebrew Numbering incorrect above value ten (seeing Kaf instead of Yod Aleph)
Summary: Hebrew Numbering incorrect above value ten (seeing Kaf instead of Yod Aleph)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Localization (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: yossi zahn
URL:
Whiteboard: target:5.4.0 target:6.0.0
Keywords:
Depends on:
Blocks: RTL-Hebrew Numbering-Formats
  Show dependency treegraph
 
Reported: 2013-06-26 16:01 UTC by Boruch Baum
Modified: 2018-10-17 13:25 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Boruch Baum 2013-06-26 16:01:10 UTC
The Hebrew numbering system uses letters of the Hebrew alphabet. Libreoffice offers an option to use this system, but incorrectly assigns values above ten.

Ten is the letter 'yod' = "י". Done correctly by Libreoffice.

Eleven should be the two letter combination 'yod aleph' = "יא". However, Libreoffice incorrectly jumps to the next single letter of the Hebrew alphabet, 'chof' = "כ".

See the wikipedia article for 'Gematria'. You want to be using the method described there as 'Mispar Hechrachi'. The article includes a 'values table' for letters - you want to limit yourself to the first 22 letters only.
Comment 1 Boruch Baum 2013-06-27 15:01:57 UTC
Here's a code snippet, written in C and taken from libhdate (hdate_strings.c, function hdate_strings), that should solve the bug:

#define H_CHAR_WIDTH 2
static char *digits[3][10] = {
	{" ", "א", "ב", "ג", "ד", "ה", "ו", "ז", "ח", "ט"},
	{"ט", "י", "כ", "ל", "מ", "נ", "ס", "ע", "פ", "צ"},
	{" ", "ק", "ר", "ש", "ת"}

if ((index > 0) && (index < 11000))
{
	/// HEBREW_NUMBER_BUFFER_SIZE 17	defined in hdate.h
	return_string = malloc(HEBREW_NUMBER_BUFFER_SIZE);
	if (return_string == NULL) return NULL;
	return_string[0] = '\0';
	int n = index;
	if (n >= 1000)
	{
		strncat (return_string, digits[0][n / 1000], H_CHAR_WIDTH);
		n %= 1000;
	}
	while (n >= 400)
	{
		strncat (return_string, digits[2][4], H_CHAR_WIDTH);
		n -= 400;
	}
	if (n >= 100)
	{
		strncat (return_string, digits[2][n / 100], H_CHAR_WIDTH);
		n %= 100;
	}
	if (n >= 10)
	{
		if (n == 15 || n == 16)
			n -= 9;
		strncat (return_string, digits[1][n / 10], H_CHAR_WIDTH);
		n %= 10;
	}
	if (n > 0)
		strncat (return_string, digits[0][n], H_CHAR_WIDTH);
		
 	/// possibly add the ' and " to hebrew numbers	
	if (!short_form)
	{
		return_string_len = strlen (return_string);
		if (return_string_len <= H_CHAR_WIDTH) strncat (return_string, "'", H_CHAR_WIDTH);
		else
		{
			return_string[return_string_len + 1] = return_string[return_string_len];
			return_string[return_string_len] = return_string[return_string_len - 1];
			return_string[return_string_len - 1] = return_string[return_string_len - 2];
			return_string[return_string_len - 2] = '\"';
			return_string[return_string_len + 2] = '\0';
		}
	}
	return return_string;
Comment 2 Maxim Monastirsky 2013-08-01 08:53:46 UTC
You should choose "Native Numbering" instead of "א ב ג".
Comment 3 Boruch Baum 2013-08-01 15:41:39 UTC
(In reply to comment #2)
> You should choose "Native Numbering" instead of "א ב ג".

Two responses:

1] Your suggestion doesn't work. Maybe 'native numbering' uses the default WESTERN language set in the libreoffice default, and Hebrew is set in the CTL section.

2] Even were your suggestion to work, it would not close this bug, because having the eleventh letter of the Hebrew alphabet follow the tenth one makes no sense to any Hebrew speaker in any listing or counting context. In Hebrew, letters ARE numerals, and have always been numerals, so when a Hebrew speaker sees the tenth letter of the Hebrew alphabet, she thinks the number 'ten', and when she sees the eleventh letter, see thinks the number 'twenty'.
Comment 4 Maxim Monastirsky 2013-08-04 06:39:35 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > You should choose "Native Numbering" instead of "א ב ג".
> 
> Two responses:
> 
> 1] Your suggestion doesn't work. Maybe 'native numbering' uses the default
> WESTERN language set in the libreoffice default, and Hebrew is set in the
> CTL section.
> 
In order to make it work, you should go to Tools->Options..->Language Settings->Languages and change the "Locale setting" field to "Hebrew". It works for me.

> 2] Even were your suggestion to work, it would not close this bug, because
> having the eleventh letter of the Hebrew alphabet follow the tenth one makes
> no sense to any Hebrew speaker in any listing or counting context. In
> Hebrew, letters ARE numerals, and have always been numerals, so when a
> Hebrew speaker sees the tenth letter of the Hebrew alphabet, she thinks the
> number 'ten', and when she sees the eleventh letter, see thinks the number
> 'twenty'.
OK got it.
Comment 5 Maxim Monastirsky 2013-08-11 14:07:31 UTC
Changing status to 'NEW', as the current behaviour is completely wrong. See comment #3 and Wikipedia article about 'Hebrew numerals' for more details. The Item 'א ב ג' should act the same as 'Native Numbering'+Hebrew locale.

Also I'm lowering the severity, as users can get the right behaviour using 'Native Numbering'+Hebrew locale (although it's not easily discoverable).
Comment 6 QA Administrators 2015-04-01 14:42:20 UTC Comment hidden (obsolete, spam)
Comment 7 tommy27 2016-04-16 07:28:32 UTC Comment hidden (obsolete, spam)
Comment 8 Eyal Rozenberg 2016-08-14 20:13:14 UTC
(In reply to tommy27 from comment #7)
Bug still manifests in the release version used in Ubunutu 16.04 at the moment (5.1.4.2).

This should actually not be incredibly hard to fix, so if any developer is checking this page out - try devoting 15 minutes to doing this (i.e. changing the Hebrew numerals behavior to be the same as Default numerals + Hebrew locale).

Anyway, about the workaround and the importance setting: While it does work, it has two issues

1. It is not at all obvious, and involves changing settings at two different and UI-far places. I would probably not have guessed it even given some time.
2. Some people have non-Hebrew locales, and should still see Hebrew documents rendered properly.

So, I'm upping the severity to normal.
Comment 9 Eike Rathke 2016-12-08 17:05:40 UTC
The current Hebrew numbering is an alphabet character numbering like A,B,C,...
This is not a bug but just what was implemented upon request.

What is requested instead indeed seems to be the Native Numbering in a Hebrew locale that is also available in the number formatter with [NatNum1]0 in a Hebrew locale. Just being available as a fixed numbering and not depending on the current work locale.

I'm setting this to enhancement because an additional numbering is actually what is needed.
Comment 10 Boruch Baum 2016-12-08 21:32:51 UTC
(In reply to Eike Rathke from comment #9)
> The current Hebrew numbering is an alphabet character numbering like
> A,B,C,...
> This is not a bug but just what was implemented upon request.
> 
> What is requested instead indeed seems to be the Native Numbering in a
> Hebrew locale that is also available in the number formatter with [NatNum1]0
> in a Hebrew locale. Just being available as a fixed numbering and not
> depending on the current work locale.

Please read the thread before adding to it and before changing things. Everything you wrote is wrong.

My guess is that the basis for your error is that you think that a language / localization is just a different set of words and unicode characters.

But it isn't.

Different languages -do- things differently.

And, for Hebrew, what you're suggesting makes no sense at all. You're taking an English-style cultural convention and imposing it on a Jewish one, and it doesn't work.

> I'm setting this to enhancement because an additional numbering is actually
> what is needed.

Kindly revert. You're action was misguided. Please read the prior comments on this thread and consult with native speakers of the language before jumping into the fray.

As for this bug being inherited from Ooo, I'll take it on good faith that you researched that to be the case, but the bug was discovered in LibreOffice 5.1.4.2 release and reported against that version.
Comment 11 Eike Rathke 2016-12-09 12:36:49 UTC
You may have discovered the behavior in 5.1.4, but the Hebrew Alphabet numbering was implemented since OOo, see https://bz.apache.org/ooo/show_bug.cgi?id=17516 and related the Hebrew Number numbering https://bz.apache.org/ooo/show_bug.cgi?id=23372

Don't tell me everything I wrote is wrong, I did research. You want the NatNum1 (and maybe even NatNum2) numbering being explicitly available as outline numbering.
Comment 12 Commit Notification 2016-12-13 18:25:24 UTC
Yossi Zahn committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=08fb6d73f8c22d98ab806dd93f4afe3f78b4ff83

tdf#66212 - Add Hebrew NATNUM1 to numbering-format menus.

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Xisco Faulí 2017-03-01 11:12:07 UTC
Hello,
Is this bug fixed?
If so, could you please close it as RESOLVED FIXED?
Comment 14 yossi zahn 2017-03-01 21:42:15 UTC
The original complaint is fixed via http://cgit.freedesktop.org/libreoffice/core/commit/?id=08fb6d73f8c22d98ab806dd93f4afe3f78b4ff83
I still would like to add support for Hebrew numbering in the rtf and doc/docx filters.
Comment 15 Commit Notification 2017-08-09 11:17:37 UTC
Yossi Zahn committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5937eefe533fba332ab6a83da02496bb4b0bd3db

tdf#66212 - Hebrew numbering import/export support

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.