[rtibblesbot]

Summary

• Numeric answers are read and shown in the exercise language (fallback: channel, then UI), stored as canonical xsd:double
• Non-canonical stored answers (1.50, -0) save once, canonically, when opened
• Digits NumberParser can't read are flagged invalid
• Closed question cards show Incomplete for stored errors of any question type

References

Fixes #6198. See #6150.

Reviewer guidance

State	Before	After
fr, stored 1234.5 and 30
ar-EG, same item
fr, typing 1,5 (stores 1.5)

Seeded through /api/sync/:

• Opening 1.50 or -0 sends one change; reopening, none.
• Numeric → Text entry → Numeric keeps single cardinality and a qti-mapping.

Open risks:

• German reads the period as grouping: 1.234 → 1234.
• After a language change, unedited answers save as stored.
• Stored non-xsd:double answers stay flagged until opened.

QA team: Numeric answers use the number format of the exercise language. Regressions are most probable when the Response type changes in German or Arabic.

1. German: In a Deutsch (de) exercise, give a Numeric question the answers 1,5, 0,5 and -0,5. Set Response type to Text entry. The answers show 1.5, 0.5 and -0.5. Set it back to Numeric. The answers show 1,5, 0,5 and -0,5.
2. Text entry to Numeric: In the German question, set Response type to Text entry. Replace the answers with 1,5, 1.000 and apple. Set Response type to Numeric. The answers show 1,5, 1 and apple. Only apple shows Must be a valid number.
3. Arabic: In an Arabic (ar-EG) exercise, give a Numeric question the answer -0.5. It shows -٠٫٥. Set Response type to Text entry. The answer shows -0.5. Set it back to Numeric. The answer shows -٠٫٥.
4. Reopen: Close each exercise and open the question again. The answers do not change.
5. Mixed digits: In a فارسی (fa) exercise, give a Numeric question the answer 7.5. Type 1 at the end and press Tab. Must be a valid number shows.
6. Incomplete: Add a Single choice question with no correct answer and a Numeric question with the answer abc. Both cards show Incomplete.

Look out for:

• In a Deutsch (de) exercise, type 0.5 as a Numeric answer. It shows 5. Is this acceptable?

Manual QA cannot reach answers stored outside the editor. Look at the ar-EG captures under Evidence.

Evidence

Answers stored outside the editor, ar-EG exercise

Step	Screenshot
Opened: ١٫٥, ٠, -٠٫٥, ٠٫٠٠٠٠٠٠١٢٣, minus on the left
Text entry: 1.5, 0, -0.5, 0.000000123

Switch question type between Numeric and Text entry in German (de) and Arabic (ar-EG) exercises

Step	Screenshot
ar-EG, stored -0.5, Text entry and back to Numeric: -٠٫٥

6198rt-de-roundtrip.webm

Numeric to Text entry and back, de exercise

Step	Screenshot
0.5 shows 5; 123.456,78 shows 123456,78

s2-de-numeric-text-entry-round-trip.webm

Mixed and foreign digits

Step	Screenshot
fa: ۷٫۵1 flagged invalid; 8.25 shows ۸٫۲۵
th: ๗.๕ flagged invalid

s3-arEG-type-save-reopen.webm

Closed question cards

Step	Screenshot
Incomplete on questions with stored errors only

More captures (23)

Step	Screenshot
ar-EG, stored -0.5 opened in Numeric
ar-EG, Text entry: -0.5
ar-EG, reopened in Numeric
de, typed in Text entry, back to Numeric: 1,5
de, reopened in Numeric
de, Text entry after reopening
ar-EG, reopened: same display
fr, Text entry: stored ASCII values
de, opened: 1,5, 0,5
de, Text entry: 1.5, 0.5
de, back to Numeric: 1,5, 0,5
de, reopened: 5, 123456,78
ar-EG, stored 7.5: ٧٫٥
ar-EG, ٧٫٥1 flagged invalid
ar-EG, 7.51 added: ٧٫٥١
ar-EG, reopened: values as shown
fa, stored 7.5: ۷٫۵
bn, stored 7.5: ৭.৫
bn, ৭.৫1 flagged invalid; 8.25 shows ৮.২৫
en, 1٣ flagged invalid
Numeric abc opened: invalid-number message
Single choice opened: Choose a correct answer
Correct answer selected: no Incomplete

AI usage

Claude Code planned and implemented the change from the issue's rules. Verified with the QTIEditor and channelEdit Jest suites, pre-commit, and screenshots of the editor in a headless browser.

🤖 Generated with Claude Code

Deviations from the issue spec

Criterion	Why not
Stored answers display in the language's own digits	Display uses Intl's default digits: ar-EG shows ٣٠, but Chrome's ar and ur show Latin digits

---

Written by rtibblesbot, an LLM-based coding agent.

🟡 Waiting for feedback Last updated: 2026-10-13 21:57 UTC

[AlexVelezLl]

blocking: storedValue treats every answer as stored, including ones stored under a string declaration. Repro in a French exercise: make a Text entry question with the answer 1,5 and save it. Then switch it to Numeric. The editor shows 1,5 with "Must be a valid number (e.g. 12; 0,5; -3,14)". The message contradicts itself, since its own example has the same shape. buildXML also writes <qti-value>1,5</qti-value> into the float declaration.

The cause: uneditedIds includes the text answer, so storedValue returns the raw 1,5 and skips readLocaleNumber. The storedErrors check at line 67 then flags it because it isn't an xsd:double.

The reasoning in the comment at line 58 holds for answers already stored as numbers. A Text entry answer was never a stored number, though. Could you limit uneditedIds and storedErrors to answers parsed from a base-type="float" declaration? Then a switched answer is read in the exercise language like a typed one, and 1,5 stores 1.5.

[AlexVelezLl]

Let's drop all this storedValue overhead. Users must always see the actual stored value; e.g., if the user wrote "123.456,78" on blur, they should see "123456,78"; also, on language change, change from text entry to numeric, etc.

[rtibblesbot]

Dropped storedValue, storedErrors and the stored/shown swap (0c2d8cd). A Numeric answer now shows its stored value in the exercise language:

• On open: the stored value, formatted.
• On switching to Numeric and on leaving an answer: read in the language, then formatted (123.456,78 → 123456,78 in German).
• On a language change: the editor already remounts and re-parses the stored XML.

Your French repro now shows 1,5, no error, and stores 1.5 (captures). uneditedIds/storedById/storedValue were the only stored-vs-shown special cases; all removed.

One consequence: a legacy float answer stored as 1,5 reads fine in French, so its card in view mode no longer shows Incomplete; opening it rewrites it as 1.5. I dropped the four QTIItemEditor tests asserting that indicator. Should view mode still flag stored answers that aren't xsd:double?

[AlexVelezLl]

suggestion: You list this as an open question, so here's what I found. In German, 1.5 gets INVALID_NUMERIC_VALUE in the editor. It's written as 1.5, though, so validateQtiItem passes it and the question doesn't count as incomplete. That's the same split #6150 (and now #6257) closed. When the question is reopened, parse formats the stored 1.5 as 1,5, and the error is gone.

The error only lasts until the editor re-parses, and the stored value is 1.5 either way. Would it be simpler to accept it, as French already does? Dropping the !grouped condition in readLocaleNumber would do that. 1.234 would still read as grouped in German, and 1.5 would read as 1.5. Then the editor, headless validation and the reopened view all agree.

[rtibblesbot]

Done (b74a1bf): readLocaleNumber falls back to xsd:double whenever the language can't read the text, so German 1.5 reads as 1.5 and 1.234 as 1234. Searched localeNumbers.js, validation.js and parse.js for other spots where the editor and headless validation disagree on an xsd:double; the !grouped check was the only one. The German, Spanish and Italian cases moved to the "reads xsd:double" test, and de 1.5 joined the headless-agreement table in validateItem.spec.js.

[AlexVelezLl]

suggestion: When the exercise's own language isn't supported, this returns '' without trying the channel's language. In Node's full ICU, 94 of the 286 ids in Languages.js aren't supported (ach, nv, dty, …). So a Navajo exercise in a French channel reads answers as xsd:double only, not French. The qaa test locks this in. Was that intended? If not, you could take the first supported candidate:

const candidates = [node?.language, channel?.language, currentLanguage].filter(Boolean);
return candidates.find(l => Intl.NumberFormat.supportedLocalesOf([l]).length) ?? '';

[rtibblesbot]

Not intended. Taken as suggested (8ab5361). The qaa test now expects the channel language, plus a case where both fall through to the UI language. exerciseLanguage is the only place the order is decided; ResourcePanel and useAssessmentItems both call it.

[AlexVelezLl]

suggestion: Two fragile spots here:

• The storedValue closure on line 24 reads uneditedIds and storedById, but both are declared later, at lines 35 and 60. It only works because useInteraction builds the XML in a lazy computed. Anything that reads bodyXml during setup would throw a TDZ ReferenceError.
• The declarations are parsed twice, once with language and once without, and the results are paired by index.

Could parse stay language-free? This composable could parse once and set shown = formatLocaleNumber(stored, language) per answer, and the answer ids would line up for free. It would also drop the language option from parse/_extractAnswers/extractNumericAnswers. Display formatting is a concern of the editor, not of reading the XML.

[rtibblesbot]

Done (0c2d8cd). parse, _extractAnswers and extractNumericAnswers no longer take a language; useInteraction passes options to buildXML and validate only. The composable formats the parsed answers once, so there's no second parse, no index pairing, and no closure over later declarations.

[AlexVelezLl]

nitpick: Switching to ; avoids clashing with comma decimals, but the English source now reads "e.g. 12; 0.5; -3.14". Quoting each example avoids the clash and keeps normal commas:

errorInvalidNumericValue: {
  message: 'Must be a valid number (e.g. "{integer}", "{decimal}", "{negative}")',
  context:
    'Validation error shown when an answer value is not a valid number. The placeholders are example numbers written the way the exercise language writes them, and may contain commas or periods. Keep each one inside quotation marks, using the quotation marks your language normally uses.',
},

Use double quotes, not single quotes: in ICU ' is the escape character, so '{integer}' would print the literal placeholder.

[rtibblesbot]

Taken as suggested (0c2d8cd). It's the only string with number placeholders.

[rtibblesbot]

French exercise, live editor after 8ab5361:

State	Screenshot
Text entry 1,5 switched to Numeric: shows 1,5, no error, stores 1.5
1 234,5 typed, before leaving the field
After leaving the field: 1234,5
1,2,3: quoted examples

fr-blur.webm

[rtibbles]

Slight change of approach to limit the amount of code we need to maintain ourselves.

[rtibbles]

I think we can probably not have to implement this all ourselves here. This package: https://react-aria.adobe.com/internationalized/number/NumberParser provides most of the number parsing that we require (and can even do some additional number formatting too for display). I think we should lean on this, and drop the requirements that it can't meet (like the very strict separator parsing).

This is a well maintained and active library, so I feel confident this will be easier for us to use going forwards. We should also flag this for similar things on the Kolibri side, so that it can be using the same library and reduce internal code needs.

[rtibblesbot]

Done in 87d076b: localeNumbers.js now wraps NumberParser / NumberFormatter, and the vendored numerals.js is gone. I searched the branch for other hand-written parsing and found those 2 files; both changed. parseXsdDouble stays, since it checks the stored format.

Dropped requirements:

• Group separators are accepted anywhere: English 1,23 stores 123, German 1.5 stores 15.
• Digits: the language's own plus the 6 systems NumberParser detects, instead of every Unicode \p{Nd}.
• Answers read in a language store String(number), so French 1,50 stores 1.5. A plain xsd:double the language can't read (French 1.5) is still stored as typed.

I drafted an edit to #6198 with these changes, and a Kolibri follow-up for the QTI text entry. It will be linked here once filed.

[rtibblesbot]

Tracked in learningequality/kolibri#15387, which already covers this.

[rtibblesbot]

Updated #6198 as the review asked:

• Parsing moved to @internationalized/number. Requirements it can't meet are dropped.
• Group separators accepted anywhere. English 1,23 now stores 123 instead of being rejected.
• Digits narrowed. Only the language's own digits and the numbering systems NumberParser detects are read, not every Unicode numbering system.

---

Written by rtibblesbot, an LLM-based coding agent.

[AlexVelezLl]

Why did we bring back all the stored, untouchedIds, etc. logic that we had previously dropped?

[rtibblesbot]

Dropped untouchedIds in b7d2778. A language change now reads each answer as shown in the old language and reshows it in the new one.

stored stays. It only keeps an unedited answer's stored form in buildXML. Without it, opening 1.50, 1E3 or 0012 in French saves 1.5, 1000 or 12, because opening an item syncs any change. The does not save a numeric answer stored as xsd:double on opening tests cover this.

Searched the QTIEditor tree for other per-answer tracking (untouched, stored). The only other match is numericMapKey, the stored use above.

[AlexVelezLl]

Code changes look good, tests provide good confidence, manual QA checks out, and the localeNumbers.js delegates to @internationalized/number for number parsing/formatting, dropping requirements it can't meet.

Comments addressed.

[rtibblesbot]

Quick check on rtibblesbot's work on this PR: react 👍 helpful · 😕 mixed · 👎 not helpful. Reply with anything specific.

[AlexVelezLl]

QA Steps

Numeric answers are now typed and shown in the number format of the exercise's language (1,5 in German, Arabic digits in ar-EG) and saved in one standard form.

1. German. In Details, set Language to Deutsch (de). Add a Numeric question with 1,5, -0,5 and 0.5. Close and reopen. Expected: 1,5 and -0,5 show as typed; 0.5 becomes 5, which is expected because the period is the German thousands separator. No Must be a valid number or Incomplete.
2. Switching type. Set Response type to Text entry, then back to Numeric. In Text entry, add apple before switching back. Expected: Text entry shows 1.5; Numeric shows 1,5 again; only apple shows Must be a valid number.
3. Other languages. Repeat the first two steps in a few other exercise languages, for example ar-EG (-0.5), French (1 234,5), Hindi (३०) or any you know. Expected: answers show in that language's format, read back the same after reopening, and valid numbers aren't flagged. Separator conversions like German's are expected.
4. Kolibri. In an English exercise, save 2.50 and 1,000. Publish, then answer 2.5 and 1000 in Kolibri. Expected: both are marked correct.

---

_{🤖 This comment was posted by Claude under my supervision, to find the PRs that needed QA and to review the steps QA should test.}

[pcenov]

Manual QA checks out - implemented as specified.