Repository navigation
feat(i18n)!: a -u-ca- keyword selects the calendar - #10000
nynexman4464 wants to merge 2 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
AI review status for this pull request.
|
meta-cla
Bot
added
the
CLA Signed
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
Approval waits on an engineering owner's spec decision. An explicit -u-ca- keyword in the InternationalizationProvider locale now selects the calendar, while the internationalization architecture on main says a locale must not select a different calendar and the calendar-systems spec the description wants amended is not merged. An engineering owner needs to approve or reject the proposed provider FR10 and ORD3 and architecture INV10 text: the keyword rule, the islamic to islamic-tbla alias, the fallback for an unsupported keyword, and the breaking class. To approve, the owner comments /approve-spec with the full head commit SHA (the author may do so as an engineering owner), or says what to change.
Required regardless of that decision:
- Six unreleased Changesets on this branch (
calendar-system-boundary.md,calendar-systems-core.md,calendar-typed-entry.md,calendar-bottom-sheet.md,calendar-native-fallback.mdandcalendar-presentations.md) still say a-u-ca-locale keeps Gregorian dates, contradicting the new[breaking]Changeset in the same release, so delete or reword that sentence in each and mention the touch-picker change incalendar-locale-keyword.md.
[Automated review]
37c9150 to
02527f4
Compare
48a0c64 to
470d85d
Compare
02527f4 to
6db495e
Compare
470d85d to
8164323
Compare
6db495e to
4f3aa42
Compare
8164323 to
c5f702f
Compare
There was a problem hiding this comment.
Approval waits on an engineering owner's spec decision. The current InternationalizationProvider FR10 and ORD3 and internationalization INV10 say a -u-ca- keyword in the provider locale never selects the calendar, and this pull request intentionally rewrites them, so an engineering owner needs to update those records by approving or rejecting the keyword rule, the islamic to islamic-tbla alias, the Gregorian fallback with a warning for an unsupported keyword, and the breaking 0.8.0 class. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner.
Required whatever the decision:
- Amend the calendar-systems spec (
docs/specs/AST-111-calendar-systems/spec.md) FR2, its example, its Current-state impact bullet, its FR1–FR2 verification row and DEC-2 in this pull request, because they still say a-u-ca-keyword never selects the calendar while the rewritten FR10 and INV10 cite AST-111 FR2 as their basis. - Delete or reword the
-u-ca-sentence in the six pending Changesets that still say such a locale keeps Gregorian dates (calendar-system-boundary.md,calendar-systems-core.md,calendar-typed-entry.md,calendar-presentations.md,calendar-bottom-sheet.mdandcalendar-native-fallback.md), and add tocalendar-locale-keyword.mdthat on touch screens DateInput and DateTimeInput under such a locale now open the bottom sheet instead of the native date control.
[Automated review]
| | FR6 | Without a provider, the public context and hooks MUST expose locale `en`, direction `ltr`, an empty supplied-catalog map, and a translator backed by shipped English. | Released context and tests | settled | | ||
| | FR7 | The provider MUST preserve a string-returning translator suitable for visible and assistive attributes. | Released catalog/runtime contract | settled | | ||
| | FR8 | A nested provider MUST replace locale, messages, overrides, direction, and calendar with values derived solely from the child provider's own props rather than merge parent context. | Released provider and nested-provider tests | settled | | ||
| | FR10 | The provider MUST resolve its calendar from its `calendar` prop, else an explicit `-u-ca-` keyword in `locale`, else `gregory`, and expose it on the context as `calendar`. A locale's default calendar MUST NOT apply: `fa-IR` alone resolves to `gregory`, and `th-TH-u-ca-buddhist` resolves to `buddhist`. The keyword `islamic` resolves to `islamic-tbla`, as ECMA-402 resolves it; that alias does not apply to a `calendar` prop. The calendar is independent of language, numbering, and direction. `Calendar`, `DateInput`, `DateRangeInput`, and `DateTimeInput` follow the resolved calendar, and a component's own `calendar` prop takes precedence over the provider's. | `spec:AST-111` FR1, FR2 | settled | |
There was a problem hiding this comment.
FR10 names spec:AST-111 FR1, FR2 as its basis, but AST-111 FR2 on this base still says a -u-ca- keyword never selects the calendar. Please add the FR2, example, Current-state impact, verification-row and DEC-2 amendment from the description to this pull request so the records agree.
| display-calendar override remains a supported explicit caller choice. | ||
| date component shows the calendar that it resolves from its own `calendar` | ||
| prop, the provider's `calendar` prop, or an explicit `-u-ca-` keyword in the | ||
| provider's locale, and otherwise the Gregorian calendar (`spec:AST-111` FR2). |
There was a problem hiding this comment.
INV10 cites spec:AST-111 FR2 for a rule that FR2 still states the other way round on this base; the AST-111 amendment needs to land with this change.
| '@astryxdesign/core': minor | ||
| --- | ||
|
|
||
| [breaking] A `-u-ca-` keyword in the `InternationalizationProvider` `locale` selects the calendar when the provider has no `calendar` prop. `th-TH-u-ca-buddhist` now shows Buddhist years in `Calendar`, `DateInput`, `DateRangeInput`, and `DateTimeInput`, where it showed Gregorian dates before. A component's `calendar` prop and the provider's `calendar` prop still take precedence. The keyword `islamic` resolves to `islamic-tbla`, as ECMA-402 resolves it; a `calendar="islamic"` prop stays an unknown identifier. A keyword outside `CalendarSystem` resolves to Gregorian and warns once in development. A locale without the keyword, such as `fa-IR`, still shows Gregorian dates. Date values stay Gregorian ISO strings. |
There was a problem hiding this comment.
Under a -u-ca- locale, DateInput and DateTimeInput on a touch screen now open the bottom sheet instead of the native date control, and an explicit presentation="native" shows the Astryx picker and warns. Please say so here, and remove the "keeps Gregorian dates" sentence from the six other pending calendar Changesets.
4f3aa42 to
351ec9c
Compare
c5f702f to
591a7f0
Compare
There was a problem hiding this comment.
Approval waits on an engineering owner's spec decision. The current InternationalizationProvider FR10 and ORD3 and internationalization INV10 say a -u-ca- keyword in the provider locale never selects the calendar, and this pull request intentionally rewrites them, so an engineering owner needs to update those records by approving or rejecting the keyword rule, the islamic to islamic-tbla alias, the Gregorian fallback with a warning for an unsupported keyword, and the breaking 0.8.0 class. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner.
Required whatever the decision:
- Amend the calendar-systems spec (
docs/specs/AST-111-calendar-systems/spec.md) FR2, its example, its Current-state impact bullet, its FR1–FR2 verification row and DEC-2 in this pull request, because they still say a-u-ca-keyword never selects the calendar while the rewritten FR10 and INV10 cite AST-111 FR2 as their basis. - Delete or reword the
-u-ca-sentence in the six pending Changesets that still say such a locale keeps Gregorian dates (calendar-system-boundary.md,calendar-systems-core.md,calendar-typed-entry.md,calendar-presentations.md,calendar-bottom-sheet.mdandcalendar-native-fallback.md), and add tocalendar-locale-keyword.mdthat on touch screens DateInput and DateTimeInput under such a locale now open the bottom sheet instead of the native date control.
[Automated review]
351ec9c to
103c7e5
Compare
591a7f0 to
f11dd36
Compare
103c7e5 to
b83b6c0
Compare
f11dd36 to
479fe46
Compare
b83b6c0 to
296ad4b
Compare
479fe46 to
82c6836
Compare
There was a problem hiding this comment.
Approval waits on an engineering owner's spec decision. The current InternationalizationProvider FR10 and ORD3 and internationalization INV10 say a -u-ca- keyword in the provider locale never selects the calendar, and this pull request intentionally rewrites them. An engineering owner needs to update those records by approving or rejecting the keyword rule, the islamic to islamic-tbla alias, the Gregorian fallback with a warning for an unsupported keyword, and the breaking 0.8.0 class. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner.
Required whatever the decision:
- Regression: the Timestamp test
keeps Gregorian dates for a -u-ca- keyword in the provider locale(Timestamp.test.tsx:1843-1848) now fails because Timestamp writes30 ตุลาคม 2569underth-TH-u-ca-buddhist, so update it to expect the keyword's calendar and add a matching PowerSearch keyword test. - Regression: the Timestamp and PowerSearch records (
Timestamp.spec.md:47and:65-67,PowerSearch.spec.md:90-92) and the Calendars guide (packages/cli/assets/docs/tree/calendar-systems.doc.mjs:30) still say a-u-ca-keyword keeps Gregorian dates, so give them the compatibility line and migration the four date-component records get. - Amend
docs/specs/AST-111-calendar-systems/spec.mdFR2, its example, its Current-state impact bullet, its FR1–FR2 verification row and DEC-2 in this pull request, because they still say the keyword never selects the calendar while the rewritten FR10 and INV10 cite AST-111 FR2 as their basis. - Delete or reword the
-u-ca-sentence in the six pending Changesets that still say such a locale keeps Gregorian dates (calendar-system-boundary.md,calendar-systems-core.md,calendar-typed-entry.md,calendar-presentations.md,calendar-bottom-sheet.mdandcalendar-native-fallback.md), and add tocalendar-locale-keyword.mdthat on touch screens DateInput and DateTimeInput under such a locale now open the bottom sheet instead of the native date control. - Regression: also reword
calendar-systems-formatters.mdandcalendar-schedule.md, which say the keyword keeps Gregorian dates or that a locale never selects the calendar, and add Timestamp, PowerSearch and Lab Schedule dates tocalendar-locale-keyword.md.
Non-blocking: Calendar.spec.md:78-81 still calls the compatibility class "no default ... change" in the bullet that now says the keyword change is breaking.
[Automated review]
| ? resolveCalendarSystem(calendarProp, PROVIDER_NAME) | ||
| : 'gregory', | ||
| [calendarProp], | ||
| : (getExplicitLocaleCalendar(locale, PROVIDER_NAME) ?? 'gregory'), |
There was a problem hiding this comment.
This resolved calendar also reaches Timestamp, PowerSearch and Lab Schedule through useCalendarSystem, so the base's Timestamp test keeps Gregorian dates for a -u-ca- keyword in the provider locale (Timestamp.test.tsx:1843-1848) fails on this head: it receives 30 ตุลาคม 2569. Please update that test, add a PowerSearch keyword test, and amend the Timestamp and PowerSearch compatibility lines.
| | FR6 | Without a provider, the public context and hooks MUST expose locale `en`, direction `ltr`, an empty supplied-catalog map, and a translator backed by shipped English. | Released context and tests | settled | | ||
| | FR7 | The provider MUST preserve a string-returning translator suitable for visible and assistive attributes. | Released catalog/runtime contract | settled | | ||
| | FR8 | A nested provider MUST replace locale, messages, overrides, direction, and calendar with values derived solely from the child provider's own props rather than merge parent context. | Released provider and nested-provider tests | settled | | ||
| | FR10 | The provider MUST resolve its calendar from its `calendar` prop, else an explicit `-u-ca-` keyword in `locale`, else `gregory`, and expose it on the context as `calendar`. A locale's default calendar MUST NOT apply: `fa-IR` alone resolves to `gregory`, and `th-TH-u-ca-buddhist` resolves to `buddhist`. The keyword `islamic` resolves to `islamic-tbla`, as ECMA-402 resolves it; that alias does not apply to a `calendar` prop. The calendar is independent of language, numbering, and direction. `Calendar`, `DateInput`, `DateRangeInput`, and `DateTimeInput` follow the resolved calendar, and a component's own `calendar` prop takes precedence over the provider's. | `spec:AST-111` FR1, FR2 | settled | |
There was a problem hiding this comment.
FR10 names spec:AST-111 FR1, FR2 as its basis, but AST-111 FR2 on this base still says a -u-ca- keyword never selects the calendar. Please add the FR2, example, Current-state impact, verification-row and DEC-2 amendment the description drafts.
| display-calendar override remains a supported explicit caller choice. | ||
| date component shows the calendar that it resolves from its own `calendar` | ||
| prop, the provider's `calendar` prop, or an explicit `-u-ca-` keyword in the | ||
| provider's locale, and otherwise the Gregorian calendar (`spec:AST-111` FR2). |
There was a problem hiding this comment.
INV10 cites spec:AST-111 FR2 for a rule that FR2 still states the other way round on this base; the AST-111 amendment needs to land with this change.
| '@astryxdesign/core': minor | ||
| --- | ||
|
|
||
| [breaking] A `-u-ca-` keyword in the `InternationalizationProvider` `locale` selects the calendar when the provider has no `calendar` prop. `th-TH-u-ca-buddhist` now shows Buddhist years in `Calendar`, `DateInput`, `DateRangeInput`, and `DateTimeInput`, where it showed Gregorian dates before. A component's `calendar` prop and the provider's `calendar` prop still take precedence. The keyword `islamic` resolves to `islamic-tbla`, as ECMA-402 resolves it; a `calendar="islamic"` prop stays an unknown identifier. A keyword outside `CalendarSystem` resolves to Gregorian and warns once in development. A locale without the keyword, such as `fa-IR`, still shows Gregorian dates. Date values stay Gregorian ISO strings. |
There was a problem hiding this comment.
This is the one place release readers learn about the break (spec:AST-017 FR31), but it names only Calendar and the three date fields: Timestamp, PowerSearch and Lab Schedule dates change too, and on touch screens DateInput and DateTimeInput under a keyword locale open the bottom sheet instead of the native date control. Eight other pending Changesets still say the keyword keeps Gregorian dates.
296ad4b to
9c1c0f7
Compare
82c6836 to
294f4a5
Compare
There was a problem hiding this comment.
Approval waits on an engineering owner's spec decision. The current InternationalizationProvider FR10 and ORD3 and internationalization INV10 say a -u-ca- keyword in the provider locale never selects the calendar, and this pull request intentionally rewrites them. An engineering owner needs to update those records by approving or rejecting the keyword rule, the islamic to islamic-tbla alias, the Gregorian fallback with a warning for an unsupported keyword, and the breaking 0.8.0 class. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner.
Required whatever the decision:
- The Timestamp test
keeps Gregorian dates for a -u-ca- keyword in the provider locale(Timestamp.test.tsx:1843-1848) fails on this head because Timestamp now writes30 ตุลาคม 2569underth-TH-u-ca-buddhist, and the Timestamp and PowerSearch records (Timestamp.spec.md:47and:65-67,PowerSearch.spec.md:90-92) and the Calendars guide (calendar-systems.doc.mjs:30) still say the keyword keeps Gregorian dates, so update that test, add a PowerSearch keyword test, and give those records and the guide the compatibility line and migration the four date-component records get. - Amend
docs/specs/AST-111-calendar-systems/spec.mdFR2, its example, its Current-state impact bullet, its FR1–FR2 verification row and DEC-2 in this pull request, because the rewritten FR10 and INV10 cite AST-111 FR2 as their basis while it still says the opposite. - Add the Timestamp, PowerSearch and touch-screen picker changes (the native date control gives way to the bottom sheet under a keyword locale) to
calendar-locale-keyword.md, the one place release readers learn about this break, and reword the "keeps Gregorian dates" sentence in each pending calendar Changeset that will ship in the same release.
[Automated review]
| ? resolveCalendarSystem(calendarProp, PROVIDER_NAME) | ||
| : 'gregory', | ||
| [calendarProp], | ||
| : (getExplicitLocaleCalendar(locale, PROVIDER_NAME) ?? 'gregory'), |
There was a problem hiding this comment.
This resolved calendar also reaches Timestamp and PowerSearch through useCalendarSystem, so the base's Timestamp test keeps Gregorian dates for a -u-ca- keyword in the provider locale (Timestamp.test.tsx:1843-1848) fails on this head: it receives 30 ตุลาคม 2569. Please update that test, add a PowerSearch keyword test, and amend the Timestamp and PowerSearch compatibility lines and the Calendars guide.
| | FR6 | Without a provider, the public context and hooks MUST expose locale `en`, direction `ltr`, an empty supplied-catalog map, and a translator backed by shipped English. | Released context and tests | settled | | ||
| | FR7 | The provider MUST preserve a string-returning translator suitable for visible and assistive attributes. | Released catalog/runtime contract | settled | | ||
| | FR8 | A nested provider MUST replace locale, messages, overrides, direction, and calendar with values derived solely from the child provider's own props rather than merge parent context. | Released provider and nested-provider tests | settled | | ||
| | FR10 | The provider MUST resolve its calendar from its `calendar` prop, else an explicit `-u-ca-` keyword in `locale`, else `gregory`, and expose it on the context as `calendar`. A locale's default calendar MUST NOT apply: `fa-IR` alone resolves to `gregory`, and `th-TH-u-ca-buddhist` resolves to `buddhist`. The keyword `islamic` resolves to `islamic-tbla`, as ECMA-402 resolves it; that alias does not apply to a `calendar` prop. The calendar is independent of language, numbering, and direction. `Calendar`, `DateInput`, `DateRangeInput`, and `DateTimeInput` follow the resolved calendar, and a component's own `calendar` prop takes precedence over the provider's. | `spec:AST-111` FR1, FR2 | settled | |
There was a problem hiding this comment.
FR10 names spec:AST-111 FR1, FR2 as its basis, but AST-111 FR2 still says a -u-ca- keyword never selects the calendar. Please add the FR2, example, Current-state impact, verification-row and DEC-2 amendment the description drafts.
| display-calendar override remains a supported explicit caller choice. | ||
| date component shows the calendar that it resolves from its own `calendar` | ||
| prop, the provider's `calendar` prop, or an explicit `-u-ca-` keyword in the | ||
| provider's locale, and otherwise the Gregorian calendar (`spec:AST-111` FR2). |
There was a problem hiding this comment.
INV10 cites spec:AST-111 FR2 for a rule that FR2 still states the other way round; the AST-111 amendment needs to land with this change.
| '@astryxdesign/core': minor | ||
| --- | ||
|
|
||
| [breaking] A `-u-ca-` keyword in the `InternationalizationProvider` `locale` selects the calendar when the provider has no `calendar` prop. `th-TH-u-ca-buddhist` now shows Buddhist years in `Calendar`, `DateInput`, `DateRangeInput`, and `DateTimeInput`, where it showed Gregorian dates before. A component's `calendar` prop and the provider's `calendar` prop still take precedence. The keyword `islamic` resolves to `islamic-tbla`, as ECMA-402 resolves it; a `calendar="islamic"` prop stays an unknown identifier. A keyword outside `CalendarSystem` resolves to Gregorian and warns once in development. A locale without the keyword, such as `fa-IR`, still shows Gregorian dates. Date values stay Gregorian ISO strings. |
There was a problem hiding this comment.
This is the one place release readers learn about the break (spec:AST-017 FR31), but it names only Calendar and the three date fields: Timestamp and PowerSearch dates change too, and on touch screens DateInput and DateTimeInput under a keyword locale use the bottom sheet instead of the native date control. Pending calendar Changesets that ship in the same release still say the keyword keeps Gregorian dates.
…ndar The provider resolves its calendar from its calendar prop, else an explicit -u-ca- keyword in its locale, else gregory. A component's own calendar prop still comes first. The keyword islamic resolves to islamic-tbla, as ECMA-402 resolves it; the alias does not apply to a calendar prop, so calendar="islamic" stays an unknown identifier. A keyword outside CalendarSystem resolves to gregory and warns once. th-TH-u-ca-buddhist showed Gregorian dates before, so this is breaking: an application that wants Gregorian dates sets calendar="gregory". The provider, Calendar, DateInput, DateTimeInput and DateRangeInput records, architecture INV10, the provider docs, and the story say so.
A [breaking] minor Changeset with the migration. check:changesets rejects it while main declares a patch version; it passes once main declares the 0.8.0 minor.
294f4a5 to
b06bfd5
Compare
github-actions
Bot
added
the
needs:spec-owner-review
PR Analysis Report
Generated by PR Enrichment workflow | View current CI run |
There was a problem hiding this comment.
Approval waits on an engineering owner's spec decision. The current InternationalizationProvider FR10 and ORD3 and internationalization INV10 say a -u-ca- keyword in the provider locale never selects the calendar, and this pull request intentionally rewrites them. An engineering owner needs to update those records by approving or rejecting the keyword rule, the islamic to islamic-tbla alias, the Gregorian fallback with a warning for an unsupported keyword, and the breaking 0.8.0 class. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner.
Required whatever the decision:
- The Timestamp test
keeps Gregorian dates for a -u-ca- keyword in the provider locale(Timestamp.test.tsx:1843-1848) fails on this head because Timestamp now writes30 ตุลาคม 2569underth-TH-u-ca-buddhist, and the Timestamp and PowerSearch records (Timestamp.spec.md:47and:65-67,PowerSearch.spec.md:90-92) and the Calendars guide (calendar-systems.doc.mjs:30) still say the keyword keeps Gregorian dates, so update that test, add a PowerSearch keyword test, and give those records and the guide the compatibility line and migration the four date-component records get. - Amend
docs/specs/AST-111-calendar-systems/spec.mdFR2, its example, its Current-state impact bullet, its FR1–FR2 verification row and DEC-2 in this pull request, because the rewritten FR10 and INV10 cite AST-111 FR2 as their basis while it still says the opposite. - Add the Timestamp, PowerSearch and touch-screen picker changes (the native date control gives way to the bottom sheet under a keyword locale) to
calendar-locale-keyword.md, the one place release readers learn about this break, and reword the "keeps Gregorian dates" sentence in each pending calendar Changeset that will ship in the same release.
Smaller record fixes, not blocking:
- The Calendar and DateInput compatibility classes still say the default is unchanged.
- Miss: the provider record's ownership line still says the calendar resolves from
calendaralone.
[Automated review]
| ? resolveCalendarSystem(calendarProp, PROVIDER_NAME) | ||
| : 'gregory', | ||
| [calendarProp], | ||
| : (getExplicitLocaleCalendar(locale, PROVIDER_NAME) ?? 'gregory'), |
There was a problem hiding this comment.
This resolved calendar also reaches Timestamp and PowerSearch through useCalendarSystem, so the base's Timestamp test keeps Gregorian dates for a -u-ca- keyword in the provider locale (Timestamp.test.tsx:1843-1848) fails on this head: it receives 30 ตุลาคม 2569. Please update that test, add a PowerSearch keyword test, and give the Timestamp and PowerSearch records and the Calendars guide the same compatibility line.
| | FR6 | Without a provider, the public context and hooks MUST expose locale `en`, direction `ltr`, an empty supplied-catalog map, and a translator backed by shipped English. | Released context and tests | settled | | ||
| | FR7 | The provider MUST preserve a string-returning translator suitable for visible and assistive attributes. | Released catalog/runtime contract | settled | | ||
| | FR8 | A nested provider MUST replace locale, messages, overrides, direction, and calendar with values derived solely from the child provider's own props rather than merge parent context. | Released provider and nested-provider tests | settled | | ||
| | FR10 | The provider MUST resolve its calendar from its `calendar` prop, else an explicit `-u-ca-` keyword in `locale`, else `gregory`, and expose it on the context as `calendar`. A locale's default calendar MUST NOT apply: `fa-IR` alone resolves to `gregory`, and `th-TH-u-ca-buddhist` resolves to `buddhist`. The keyword `islamic` resolves to `islamic-tbla`, as ECMA-402 resolves it; that alias does not apply to a `calendar` prop. The calendar is independent of language, numbering, and direction. `Calendar`, `DateInput`, `DateRangeInput`, and `DateTimeInput` follow the resolved calendar, and a component's own `calendar` prop takes precedence over the provider's. | `spec:AST-111` FR1, FR2 | settled | |
There was a problem hiding this comment.
FR10 names spec:AST-111 FR1, FR2 as its basis, but AST-111 FR2 still says a -u-ca- keyword never selects the calendar. Please add the FR2, example, Current-state impact, verification-row and DEC-2 amendment the description drafts.
| display-calendar override remains a supported explicit caller choice. | ||
| date component shows the calendar that it resolves from its own `calendar` | ||
| prop, the provider's `calendar` prop, or an explicit `-u-ca-` keyword in the | ||
| provider's locale, and otherwise the Gregorian calendar (`spec:AST-111` FR2). |
There was a problem hiding this comment.
INV10 cites spec:AST-111 FR2 for a rule that FR2 still states the other way round; the AST-111 amendment needs to land with this change.
| '@astryxdesign/core': minor | ||
| --- | ||
|
|
||
| [breaking] A `-u-ca-` keyword in the `InternationalizationProvider` `locale` selects the calendar when the provider has no `calendar` prop. `th-TH-u-ca-buddhist` now shows Buddhist years in `Calendar`, `DateInput`, `DateRangeInput`, and `DateTimeInput`, where it showed Gregorian dates before. A component's `calendar` prop and the provider's `calendar` prop still take precedence. The keyword `islamic` resolves to `islamic-tbla`, as ECMA-402 resolves it; a `calendar="islamic"` prop stays an unknown identifier. A keyword outside `CalendarSystem` resolves to Gregorian and warns once in development. A locale without the keyword, such as `fa-IR`, still shows Gregorian dates. Date values stay Gregorian ISO strings. |
There was a problem hiding this comment.
This is the one place release readers learn about the break (spec:AST-017 FR31), but it names only Calendar and the three date fields: Timestamp and PowerSearch dates change too, and on touch screens DateInput and DateTimeInput under a keyword locale use the bottom sheet instead of the native date control. Please add both.
User need
An application that passes a locale such as
th-TH-u-ca-buddhistorfa-IR-u-ca-persiantoInternationalizationProvidernames its calendar in the BCP 47 tag it already owns. On the stack below, Astryx ignores that keyword and shows Gregorian dates, so the application must repeat the same choice incalendar. Two inputs that disagree are a source of bugs: the locale says Buddhist, and the date fields say Gregorian. Honoring the keyword lets the tag alone select the calendar, asIntl.DateTimeFormatdoes. Because it changes what an existing locale shows with no code change, it is breaking (spec:AST-017FR1) and ships in a minor release.Problem and solution fit
InternationalizationProviderresolves its calendar as itscalendarprop, then an explicit-u-ca-keyword inlocale, thengregory. A component's owncalendarprop still comes first (useCalendarSystem). This restores the keyword lookup that the stack removed.islamicresolves toislamic-tbla, as ECMA-402 resolves it. The alias applies only to the keyword;calendar="islamic"stays an unknown identifier that resolves togregoryand warns.main's statement that Timestamp, PowerSearch, and Lab's Schedule write their dates in the calendar), the five records' compatibility lines, and thePersianFromLocaleKeywordstory.[breaking]Changeset with the migration.Current specification
component:InternationalizationProviderFR10 and ORD3 (changed here).architecture:internationalizationINV10 (changed here).spec:AST-111FR2 and DEC-2 decide calendar resolution. AST-111 (merged in spec(AST-111): date components use the calendar the application chooses #9605) still says a-u-ca-keyword does not select the calendar. The amendment this needs is below; it joins this pull request before it leaves draft.spec:AST-017FR1 classes the change as breaking; FR6 does not let an approval reclassify it.spec:AST-111amendment this change needsApply to
docs/specs/AST-111-calendar-systems/spec.md, which is onmain(#9605).FR2, replacing the current text:
Example block, replacing the second provider:
Current-state impact: delete the bullet "A provider locale with a
-u-ca-keyword keeps the Gregorian dates …", and add this item to the list under "Gregorian behavior that changes, with itsspec:AST-017class":Verification map, row
FR1–FR2:DEC-2, replacing its last two paragraphs:
Public delta and caller burden
calendarprop on the provider or the component, a-u-ca-keyword in the provider'slocaleselects the calendar. A locale without the keyword, such asfa-IR, still shows Gregorian dates. A keyword outsideCalendarSystem, such asislamic-rgsa, resolves to Gregorian and warns once in development. Values stay Gregorian ISO dates.spec:AST-017FR1). An application whose locale carries a-u-ca-keyword and that wants Gregorian dates setscalendar="gregory".Before (0.7.x):
After (0.8.0):
The caller's one new decision: keep the keyword's calendar, or set
calendar="gregory".Design and alternatives
The provider reads the keyword with
Intl.Locale#calendarand normalizes it through the same identifier check as the prop. Rejected alternatives are recorded inspec:AST-111DEC-2 (amendment above): honoring the keyword in a patch release, and acalendar="from-locale"opt-in.Evidence
packages/core/src/i18n/__tests__/calendarSystem.test.tsx, run withoutTemporal:th-TH-u-ca-buddhist, no propbuddhistth-TH-u-ca-buddhistwith a providercalendar(the Minguo calendar)calendar="japanese"japanesear-u-ca-islamicislamic-tblaar-SA-u-ca-islamic-rgsa(unsupported keyword)gregory, one warningfa-IR, bareth-THgregorycalendar="islamic"propgregory, warningStorybook:
CalendarSystems›PersianFromLocaleKeyword(fa-IR-u-ca-persian, nocalendar) should show Persian months, andLocaleAloneStaysGregorian(fa-IR) Gregorian months. Not yet checked in a browser.Scope
Not yet in this pull request (these records and the guide are now on
main):-u-ca-locale changes their output too.component:Timestampandcomponent:PowerSearchstill say that a-u-ca-keyword keeps Gregorian dates. Add the same compatibility line to both, and a keyword test for each.-u-ca-locale changes its dates too. Its record has no-u-ca-line; its changeset says only that dates stay Gregorian without a provider calendar.calendar-systems.doc.mjsstill says that a-u-ca-keyword keeps Gregorian dates. Replace it with the new resolution order and thecalendar="gregory"migration.Testing
pnpm exec tsc --noEmit -p packages/core: pass.pnpm exec vitest run --maxWorkers=4overpackages/core/src/i18n,docPropLiterals.test.tsand the CLI core prop docs test, after the restack onto currentmain(with Lab's Schedule): 14 files, 136 tests pass. CI runs the full suites.docPropLiterals.test.ts: 5 files, 38 tests pass.pnpm check:knowledge: pass.pnpm check:changesets: rejectscalendar-locale-keyword.mdwith "[breaking] cannot merge while main declares patch 0.7.9. Plan the minor first, or keep the change compatible through deprecation." This is expected untilmaindeclares 0.8.0.mainwith the same two commits.Writing rubric results
component:InternationalizationProviderarchitecture:internationalizationcomponent:Calendarmain's "additive optionalcalendarprop and hook option".component:DateInputcomponent:DateTimeInputcomponent:DateRangeInput