Drop trailing zeroes only for rightmost group for cjk-ideographic

Drop trailing zeroes only for rightmost group for cjk-ideographic

Drop trailing zeroes only for rightmost group for cjk-ideographic
list style type and add subtests for it to fast/lists/w3-list-styles.html.

Also import relevant tests from css-counter-styles-3 spec [1].

Help with chinese numbering conventions was provided by Kai
Sheng (k.sheng@partner.samsung.com).

[1] https://github.com/w3c/csswg-test/tree/master/css-counter-styles-3/i18n

BUG=344214
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=197154

[rwlbuis, 2015-06-05 23:49:59]

rob.buis@samsung.com changed reviewers:
+ tabatkins@chromium.org

[rwlbuis, 2015-06-05 23:50:00]

PTAL. Not sure who is the best reviewer for this...

[tkent, 2015-06-10 22:17:18]

tkent@chromium.org changed reviewers:
+ kojii@chromium.org, tkent@chromium.org

[tkent, 2015-06-10 22:17:19]

+kojii

[rwlbuis, 2015-06-10 23:11:54]

On 2015/06/10 22:17:19, tkent wrote:
> +kojii

A comment from Tab on #blink:

TabAtkins> rwlbuis: <snip> feel free to comment in the bug that this got a
spec-wise r+ from me.

[kojii, 2015-06-11 00:13:32]

On 2015/06/10 at 23:11:54, rob.buis wrote:
> On 2015/06/10 22:17:19, tkent wrote:
> > +kojii
> 
> A comment from Tab on #blink:
> 
> TabAtkins> rwlbuis: <snip> feel free to comment in the bug that this got a
spec-wise r+ from me.

Don't know about the code around this, so talking purely from the -expected
perspective.

Chinese and Japanese disagrees when >= 100, and cjk-ideographic is for Chinese
for the case. I'm Japanese, so I can't be sure the new behavior is really
correct from Chinese cultural point of view.

I asked Xidorn, a Chinese Gecko developer who implemented lists to Gecko:
1. 一千零万一千 is definitely wrong
2. I don't think 一千万一千 is acceptable as well
3. 一千万零一千 is the correct one
4. There was a feedback on this for the spec, but it was too complicated that
the spec dropped documenting these ranges
5. Since the spec is not correct for the extended ranges, if you want to
implement the extended range, you should fix what behavior to what the issue
original described

Gecko's test case is here:
http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/counters/c...
It doesn't include 10001000, but the general rule looks to align with what the
original reporter said.

[rwlbuis, 2015-06-11 14:13:37]

On 2015/06/11 00:13:32, kojii wrote:
> On 2015/06/10 at 23:11:54, rob.buis wrote:
> > On 2015/06/10 22:17:19, tkent wrote:
> > > +kojii
> > 
> > A comment from Tab on #blink:
> > 
> > TabAtkins> rwlbuis: <snip> feel free to comment in the bug that this got a
> spec-wise r+ from me.
> 
> Don't know about the code around this, so talking purely from the -expected
> perspective.
> 
> Chinese and Japanese disagrees when >= 100, and cjk-ideographic is for Chinese
> for the case. I'm Japanese, so I can't be sure the new behavior is really
> correct from Chinese cultural point of view.
> 
> I asked Xidorn, a Chinese Gecko developer who implemented lists to Gecko:
> 1. 一千零万一千 is definitely wrong
> 2. I don't think 一千万一千 is acceptable as well
> 3. 一千万零一千 is the correct one
> 4. There was a feedback on this for the spec, but it was too complicated that
> the spec dropped documenting these ranges
> 5. Since the spec is not correct for the extended ranges, if you want to
> implement the extended range, you should fix what behavior to what the issue
> original described
> 
> Gecko's test case is here:
>
http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/counters/c...
> It doesn't include 10001000, but the general rule looks to align with what the
> original reporter said.

Thanks for the pointers!

I am going by my chinese colleague Kai Sheng who thinks 2 is acceptable:

In the Chinese wiki page
(https://zh.wikipedia.org/wiki/%E4%B8%AD%E6%96%87%E6%95%B0%E5%AD%97), the
following sentence appears,

台灣的小學四上數學中，即有一個單元是關於大數字的讀法，例如：5,920,001,245，讀作“五十九億兩千萬一千兩百四十五”

(There is a chapter about representation of large numbers on the textbook of
Taiwan 4th grade fall semester, for example,

5,920,001,245 is read as 五十九億兩千萬一千兩百四十五.)

Notice that it is not五十九億兩千萬*零*一千兩百四十五.

[kojii, 2015-06-11 17:11:43]

It's true that CJK numbering has some variations. The correctness and acceptance
level could vary by formal/informal or by regions, or sometimes even by people,
so it's quite possible that two natives disagree, and it's hard to determine how
acceptable it is in such cases.

Two questions:
1. What did your colleague say about #3? Is #3 better than #2 for your
colleague?
2. Is it feasible for you to prepare a patch for #3?

If your friend says #2 is acceptable but #3 is correct, and if it's not too hard
to do #3, I would prefer us doing non-controversial fix. That'd be then no
brainer for OWNERS.

If no to any of these questions, I would like to ask what OWNERS would say based
on the facts we collected. Facts we could show atm are:

* The current patch behavior:
  - Makes "definitely wrong" to "controversial". Not sure what the parameters of
the controversial are; probably by people, by formalness, or by Taiwan/mainland.
  - Does not do what the reporter expects.
  - Disagree with Gecko.
  - Follows the spec, but there was a feedback that the spec is not correct, and
it was Won't Fixed. I found some reference saying that Chinese should collapse
consecutive zeros (regardless of groups), so the feedback was not just from
single person.
* IE does not support this format.
* If we need more info to make the call, maybe we could try Chinese version of
Excel, or ask i18n team if ICU/CLDR supports this.

You could add if any.

[kojii, 2015-06-11 17:16:07]

One more I found:
* The w3-list-style-expected.txt says "101" is "一百零一" both before/after the
patch.

[rwlbuis, 2015-06-12 21:30:13]

Patchset #4 (id:60001) has been deleted

[rwlbuis, 2015-06-15 19:39:04]

On 2015/06/11 17:11:43, kojii wrote:
> It's true that CJK numbering has some variations. The correctness and
acceptance
> level could vary by formal/informal or by regions, or sometimes even by
people,
> so it's quite possible that two natives disagree, and it's hard to determine
how
> acceptable it is in such cases.
> 
> Two questions:
> 1. What did your colleague say about #3? Is #3 better than #2 for your
> colleague?
> 2. Is it feasible for you to prepare a patch for #3?
> 
> If your friend says #2 is acceptable but #3 is correct, and if it's not too
hard
> to do #3, I would prefer us doing non-controversial fix. That'd be then no
> brainer for OWNERS.
> 
> If no to any of these questions, I would like to ask what OWNERS would say
based
> on the facts we collected. Facts we could show atm are:
> 
> * The current patch behavior:
>   - Makes "definitely wrong" to "controversial". Not sure what the parameters
of
> the controversial are; probably by people, by formalness, or by
Taiwan/mainland.
>   - Does not do what the reporter expects.
>   - Disagree with Gecko.
>   - Follows the spec, but there was a feedback that the spec is not correct,
and
> it was Won't Fixed. I found some reference saying that Chinese should collapse
> consecutive zeros (regardless of groups), so the feedback was not just from
> single person.
> * IE does not support this format.
> * If we need more info to make the call, maybe we could try Chinese version of
> Excel, or ask i18n team if ICU/CLDR supports this.
> 
> You could add if any.

I am not an expert on this and I am fine with the Firefox behavior. I
implemented this
in patch set #5.

[rwlbuis, 2015-06-15 19:42:38]

PTAL.

[kojii, 2015-06-16 01:24:34]

Again from purely test perspective and non-owner, but LGTM.

It's great to see we now pass most (all?) of i18n WG tests and turn them to
green:
http://www.w3.org/International/tests/repo/results/predefined-counter-styles#...

I'll ask Richard to re-test when this CL landed. Thank you for all the efforts!

[tkent, 2015-06-16 01:56:06]

lgtm

[rwlbuis, 2015-06-16 02:06:32]

The CQ bit was checked by rob.buis@samsung.com

[commit-bot: I haz the power, 2015-06-16 02:06:40]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1170603003/100001

[commit-bot: I haz the power, 2015-06-16 03:15:02]

Committed patchset #5 (id:100001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=197154

[rwlbuis, 2015-06-16 13:55:15]

On 2015/06/16 01:24:34, kojii wrote:
> Again from purely test perspective and non-owner, but LGTM.
> 
> It's great to see we now pass most (all?) of i18n WG tests and turn them to
> green:
>
http://www.w3.org/International/tests/repo/results/predefined-counter-styles#...
> 
> I'll ask Richard to re-test when this CL landed. Thank you for all the
efforts!

I'd be happy to add more of cjk to get more passes. Remember that we only
support
cjk-ideographic and korean-hangul-formal. So even though cjk-ideographic resorts
to
trad-chinese-formal we will not support the latter and the tests you linked to
will all fail.
I think I'll do a follow up patch to support at least that, otherwise Richard
maybe
will not see any improvement.

[kojii, 2015-06-16 14:44:50]

On 2015/06/16 13:55:15, rwlbuis wrote:
> On 2015/06/16 01:24:34, kojii wrote:
> > Again from purely test perspective and non-owner, but LGTM.
> > 
> > It's great to see we now pass most (all?) of i18n WG tests and turn them to
> > green:
> >
>
http://www.w3.org/International/tests/repo/results/predefined-counter-styles#...
> > 
> > I'll ask Richard to re-test when this CL landed. Thank you for all the
> efforts!
> 
> I'd be happy to add more of cjk to get more passes. Remember that we only
> support
> cjk-ideographic and korean-hangul-formal. So even though cjk-ideographic
resorts
> to
> trad-chinese-formal we will not support the latter and the tests you linked to
> will all fail.
> I think I'll do a follow up patch to support at least that, otherwise Richard
> maybe
> will not see any improvement.

You're right, I thought cjk-ideographic is an alias to trad-chinese-informal,
but it's so only in the spec, not in our impl yet...

If you're willing to continuously work on this area, the better option than
asking Richard to re-test is to import the CSS WG tests, which has imported all
i18n tests:
https://github.com/w3c/csswg-test/tree/master/css-counter-styles-3/i18n
then fix failures incrementally. We don't have to maintain a copy of tests then.

tkent and I can help if you're willing to do so. Does that sound good?

[rwlbuis, 2015-06-17 23:36:02]

On 2015/06/16 14:44:50, kojii wrote:
> On 2015/06/16 13:55:15, rwlbuis wrote:
> > On 2015/06/16 01:24:34, kojii wrote:
> > > Again from purely test perspective and non-owner, but LGTM.
> > > 
> > > It's great to see we now pass most (all?) of i18n WG tests and turn them
to
> > > green:
> > >
> >
>
http://www.w3.org/International/tests/repo/results/predefined-counter-styles#...
> > > 
> > > I'll ask Richard to re-test when this CL landed. Thank you for all the
> > efforts!
> > 
> > I'd be happy to add more of cjk to get more passes. Remember that we only
> > support
> > cjk-ideographic and korean-hangul-formal. So even though cjk-ideographic
> resorts
> > to
> > trad-chinese-formal we will not support the latter and the tests you linked
to
> > will all fail.
> > I think I'll do a follow up patch to support at least that, otherwise
Richard
> > maybe
> > will not see any improvement.
> 
> You're right, I thought cjk-ideographic is an alias to trad-chinese-informal,
> but it's so only in the spec, not in our impl yet...
> 
> If you're willing to continuously work on this area, the better option than
> asking Richard to re-test is to import the CSS WG tests, which has imported
all
> i18n tests:
> https://github.com/w3c/csswg-test/tree/master/css-counter-styles-3/i18n
> then fix failures incrementally. We don't have to maintain a copy of tests
then.
> 
> tkent and I can help if you're willing to do so. Does that sound good?

That sounds great, I started working on that.