fix(utils): read back calendar text in Latvian, Amharic and Hindi by nynexman4464 · Pull Request #9840 · meta/astryx

nynexman4464 · 2026-11-03T23:48:32Z

User impact

The calendar date parser must read back the text it writes: the committed text and the format hint (spec:AST-111 FR13). In these cases it cannot:

Latvian (lv-LV), Hebrew and all three Hijri calendars: some month names start with a number. Examples are 1. adars (Adar I), 2. adars (Adar II), 1. rabī and 2. džumādā. The parser reads the number as a day, so 5660. g. 2. 1. adars AM is unreadable.
Japanese and Minguo (roc) calendars, where the locale's pattern omits the era: a year without its era reads in the latest era. Amharic 1/1/12 (1 January 1900, 12 years before the Minguo era) reads as 1923. 1/1/33 (Meiji 33) reads as Reiwa 33, which is 2051.
Hindi (hi-IN), Buddhist format hint: the CLDR pattern has a stray backtick, so the hint is 1/1`/2443 बौद्ध संवत. The parser needs one separator between all the numbers, so the hint is unreadable.

The parser is internal, and no public API changes.

Problem and solution fit

Month names that start with a number. The lexicon already keeps a month name that holds a number when the number is not the month's own number, such as Hungarian Réb. 1. But the tokenizer reads a digit as a number before it looks for a name. Now it looks for a known name at a digit too. 1. adars is also day 1 of adars in a common year, so the parser reads it as the day when no other number in the text can be the day. Only a number up to 31 can be the day, so a two-digit year does not count: Latvian Hebrew 86. g. 1. adars reads as 1 Adar 5786. A number before the locale's year word is the year, not a possible day. The lexicon learns the year words from the literal that follows the year in the locale's own formats (g. and gada in lv), so 26. g. 1. adars reads as 1 Adar 5726.
An era where a year without it is ambiguous. This follows the ICU4X year-ambiguity model, with an extension for japanese and roc where the locale's pattern omits the era. A year needs its era only in a calendar whose era changes within the supported range. The formatter derives this from Intl: the era of 1900-01-01 differs from the era of 2100-12-31. On current engines that is japanese (Meiji to Reiwa) and roc (before Minguo to Minguo). No calendar list decides this. In those two calendars only:
- When the short era reorders the fields of a format that omits the era, the formatter tries the narrow era and uses it if it keeps the order. The rule depends on the locale and calendar, not the date, so the hint shows the narrow era for every date, such as Amharic 1/1/8 R and Turkmen 1.1.12 BROC. The lexicon reads the narrow names because it learns era names from the same display options.
- Where every era width reorders the fields, the text keeps the locale's pattern without an era, as before. A date of an earlier era then adds the short era on the side where the era format puts it, such as Colognian BROC 1. Jan. 12 and Amharic 1 ጃን 12 BROC. Dates in the latest era are unchanged.
- Calendars with one era in that range (Buddhist, Persian, Indian, Hebrew, Coptic, both Ethiopic calendars and the three Hijri calendars) keep the base's rule: the short era where it keeps the locale's field order, as in English Persian 8/11/1405 AP, and no era otherwise, as in Turkmen Buddhist 02.11.2569 and Amharic Ethiopic 23/4/2018. Their text is the same as on the base.
Two separators. The lexicon learns the separators of the locale's own numeric hint. Two different separators are accepted when both are from that pattern. feat(core): read typed dates in every calendar #9792 folds a backtick to an apostrophe in all text, ASCII included, so the learned separator and the typed text agree.

Expected behavior and authority

spec:AST-111 FR13 (draft): committed text and the format hint read back as the same date.
spec:AST-111 FR10 (draft) says a japanese or roc format that omits the era gains it, written narrow when that keeps the field order; where every era width reorders the fields, only a date before the latest era gains it, because a year without an era reads in the latest era. The formatter does both.
The round-trip matrix in calendarDateParser.roundtrip.test.ts checks FR13. This change adds the locales above to it.

Smallest restoration

calendarDateParser.ts only: one tokenizer step with a fallback, two learned lexicon sets (separators and year words), one derived era-change check, a narrow-era fallback in the display options, and an earlier-era suffix beside it in the formatter. There are no per-locale or per-calendar rules. The text still goes through Core's plainDateFormat and plainDateFormatToParts, as on the base.
No new API, no new options, and no component changes.

Output changes against the base

Comparison of the base and this branch over every locale that both CLDR 48 lists and Intl.DateTimeFormat.supportedLocalesOf accepts (662), in all 16 calendars, with every 331st day from 1900 through 2100 plus the era boundaries (233 dates), in the hint and the three committed formats: 9,860,560 texts.

Changed: 40,500 texts in 105 locales, all in japanese and roc. No text in any other calendar changes.
- Narrow era in the hint, every date: 30 locales, 13,980 texts. Examples: Amharic 1/1/33 → 1/1/33 M, Turkmen 01.01.12 → 1.1.12 BROC, Asturian 1/1/12 → 1/1/12 A.R.D.C..
- Short era on an earlier-era date: 26,520 texts. The hint in 10 more locales (such as Zulu 1/1/12 → BROC 1/1/12), the date text in 55 locales (Colognian 1. Jan. 12 → BROC 1. Jan. 12), the date_long text in 4 and the date_weekday text in 101.
Read-back: 23,721 of the changed texts did not read back on the base and now do. 9,300 are hints of latest-era dates that read back before and after. 7,479 are earlier-era date_weekday texts (and the date text in bas, dua and dyo) that did not read back on the base and still do not. In 48 of those 53 locales the base cannot read back the latest-era Japanese weekday text either, so the cause is the weekday and month words, not the era. No text that read back on the base fails now.
Unchanged: every Latvian and Hindi text, and every text in ja, en, zh-Hant and th. The parser-side fixes for lv-LV and hi-IN change no output.
One locale is left out: Node 24 (ICU 78) stops the process on any my numeric non-Gregorian date format, on the base too. my is compared in Gregorian, ISO and the lunisolar calendars only.

Evidence

Reproduction before the change: the new focused round-trip test fails for each case. Examples: "5660. g. 2. 1. adars AM" -> unreadable, "1318. g. 3. 1. rabī AH" -> unreadable, "1/1/12" -> 1923-01-01, "1/1/33" -> 2051-01-01, "1/1`/2443 बौद्ध संवत" -> unreadable.
Result after the change: the focused test and the matrix pass. A dense check of every calendar in lv-LV, am-ET and hi-IN, with every seventh day from 1900 through 2100 (every 41st day for chinese and dangi), finds no failures. Dates before 1900 are best effort.
Representative unchanged path: the fa-IR Persian hint is still ۱۴۰۵/۸/۱۱. Latvian 5661. g. 1. adars is still 1 Adar 5661 (20 February 1901), 86. g. 1. adars is still 1 Adar 5786 (18 February 2026), and 26. g. 1. adars is still 1 Adar 5726 (21 February 1966), as on the base.
Regression test or other mutation-sensitive proof: the focused test has a date for each failure, plus the common-year 1. adars case that guards the day fallback, 86. g. 1. adars, which fails when a two-digit year counts as a possible day, and 26. g. 1. adars, which reads as 26 Adar I 5787 (5 March 2027) when a number before the year word counts as a possible day. The matrix adds lv-LV for Hebrew and the Hijri calendars, am-ET for roc and japanese, and hi-IN for Buddhist. The focused test reads back am-ET and Colognian (ksh) dates in the current and earlier eras, checks the narrow era in the hint (1/1/8 R, 1/1/2 H), and checks that single-era hints get no era (Amharic Ethiopic 23/4/2018, Turkmen Buddhist 02.11.2569).

Scope

One defect is restored.
Separable contradictory or unsettled tagalongs were removed or split.
No new public API, visual representation, default, or interaction model is hidden under the bug-fix label.
Public text and artifacts contain no internal Meta context.

Testing

pnpm exec vitest run --maxWorkers=2 over the parser's test files (unit and round trip) plus docPropLiterals.test.ts: 3 files, 96 tests pass. CI runs the full suites.
pnpm exec tsc --noEmit in packages/core: passes.
pnpm check:knowledge and pnpm check:changesets: pass.
node scripts/pre-review.mjs --base origin/main: 204 authored lines.
No browser test: the change is in text parsing and formatting only, with no layout, focus or input-modality dependence.

Writing rubric results

No knowledge record is touched.

vercel · 2026-11-03T23:48:34Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
astryx	Ready	Preview	Nov 5, 2026 2:38am UTC

astracat-bot · 2026-11-03T23:49:14Z

AI review status for this pull request.

Review status	Updated
🔄 In progress (for maintainers only)	Nov 5, 2026, 2:38 AM UTC

astracat-bot

Approval waits on an engineering owner's spec decision: these parser changes rest on spec:AST-111 FR9, FR10 and FR13, which are still draft and not on main, where the internationalization architecture (INV10) keeps date parsing Gregorian.

The decision needs to cover these choices:

1. adars reads as day 1 of Adar when no other number in the text can be the day.
Where the short era reorders a format's fields and the narrow era does not, the narrow era is written for every date: every Amharic era-calendar hint (1/1/8 R, 23/2/2019 AM) and the same hints in about 25 other languages, such as Turkmen 02.11.2569 → 2.11.2569 BE.
Where every era width reorders the fields, a date before the latest era gets the short era at one end of the text, such as Amharic 1 ጃን 12 BROC; this also changes committed text in other locales, such as Colognian BROC 1. Jan. 12.

An engineering owner records the decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so if they are an engineering owner; otherwise this waits until AST-111 is current on main.

Non-blocking: the description says no committed text and no other locale changes, but against the base the Amharic date text gains the era for earlier-era dates (1 ጃን 33 → 1 ጃን 33 Meiji) and both era rules reach locales outside the 34 compared; please correct it so the decision covers them.

[Automated review]

astracat-bot · 2026-11-04T00:28:20Z

+  // When every era width reorders the fields, such as the Amharic short-month
+  // date, the text has no era. Text without an era reads in the latest era,
+  // so a date of an earlier era adds it on the side where the era format has
+  // it.


Non-blocking (comment style): the second sentence is 27 words and joins two topics. A shorter form that keeps the reason: "Text without an era reads in the latest era. So a date of an earlier era adds the era. It goes at the start or the end, as in the era format."

astracat-bot

Approval waits on an engineering owner's spec decision: these parser changes rest on spec:AST-111 FR9, FR10 and FR13, which are still draft and not on main, where the internationalization architecture (INV10) keeps date parsing Gregorian.

The decision needs to cover these choices:

1. adars reads as day 1 of Adar when no other number in the text can be the day.
In the Japanese and Minguo calendars, a hint whose short era reorders the fields and whose narrow era does not shows the narrow era for every date, in 30 locales (Amharic 2/11/8 → 2/11/8 R, Turkmen 02.11.8 → 2.11.8 R).
In those calendars, where every era width reorders the fields, only a date before the latest era gets the short era at one end (Colognian 1. Jan. 12 → BROC 1. Jan. 12), in 104 locales; a current-era date keeps no era, while draft FR10 says such a format gains it.

An engineering owner records the decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so if they are an engineering owner; otherwise this waits until AST-111 is current on main.

Non-blocking: the description still says the other Amharic hints gain an era (23/2/2019 AM) and that no committed text or other locale changes, but now only Japanese and Minguo text changes, including committed text in 103 locales such as Amharic and Colognian; please update it so the decision covers what the pull request does.

[Automated review]

astracat-bot · 2026-11-04T19:00:37Z

+ * the fields. Where the era changes, a narrow era that keeps the order is
+ * used instead, such as Amharic Japanese "1/1/8 R".


Non-blocking (comment style): "a narrow era that keeps the order is used instead" is passive. An active form: "Where the era changes, it uses a narrow era that keeps the order instead, such as Amharic Japanese "1/1/8 R"."

astracat-bot

Approval waits on an engineering owner's spec decision: these parser changes rest on spec:AST-111 FR9, FR10 and FR13, which are still draft and not on main, where the internationalization architecture (INV10) keeps date parsing Gregorian.

The decision needs to cover these choices:

1. adars reads as day 1 of Adar when no other number in the text can be the day.
In the Japanese and Minguo calendars, a hint whose short era reorders the fields and whose narrow era does not shows the narrow era for every date, in 30 locales (Amharic 2/11/8 → 2/11/8 R, Turkmen 02.11.8 → 2.11.8 R).
In those calendars, where every era width reorders the fields, only a date before the latest era gets the short era at one end (Colognian 1. Jan. 12 → BROC 1. Jan. 12), in 104 locales; a current-era date keeps no era, while draft FR10 says such a format gains it.

An engineering owner records the decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so if they are an engineering owner; otherwise this waits until AST-111 is current on main.

[Automated review]

nynexman4464 · 2026-11-04T22:37:07Z

/approve-spec be112b6

astracat-bot

Approved: an engineering owner approved spec:AST-111 FR9, FR10 and FR13 for this head with /approve-spec, and the parser changes match them. The new round-trip cases for Latvian month names that start with a number, Japanese and Minguo dates of an earlier era, and the Hindi Buddhist hint fail before the change and pass after it. CI's test workflows run only for pull requests into main, so they have not run on this head; they run when the calendar-parser branch goes to main.

[Automated review]

astracat-bot

Approval waits on an engineering owner's spec decision at this head: these parser changes rest on spec:AST-111 FR9, FR10 and FR13, which are still draft on main, and the earlier /approve-spec named the previous head, so it does not carry over to this rebased head. The decision covers the same three choices as before:

1. adars reads as day 1 of Adar when no other number in the text can be the day.
In the Japanese and Minguo calendars, the narrow era is written for every date where the short era reorders the fields, such as Amharic 2/11/8 → 2/11/8 R and Asturian 1/1/12 → 1/1/12 A.R.D.C..
Where every era width reorders the fields, only a date before the latest era gains the short era at one end, such as Colognian 1. Jan. 12 → BROC 1. Jan. 12.

An engineering owner records the decision by commenting /approve-spec <full head SHA> on this pull request (the author may do so as an engineering owner), or AST-111 moves to current on main. No other issue was found.

[Automated review]

astracat-bot

Approval waits on an engineering owner's spec decision, and one parser fix is needed first.

Spec decision: these parser changes rest on spec:AST-111 FR9, FR10 and FR13, which are still draft on main, and the earlier /approve-spec named a previous head, so the decision is needed again for the 1. adars day reading, the narrow era where the short era reorders the fields (such as Amharic 2/11/8 → 2/11/8 R), and the short era on earlier-era dates where every era width reorders them (such as Colognian 1. Jan. 12 → BROC 1. Jan. 12).
Miss: calendarDateParser.ts line 714 counts a two-digit year as a possible day, so Latvian Hebrew 86. g. 1. adars, which reads as 1 Adar 5786 on the base, is now unreadable; counting only numbers up to 31 fixes it, and that input belongs in the per-date tests.

The fix makes a new head. An engineering owner then records the decision by commenting /approve-spec <full head SHA> on this pull request for that head, and the author may do so as an engineering owner. Making AST-111 current on main also settles it.

[Automated review]

astracat-bot · 2026-11-04T23:36:11Z

  }
+  // Latvian "1. adars" is a month, and also day 1 of "adars". It is the day
+  // when no other number can be the day.
+  if (hasDigitName && !out.some(t => t.t === 'num' && t.v.length <= 2)) {


Miss: this counts a two-digit year as a possible day. Latvian Hebrew 86. g. 1. adars reads as 1 Adar 5786 on the base, and on this head it is unreadable (Adar I with day 86). Counting only numbers that can be a day keeps the stated rule:

if ( hasDigitName && !out.some(t => t.t === 'num' && t.v.length <= 2 && Number(t.v) <= 31) ) {

nynexman4464 · 2026-11-05T01:00:23Z

/approve-spec 4ffa79b

astracat-bot

Changes requested: one parser fix is needed before this can be approved.

Miss: calendarDateParser.ts:711 counts a two-digit year of 31 or less as a possible day, so typed Latvian Hebrew 26. g. 1. adars reads as 26 Adar I 5787 (5 March 2027) instead of 1 Adar 5726 (21 February 1966) as on the base; treat a number followed by the locale's year word (g.) as the year and add this case to the per-date tests.

The era and separator changes cause no read-back regression in the sampled texts, and spec:AST-111 FR9, FR10 and FR13 were accepted for this head. A new commit invalidates that acceptance, so an engineering owner (the author may, as one) records /approve-spec <full head SHA> again on the head that carries the fix.

[Automated review]

astracat-bot · 2026-11-05T01:18:16Z

  }
+  // Latvian "1. adars" is a month, and also day 1 of "adars". It is the day
+  // when no other number can be the day.
+  if (hasDigitName && !out.some(t => t.t === 'num' && Number(t.v) <= 31)) {


Miss: a two-digit year of 31 or less still counts as a possible day here. Typed Latvian Hebrew 26. g. 1. adars reads as 26 Adar I 5787 (5 March 2027); the base reads 1 Adar 5726 (21 February 1966). 05. g. 1. adars and 10. g. 1. adars move the same way, and 31. g. 1. adars is rejected. A number followed by the locale's year word (g., the literal after the year in its own formats) is the year, so it should not count:

if (hasDigitName && !out.some(t => t.t === 'num' && !t.isYear && Number(t.v) <= 31)) {

Please add 26. g. 1. adars to the per-date cases.

nynexman4464 · 2026-11-05T02:01:13Z

/approve-spec 2f262b5

astracat-bot

Changes requested: one parser fix is needed before this can be approved.

Miss: calendarDateParser.ts:711 still counts a two-digit year of 31 or less as a possible day, so typed Latvian Hebrew 26. g. 1. adars reads as 26 Adar I 5787 (5 March 2027) instead of 1 Adar 5726 (21 February 1966) as on the base; treat a number followed by the locale's year word (g.) as the year and add this case to the per-date tests.

The era and separator changes cause no read-back regression in the sampled texts, and spec:AST-111 FR9, FR10 and FR13 are accepted for this head. A new commit needs that acceptance again, so an engineering owner (the author may, as one) comments /approve-spec <full head SHA> on the head that carries the fix.

[Automated review]

Month names that start with a number in Latvian Hebrew and Hijri dates, Minguo and Japanese dates of an earlier era in Amharic, and the Hindi Buddhist format hint do not read back as the same date.

Read a month name that starts with a number, and read it as a day and a month when no other number can be the day. Accept the separators of the locale's own numeric pattern, and fold a backtick in ASCII text as in other text. When the era would reorder the fields, write it beside them for a date of an earlier era.

When a locale's numeric pattern has no era and the short era reorders the fields, try the narrow era and use it if it keeps the locale's order. Amharic format hints then always show the era, such as 1/1/8 R in the Japanese calendar, so the text reads back in the right era. Formats where every era width reorders the fields keep the earlier-era step.

The narrow-era fallback and the earlier-era suffix now apply only to calendars whose era of 1900-01-01 differs from that of 2100-12-31, which Intl reports for `japanese` and `roc`. Single-era calendars write the same text as on the base. The display text comes from `format()` again: its spaces can differ from the joined `formatToParts()` values, such as before the Bulgarian and Russian year suffix.

Only a number up to 31 can be the day, so Latvian Hebrew "86. g. 1. adars" reads as 1 Adar 5786 again.

Latvian Hebrew "26. g. 1. adars" reads as 1 Adar 5726 again. The parser learns the year word ("g.", "gada") from the literal that follows the year.

nynexman4464 · 2026-11-05T02:31:13Z

/approve-spec 4c8a492

meta-cla Bot added the CLA Signed This label is managed by the Meta Open Source bot. label Nov 3, 2026

vercel Bot deployed to Preview November 3, 2026 23:57

View deployment

vercel Bot deployed to Preview November 4, 2026 00:14

View deployment

astracat-bot Bot reviewed Nov 4, 2026

View reviewed changes

nynexman4464 force-pushed the nynexman4464/feat/calendar-date-parser branch from 96920a3 to f81d686 Compare November 4, 2026 18:42

nynexman4464 force-pushed the nynexman4464/fix/calendar-parser-more-locales branch from 39fd607 to 2ab4887 Compare November 4, 2026 18:42

vercel Bot deployed to Preview November 4, 2026 18:52

View deployment

astracat-bot Bot reviewed Nov 4, 2026

View reviewed changes

nynexman4464 force-pushed the nynexman4464/feat/calendar-date-parser branch from f81d686 to 18150b8 Compare November 4, 2026 19:47

nynexman4464 force-pushed the nynexman4464/fix/calendar-parser-more-locales branch from 2ab4887 to 4c881d8 Compare November 4, 2026 19:47

astracat-bot Bot reviewed Nov 4, 2026

View reviewed changes

vercel Bot deployed to Preview November 4, 2026 19:56

View deployment

nynexman4464 mentioned this pull request Nov 4, 2026

feat(core): read typed dates in every calendar #9792

Merged

4 tasks done

nynexman4464 marked this pull request as ready for review November 4, 2026 21:29

nynexman4464 requested review from cixzhang, imdreamrunner and josephfarina as code owners November 4, 2026 21:29

nynexman4464 force-pushed the nynexman4464/feat/calendar-date-parser branch from 18150b8 to f02913f Compare November 4, 2026 22:30

nynexman4464 force-pushed the nynexman4464/fix/calendar-parser-more-locales branch from 4c881d8 to be112b6 Compare November 4, 2026 22:31

vercel Bot deployed to Preview November 4, 2026 22:40

View deployment

astracat-bot Bot approved these changes Nov 4, 2026

View reviewed changes

nynexman4464 force-pushed the nynexman4464/feat/calendar-date-parser branch from f02913f to e38dac1 Compare November 4, 2026 22:54

nynexman4464 force-pushed the nynexman4464/fix/calendar-parser-more-locales branch from be112b6 to 8427f88 Compare November 4, 2026 22:54

vercel Bot deployed to Preview November 4, 2026 23:01

View deployment

astracat-bot Bot reviewed Nov 4, 2026

View reviewed changes

nynexman4464 force-pushed the nynexman4464/feat/calendar-date-parser branch from e38dac1 to 0d0e06d Compare November 4, 2026 23:15

nynexman4464 force-pushed the nynexman4464/fix/calendar-parser-more-locales branch from 8427f88 to 4d2cb31 Compare November 4, 2026 23:15

vercel Bot deployed to Preview November 4, 2026 23:29

View deployment

astracat-bot Bot reviewed Nov 4, 2026

View reviewed changes

nynexman4464 force-pushed the nynexman4464/feat/calendar-date-parser branch from 0d0e06d to ce48c99 Compare November 5, 2026 00:58

nynexman4464 force-pushed the nynexman4464/fix/calendar-parser-more-locales branch from 4d2cb31 to 4ffa79b Compare November 5, 2026 00:58

vercel Bot deployed to Preview November 5, 2026 01:07

View deployment

astracat-bot Bot requested changes Nov 5, 2026

View reviewed changes

nynexman4464 force-pushed the nynexman4464/feat/calendar-date-parser branch from ce48c99 to 295c13c Compare November 5, 2026 02:00

nynexman4464 force-pushed the nynexman4464/fix/calendar-parser-more-locales branch from 4ffa79b to 2f262b5 Compare November 5, 2026 02:00

vercel Bot deployed to Preview November 5, 2026 02:07

View deployment

astracat-bot Bot requested changes Nov 5, 2026

View reviewed changes

nynexman4464 changed the base branch from nynexman4464/feat/calendar-date-parser to main November 5, 2026 02:20

nynexman4464 closed this Nov 5, 2026

nynexman4464 reopened this Nov 5, 2026

nynexman4464 added 7 commits November 4, 2026 18:21

test(utils): round-trip calendar text in Latvian, Amharic and Hindi

a017e48

Month names that start with a number in Latvian Hebrew and Hijri dates, Minguo and Japanese dates of an earlier era in Amharic, and the Hindi Buddhist format hint do not read back as the same date.

docs(utils): shorten two era comments in the calendar parser

a6dc261

fix(utils): a two-digit year does not stop a Latvian digit month name

d1ef5ec

Only a number up to 31 can be the day, so Latvian Hebrew "86. g. 1. adars" reads as 1 Adar 5786 again.

fix(utils): a number before the year word is the year, not a Latvian day

4c8a492

Latvian Hebrew "26. g. 1. adars" reads as 1 Adar 5726 again. The parser learns the year word ("g.", "gada") from the literal that follows the year.

nynexman4464 force-pushed the nynexman4464/fix/calendar-parser-more-locales branch from 2f262b5 to 4c8a492 Compare November 5, 2026 02:31

vercel Bot deployed to Preview November 5, 2026 02:38

View deployment

		* the fields. Where the era changes, a narrow era that keeps the order is
		* used instead, such as Amharic Japanese "1/1/8 R".

Conversation

nynexman4464 commented Nov 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

User impact

Problem and solution fit

Expected behavior and authority

Smallest restoration

Output changes against the base

Evidence

Scope

Testing

Writing rubric results

Uh oh!

vercel Bot commented Nov 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

astracat-bot Bot commented Nov 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

astracat-bot Bot left a comment

Choose a reason for hiding this comment

Uh oh!

astracat-bot Bot Nov 4, 2026

Choose a reason for hiding this comment

Uh oh!

astracat-bot Bot left a comment

Choose a reason for hiding this comment

Uh oh!

astracat-bot Bot Nov 4, 2026

Choose a reason for hiding this comment

Uh oh!

astracat-bot Bot left a comment

Choose a reason for hiding this comment

Uh oh!

nynexman4464 commented Nov 4, 2026

Uh oh!

astracat-bot Bot left a comment

Choose a reason for hiding this comment

Uh oh!

astracat-bot Bot left a comment

Choose a reason for hiding this comment

Uh oh!

astracat-bot Bot left a comment

Choose a reason for hiding this comment

Uh oh!

astracat-bot Bot Nov 4, 2026

Choose a reason for hiding this comment

Uh oh!

nynexman4464 commented Nov 5, 2026

Uh oh!

astracat-bot Bot left a comment

Choose a reason for hiding this comment

Uh oh!

astracat-bot Bot Nov 5, 2026

Choose a reason for hiding this comment

Uh oh!

nynexman4464 commented Nov 5, 2026

Uh oh!

astracat-bot Bot left a comment

Choose a reason for hiding this comment

Uh oh!

nynexman4464 commented Nov 5, 2026

Uh oh!

This branch was successfully deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

nynexman4464 commented Nov 3, 2026 •

edited

Loading

vercel Bot commented Nov 3, 2026 •

edited

Loading

astracat-bot Bot commented Nov 3, 2026 •

edited

Loading