🚚 replace old references

README.md

@@ -11,9 +11,9 @@ This source is processed to obtain a human-readable version, which you can view
 
 Proposals follow [the TC39 process](https://tc39.es/process-document/) and are tracked in the [proposals repository](https://github.com/tc39/proposals).
 
-* [Finished Proposals](https://github.com/tc39/proposals/blob/master/ecma402/finished-proposals.md)
-* [Active Proposals](https://github.com/tc39/proposals/blob/master/ecma402/README.md)
-* [Stage 0 Proposals](https://github.com/tc39/proposals/blob/master/ecma402/stage-0-proposals.md)
+* [Finished Proposals](https://github.com/tc39/proposals/blob/HEAD/ecma402/finished-proposals.md)
+* [Active Proposals](https://github.com/tc39/proposals/blob/HEAD/ecma402/README.md)
+* [Stage 0 Proposals](https://github.com/tc39/proposals/blob/HEAD/ecma402/stage-0-proposals.md)
 
 Information about status of tests, documentations and browser implementations of proposals can be found in [this wiki page](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking).
 

meetings/agenda-2018-02-16.md

@@ -17,7 +17,7 @@ Contact Daniel Ehrenberg ([email protected]) for the link to the Google Hango
         1. [Locale](https://github.com/tc39/proposal-intl-locale)
     1. [lb option added to Segmenter](https://github.com/tc39/proposal-intl-segmenter/pull/24); [renamed to lineBreakStyle](https://github.com/tc39/proposal-intl-segmenter/pull/25)
     1. [Settled on numeric: always/auto](https://github.com/tc39/proposal-intl-relative-time/pull/60)
-    1. [Explained the existence of this call; well-received](https://github.com/tc39/tc39-notes/blob/master/es8/2018-01/jan-23.md#4-ecma402-status-updates)
+    1. [Explained the existence of this call; well-received](https://github.com/tc39/tc39-notes/blob/HEAD/es8/2018-01/jan-23.md#4-ecma402-status-updates)
     1. Non-members who contribute to ECMA 402 (either PRs or in this call): Sign [this form](https://tc39.es/agreements/contributor/) to license contributions to Ecma
 1. Questions/issues with existing advanced proposals and APIs
     1. [Normative: Add calendar and numberingSystem options](https://github.com/tc39/ecma402/pull/175)

meetings/agenda-2019-01-17.md

@@ -36,7 +36,7 @@ Contact Daniel Ehrenberg ([email protected]) for the link to the Google Hango
         1. Move under TC39 by creating a new project and following instruction on [Template for Proposals](https://github.com/tc39/template-for-proposals)
         2. Frank Tang will Champion
         3. Have problem to move Issues from the [old location](https://github.com/brawer/proposal-intl-displaynames).
-        4. Now list under [Stage 0 of ECMA402](https://github.com/tc39/proposals/blob/master/ecma402/stage-0-proposals.md) 
+        4. Now list under [Stage 0 of ECMA402](https://github.com/tc39/proposals/blob/HEAD/ecma402/stage-0-proposals.md)
         5. Would like to change the API shape in [README](https://github.com/tc39/proposal-intl-displaynames/pull/2) and [SPEC](https://github.com/tc39/proposal-intl-displaynames/pull/4)
         6. And like to move under Stage 1
 6. Newer proposals

meetings/notes-2017-12-15.md

@@ -1,4 +1,4 @@
-Agenda: [https://github.com/tc39/ecma402/blob/master/meetings/agenda-2017-12-15.md](https://github.com/tc39/ecma402/blob/master/meetings/agenda-2017-12-15.md)
+Agenda: [https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2017-12-15.md](https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2017-12-15.md)
 
 # Attendees
 
@@ -11,7 +11,7 @@ Agenda: [https://github.com/tc39/ecma402/blob/master/meetings/agenda-2017-12-15.
 * RX: Rafael Xaviers (Paypal)
 * MS: Michael Saboff (Apple)
 * SM: Stas Małolepszy (Mozilla)
-* CC: Craig Cornelius (Google) 
+* CC: Craig Cornelius (Google)
 * FB: Felipe Balbontín (Google)
 * CP: Caridy Patiño (Salesforce)
 * JS: Jungshik Shin (Google)
@@ -128,7 +128,7 @@ ZB: these prefs could be made locale-sensitive, as in, dateStyle: short might me
 
 DE: navigator.locales could expose OS’s calendar prefs (something navigator.languages doesn’t expose)
 
-DE: Intl.Locale API makes an update that corresponds to lang tag and options You can parse out the script or change the calendar and pass it to other Intl ctors. 
+DE: Intl.Locale API makes an update that corresponds to lang tag and options You can parse out the script or change the calendar and pass it to other Intl ctors.
 
 NC: it feels like it combines two separate things: locales and user preferences.
 

meetings/notes-2018-01-19.md

@@ -1,16 +1,16 @@
-Agenda: [https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-01-19.md](https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-01-19.md)
+Agenda: [https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-01-19.md](https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-01-19.md)
 
 Attendees:
 
-* Caridy Patino (CP) - 
-* Zbignew Braniecki (ZB) - Mozilla - 
-* Daniel Ehrenberg (DE)  - Igalia - github.com/littledan 
+* Caridy Patino (CP) -
+* Zbignew Braniecki (ZB) - Mozilla -
+* Daniel Ehrenberg (DE)  - Igalia - github.com/littledan
 * Stas Malolepszy (SM)
 * Jungshik Shin (JS) - Google - github.com/jungshik
 * Steven R. Loomis (SL) - IBM - github.com/srl295
 * Eemeli Aro (EA) - github.com/eemeli
-* Nebojsa Ciric (NC) - Google 
-* Shane Carr (Shane) - Google 
+* Nebojsa Ciric (NC) - Google
+* Shane Carr (Shane) - Google
 * JH: Jack Horton (MSFT) github.com/jackhorton
 * DIV: Doug Ilijev (MSFT) github.com/dilijev
 * BT: Brian Terlson (MSFT) github.com/bterlson
@@ -48,10 +48,10 @@ Attendees:
             * ZB: Seems like this would be useful in Intl.js
             * NC: Does PluralRules enable us to do message formatting any way we want until we get actual message formatting
             * JS: Any plural-related things, lets you select the message. Doesn’t include the message.
-            * ZB: Everything on top of PluralRules is just an algorithm, so hopefully this reduces the load of any 
+            * ZB: Everything on top of PluralRules is just an algorithm, so hopefully this reduces the load of any
             * EA: The data is small here
-            * NC: Seems like this 
-            * DE: Is there a way to get the list of availableLocales for plural rules? 
+            * NC: Seems like this
+            * DE: Is there a way to get the list of availableLocales for plural rules?
             * EA: Seen a locale with Cardinal rules but without Ordinal Rules
             * SL: can assume that  if ‘locale’ data (e.g. for formatting) is available for a given locale, PR is also available for the locale.
             * SM: Firefox ships or is preparing to ship in 19 locales which don't have plural rules defined in the CLDR. These are: ach, an, cak, csb, gn, hto, ia (Interlingua), kok, lij, ltg, mai, oc, pbb, qvi, rw, sat, son, trs, tsz.
@@ -94,7 +94,7 @@ Attendees:
                 10. JS: Yes. Actually we had some historical Mozilla test that we had to disable since it expected the spec semantics.
                 11. DE: I’m not sure if OS semantics support this, as opposed to using ICU. Many JS implementations currently use OS APIs.
                 12. JS: I think the Windows API supports this, but we would’ve had to modify the sandbox to support it. For Linux, it probably is possible, but it would probably require a lot of hooks and duplicating a lot of what ICU does. For that reason, I didn’t other to do it.
-                13. SL: POSIX APIs assume that 
+                13. SL: POSIX APIs assume that
                 14. JS: I have an ICU change request open to change ICU to make this easier to implement.
                 15. ZB: Do implementers have any concerns?
                 16. JH: If this will require an ICU API, we definitely need it to not be internal.
@@ -109,7 +109,7 @@ Attendees:
         * CP: None of the formats that are there make forward-compatibility guarantees.
         * ZB: UTS 35 doesn’t help us too much; none of ECMA 402 depends on this. We’d have to make a lot of changes to the specification, and not make things data-dependent.
         * SC: If we introduce this, then other specifications could be rephrased in terms of this new data source.
-        * CP: The problem is the stability of UTS 35--we have to make sure that 
+        * CP: The problem is the stability of UTS 35--we have to make sure that
         * DE: Seems like there is still a lot more design work.
 3. Stage 3 proposals
     1. [Intl.Segmenter](https://github.com/tc39/proposal-intl-segmenter/)
@@ -127,8 +127,8 @@ Attendees:
             * SL: There’s a stripped-down data set by default, and then you can install all the data which includes dictionaries.
             * DE: So, is unspecified breaking right? And, should we continue to leave the connection to CSS unspecified?
             * JS: ICU has ‘strict’, ‘loose’ and ‘normal’ from CSS3. Does Ecma want to have those options?
-            * DE: Possible to add them as an option. Currently, there’s no option. 
-            * DE: how about ‘word-break: break-all’?  
+            * DE: Possible to add them as an option. Currently, there’s no option.
+            * DE: how about ‘word-break: break-all’?
             * JS: This is for latin text in CJK text
             * SL: There’s a lot of room for improvement here
             * NC: Internally in Google, there’s a lot of machine learning work going on for segmenters
@@ -144,7 +144,7 @@ Attendees:
             * DE: Currently strictness is only supported via the options bag
             * JS: Seems like we should add this to the locale tag.
             * SL: There are many other things in locales that could be added
-            * SL: Unicode locale extensions have ‘lb’ (line breaking), ‘wb’ (? word breaking), ss (suppress …), 
+            * SL: Unicode locale extensions have ‘lb’ (line breaking), ‘wb’ (? word breaking), ss (suppress …),
             * SL: If we have those three in the BCP, we should mention them in the specification here. [https://www.unicode.org/repos/cldr/trunk/specs/ldml/tr35.html#UnicodeLineBreakStyleIdentifier](https://www.unicode.org/repos/cldr/trunk/specs/ldml/tr35.html#UnicodeLineBreakStyleIdentifier) [https://www.unicode.org/repos/cldr/trunk/specs/ldml/tr35.html#UnicodeSentenceBreakSuppressionsIdentifier](https://www.unicode.org/repos/cldr/trunk/specs/ldml/tr35.html#UnicodeSentenceBreakSuppressionsIdentifier)
             * NC: Currently we support lb. Should we support wb and ss? Are they important enough? Some of these seem a little artificial, like ss, which is based on the technology underneath.
             * SL: I don’t quite follow. Ss specifies an improvement to line breaks using commonly known exceptions.
@@ -162,7 +162,7 @@ Attendees:
             * DE: compound unit is not supported. Earlier draft supported it, but it was removed due to design issues.
             * JS: future plan for compound unit?
             * DE: We could do this in a future version, but there are many policy choices, so it is complicated. List format over RelativeTF is an option.
-            * NC: Does this work 
+            * NC: Does this work
             * DE: What should we do about type: numeric/text, which has numeric as the default?
             * JS: What’s the motivation?
             * DE: You don’t know which is the right cutoff unless you know what time of day it is, etc. You don’t have the timeline that this is relative to.
@@ -175,8 +175,8 @@ Attendees:
             * DIV: I think numeric should be the default.
             * CP: I think so too. You have to be aware of this issue if you want to get yesterday/tomorrow.
             * DIV: Speaking of days, can we have "1 day, 1 hour, and 30 seconds ago"?
-            * (reply): can do with [ListFormat](?) + RelativeTimeFormat 
-            * This is a low-level API (similar to PluralRules) on top of which a library writer can implement a smarter (higher-level) API. 
+            * (reply): can do with [ListFormat](?) + RelativeTimeFormat
+            * This is a low-level API (similar to PluralRules) on top of which a library writer can implement a smarter (higher-level) API.
             * Will present next week (name TBD?)
     2. [Intl.Locale](https://github.com/tc39/proposal-intl-locale/)
         * Stage 2
@@ -187,7 +187,7 @@ Attendees:
             * JS: Yes, it should be explicit.
             * Conclusion: Not supported.
         * [Will not throw an exception on unsupported locales](https://github.com/tc39/proposal-intl-locale/issues/6)
-            * NC: We were talking about possible additional data packs. This allows working with the locale ID. We don’t have any data, but we have a working BCP 47 ID. If it goes into date formatter, date formatter will 
+            * NC: We were talking about possible additional data packs. This allows working with the locale ID. We don’t have any data, but we have a working BCP 47 ID. If it goes into date formatter, date formatter will
         * [Should additional tags be passed through?](https://github.com/tc39/proposal-intl-locale/issues/4)
             * SL: Should be able to round-trip, though it’s OK to sort the tags and normalize the locale.
         * OK to ship this as a minimal base, with other important complements (likely subtags, display names, more options) in follow-on proposals?
@@ -198,7 +198,7 @@ Attendees:
         * Ready for Stage 3?
         * DE: Interface to BCP 47. Identify script, region, language, etc from a given locale id. Has toString() to build a locale id in a string
         * DE: future extension for likelySubtag, etc
-        * When Locale is passed to Intl.* API,  should Locale be treated specially instead of invoking toString() ? 
+        * When Locale is passed to Intl.* API,  should Locale be treated specially instead of invoking toString() ?
         * DE: Yes
     3. [Intl.ListFormat](https://github.com/tc39/proposal-intl-list-format)
         * Stage 2
@@ -210,7 +210,7 @@ Attendees:
                 22. NS: Should we rename regular to "and" and add negative lists as “or”?
                 23. DIV: How about we call regular lists "conjunction" and add “disjunction” (linguistic terms rather than english-specific words “and”/”or”)
                 24. ZB: I like this suggestion, since "and" and “or” seems too specific to English
-                25. DIV: There are issues in languages about handling adjectives, etc. 
+                25. DIV: There are issues in languages about handling adjectives, etc.
                 26. ZB: I’m not sure if we’ll support adjectives here.
                 27. NC: Do we need gender information? ListFormat supports this...
                     1. SL: personList with gender

meetings/notes-2018-02-16.md

@@ -1,4 +1,4 @@
-Agenda: [https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-02-16.md](https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-02-16.md)
+Agenda: [https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-02-16.md](https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-02-16.md)
 
 Attendees: Zibi Braniecki, Mozilla (ZB), Caridy Patiño (CP), Brian Terlson (BT), Doug Ilijev (DIV), Jack Horton (JH) Steven R. Loomis (SR), Shane Carr (SC), Jeff Genovy (JG) Felipe (F)
 
@@ -15,7 +15,7 @@ Agenda:
         * [Locale](https://github.com/tc39/proposal-intl-locale)
     3. [lb option added to Segmenter](https://github.com/tc39/proposal-intl-segmenter/pull/24);[ renamed to lineBreakStyle](https://github.com/tc39/proposal-intl-segmenter/pull/25)
     4. [Settled on numeric: always/auto](https://github.com/tc39/proposal-intl-relative-time/pull/60)
-    5. [Explained the existence of this call; well-received](https://github.com/tc39/tc39-notes/blob/master/es8/2018-01/jan-23.md#4-ecma402-status-updates)
+    5. [Explained the existence of this call; well-received](https://github.com/tc39/tc39-notes/blob/HEAD/es8/2018-01/jan-23.md#4-ecma402-status-updates)
     6. Non-members who contribute to ECMA 402 (either PRs or in this call): Sign[ this form](https://tc39.es/agreements/contributor/) to license contributions to Ecma
 2. Questions/issues with existing advanced proposals and APIs
     1. [Normative: Add calendar and numberingSystem options](https://github.com/tc39/ecma402/pull/175)
@@ -155,15 +155,15 @@ SR: und is root.
 
 JS: better for users to explicitly specify a locale, rather than mysterious default locale showing up automatically
 
-??: 
+??:
 
 Conclusion: Throw when a locale isn’t provided.
 
 **Item 2.iii.c**
 
-ZB: 
+ZB:
 
-SR: 
+SR:
 
 **Item 3 (ICU tickets)**
 
@@ -211,7 +211,7 @@ SC: yes, this includes unit format on it.
 
 JH: I want to point two things. This relies heavily on ICU design, which MS usually push back. Point two is the the C implementation of these ICU apis is very far away it seems. This might put a serious burden on us.
 
-SC: Yes, there are ICU Apis that maps directly to this new APIs. But this is a 402 spec, we don’t have to model the spec after ICU. 
+SC: Yes, there are ICU Apis that maps directly to this new APIs. But this is a 402 spec, we don’t have to model the spec after ICU.
 
 DIV: We (Chakra) must have non-experimental ICU C (not C++) APIs to implement any of these features. Until experimental tag is removed from those C APIs, we should not allow these proposals to get to stage 4.
 
@@ -247,13 +247,13 @@ Conclusion: Felipe will prepare the material to present it on the next tc39 meet
 
 NC: the last one worked better.
 
-• looking at overflow: [https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-02-16.md#overflow](https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-02-16.md#overflow)
+• looking at overflow: [https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-02-16.md#overflow](https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-02-16.md#overflow)
 
 ZB: ovf 1.iv.b - likelySubtags
 
 NC: maximize?  Yes.  (and minimize)
 
-ZB: ovf 1.vi.a: datetime style? 
+ZB: ovf 1.vi.a: datetime style?
 
 CP: Organizational…  Will be out 2H2018, need help on editorial role.