Title: Intent to Implement: Intl.DisplayNames API Proposal
Contact emails
Explainer
https://github.com/tc39/proposal-intl-displaynames
https://tc39.github.io/proposal-intl-displaynames/
Design doc/Spec
Engineering Plan https://goo.gl/im9wy4
Summary
Provides a new API to get localized names of language, region, script, currency codes of international standard as well as commonly used names of date fields and symbols.
Motivation
Main motivation for Intl.DisplayNames project was to enable developers to get translation of language, region or script display names on the client. Translation of languages, regions or script display names requires large amount of data to transmit on the network, which is already available in most browsers. These display name translations also carry steep data size penalty for developers. This API will allow web developers to shrink the size of their HTML and/ or ECMAScript code without the need to include the human readable form of display names and therefore reduce the download size to decrease latency. Also, this API will reduce the localization cost for the web developers. Our goal is to expose this data through Intl API for use in e.g. language, region and script pickers, etc.
Benefit
Reduce download size of apps and therefore improve latency.
Easy for users to build internationalized language, region or script selection UI components (drop down menu or other kinds).
Reduce translation cost for developers.
Consistent translation of language, region and script display name on the web.
Risks
Interoperability and Compatibility
This is a new API. It is currently under TC39 Stage 1 and we plan to propose to advance it to Stage 2 in June 2019.
Ergonomics
Activation
Web developers could use the API immediately upon our shipment.
Debuggability
Nothing special.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Is this feature fully tested by web-platform-tests?
Tests under tc39/test262 will includes many tests to test this API.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/4965112605573120
Requesting approval to ship?
“No”. The feature is behind a runtime flag harmony_intl_display_names and I will later send an Intent to Ship email when I am ready to enable by default.
Can the doc at https://goo.gl/im9wy4 be made public please?
Usually we only implement features at stage 3. What’s the motivation for implementing this particular API earlier? (Not saying I’m opposed to it.)
From: Mathias Bynens <mt...@google.com>
Date: Mon, 13 May 2019 at 18:08
To: Frank Tang
Cc: v8-users, blink-dev, Adam Klein, Frank Yung-Fong Tang, Sathya Gunasekaran, Nebojša Ćirić, <v8-...@googlegroups.com>, Jungshik Shin, Shane CarrCan the doc at https://goo.gl/im9wy4 be made public please?It always is.
--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CA%2B7fzPEZnnAGHh6mijLRByRm2A1xrgNFjSLr3gWf5Qs42bShrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOcELL8wEy1NrdM10dd9xPmBmrUuy8CrV95eHoOwdg_TzhmLnw%40mail.gmail.com.
[Note: Resent due to message header problem. Sorry]
Contact emails
ft...@chromium.org, sf...@chromium.orgExplainer
https://github.com/tc39/proposal-intl-segmenterSpecification
https://tc39.github.io/proposal-intl-segmenter/Design docs
https://docs.google.com/document/d/1xugLpLmgRFnNXK8ztariTAbD2IXueDw1T3VNuuZCz8k/edit#heading=h.xgjl2srtytjt
https://docs.google.com/presentation/d/1X2zBU3bZ4ergVMWfubCsdnHFzeaDgqiTRJVgvNGjQBs/edit#slide=id.pTAG review
review by ECMA402Summary
Intl.Segmenter implements methods for finding the location of boundaries in text, including grapheme, line, word and sentence boundary analysis.Motivation
Currently, chrome is shipped with Intl.v8BreakIterator - a non standard way for similar functionality. According to https://www.chromestatus.com/metrics/feature/timeline/popularity/556 on 2020 Feb there are 0.74% of the web page use it. Intl.Segmenter is the web standard to replace it.Risks
Interoperability and Compatibility
The specification is moved to Stage 3 in TC39 2020-Jul meeting with support from ECMA402.
Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1423593)
WebKit: No signal
Web developers: No signalsErgonomics
Engineer from Apple believe we should not add line break support to the Intl.Segmenter because the developer may abuse the API and perform text layout by themselves instead of depending on CSS. The line break feature then were removed from the specification in the current shape.Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
YesIs this feature fully tested by web-platform-tests?
Yes https://github.com/tc39/test262/tree/master/test/intl402/SegmenterLink to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/6099397733515264This intent message was generated by Chrome Platform Status.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOcELL-m7DZ5OAwZj9FqX9VKZKWYd_Qf0YeaXCs3YAEbcnPsKA%40mail.gmail.com.
[Note: Resent due to message header problem. Sorry]
Contact emails
ft...@chromium.org, sf...@chromium.org
Explainer
https://github.com/tc39/proposal-intl-segmenter
Specification
https://tc39.github.io/proposal-intl-segmenter/
Design docs
https://docs.google.com/document/d/1xugLpLmgRFnNXK8ztariTAbD2IXueDw1T3VNuuZCz8k/edit#heading=h.xgjl2srtytjt
https://docs.google.com/presentation/d/1X2zBU3bZ4ergVMWfubCsdnHFzeaDgqiTRJVgvNGjQBs/edit#slide=id.p
TAG review
review by ECMA402
Summary
Intl.Segmenter implements methods for finding the location of boundaries in text, including grapheme, line, word and sentence boundary analysis.
Motivation
Currently, chrome is shipped with Intl.v8BreakIterator - a non standard way for similar functionality. According to https://www.chromestatus.com/metrics/feature/timeline/popularity/556 on 2020 Feb there are 0.74% of the web page use it. Intl.Segmenter is the web standard to replace it.
Risks
Interoperability and Compatibility
The specification is moved to Stage 3 in TC39 2020-Jul meeting with support from ECMA402.
Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1423593)
FWIW, in development seems a bit of a stretch since there hasn't
been activity in the bug for a while.
The patch is three years old and there was a bit of a concern due
to the binary size growing
quite a bit.
(Not an expert on this, but Gecko's layout engine doesn't use ICU for line-breaking, IIRC, so a lot of the ICU data that would be required for this has to be imported).
There may be alternative implementation strategies or what not,
but it doesn't seem to be actively worked on.
WebKit: No signal
Web developers: No signals
Ergonomics
Engineer from Apple believe we should not add line break support to the Intl.Segmenter because the developer may abuse the API and perform text layout by themselves instead of depending on CSS. The line break feature then were removed from the specification in the current shape.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes https://github.com/tc39/test262/tree/master/test/intl402/Segmenter
Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/6099397733515264
This intent message was generated by Chrome Platform Status.
On 8/13/20 12:17 AM, Frank Tang wrote:
[Note: Resent due to message header problem. Sorry]
Contact emails
ft...@chromium.org, sf...@chromium.org
Explainer
https://github.com/tc39/proposal-intl-segmenter
Specification
https://tc39.github.io/proposal-intl-segmenter/
Design docs
https://docs.google.com/document/d/1xugLpLmgRFnNXK8ztariTAbD2IXueDw1T3VNuuZCz8k/edit#heading=h.xgjl2srtytjt
https://docs.google.com/presentation/d/1X2zBU3bZ4ergVMWfubCsdnHFzeaDgqiTRJVgvNGjQBs/edit#slide=id.p
TAG review
review by ECMA402
Summary
Intl.Segmenter implements methods for finding the location of boundaries in text, including grapheme, line, word and sentence boundary analysis.
Motivation
Currently, chrome is shipped with Intl.v8BreakIterator - a non standard way for similar functionality. According to https://www.chromestatus.com/metrics/feature/timeline/popularity/556 on 2020 Feb there are 0.74% of the web page use it. Intl.Segmenter is the web standard to replace it.
Risks
Interoperability and Compatibility
The specification is moved to Stage 3 in TC39 2020-Jul meeting with support from ECMA402.
Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1423593)
FWIW, in development seems a bit of a stretch since there hasn't been activity in the bug for a while.
The patch is three years old and there was a bit of a concern due to the binary size growing quite a bit.
(Not an expert on this, but Gecko's layout engine doesn't use ICU for line-breaking,
IIRC, so a lot of the ICU data that would be required for this has to be imported).
There may be alternative implementation strategies or what not, but it doesn't seem to be actively worked on.
--
WebKit: No signal
Web developers: No signals
Ergonomics
Engineer from Apple believe we should not add line break support to the Intl.Segmenter because the developer may abuse the API and perform text layout by themselves instead of depending on CSS. The line break feature then were removed from the specification in the current shape.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes https://github.com/tc39/test262/tree/master/test/intl402/Segmenter
Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/6099397733515264
This intent message was generated by Chrome Platform Status.
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOcELL-m7DZ5OAwZj9FqX9VKZKWYd_Qf0YeaXCs3YAEbcnPsKA%40mail.gmail.com.
I see, thanks for the clarification. If that is so, "Positive signals" may be better than "In development"? It doesn't seem like anybody is working on it (yet).
-- Emilio
Sure, to be clear, I wasn't trying to push back. Jbliust wanted
to point out that it doesn't seem to be worked on right now, so
"in development" doesn't seem quite accurate. "Positive" seems
like a more accurate description per this
document?
The patch is three years old and there was a bit of a concern due to the binary size growing quite a bit.
(Not an expert on this, but Gecko's layout engine doesn't use ICU for line-breaking,
I know, I hand wrote that between 1998-2002 when I was Mozilla's i18n module owner and Netscape i18n client manager. They have not changed that part code for the last 20+ years as I know (beside the work I worked with some Thai folks in late 2003 to deal with Thai line breaking). The current version of Intl.Segmenter spec took out the line break support two years ago so that is irrelevant anyway.
FWIW, it seems that for a bunch of more complex languages (Thai included) nowadays we rely on platform-native APIs instead (see bug 389520, bug 336959, bug 390048, etc).
-- Emilio