Internationalizing Math Notation: Numbers, Symbols, and Long Division Across Five Languages

Notation matrix

Convention	en-US	en-GB	es-MX	es-ES	fr-FR	pt-BR	pt-PT	de-DE	Source
Decimal separator	.	.	.	,	,	,	,	,	[1]
Digit grouping separator (common practice)	, (1,234,567)	,	,	. (1.234.567)	space/. (1 234 567)	.	.	.	[1]
BIPM-recommended grouping	thin space	thin space	thin space	thin space	thin space	thin space	thin space	thin space	[1]
List separator when comma is decimal	,	,	,	; (to avoid clash)	;	;	;	;	[1], general practice
Division symbol taught	÷ then /	÷ then /	÷	÷ / :	:	÷	÷ / :	:	[5][6]
Multiplication symbol taught	×	×	×	×	×	×	×	· (dot)	[6]
Long-division layout	US tableau, bracket, quotient on top	US tableau	Anglo layout, mental subtraction	“potence”: divisor right of `	`, quotient below	“potence”: divisor right of `	`, quotient below	European: divisor right of `	`, quotient below
Interval, open	(0,1)	(0,1)	(0,1)	(0,1)	]0,1[ (school-taught)	(0,1)	(0,1)/]0,1[ (varies)	(0,1) (also ]0,1[ in some curricula)	[4]
Interval, half-open	[0,1)	[0,1)	[0,1)	[0,1)	[0,1[	[0,1)	[0,1)/[0,1[	[0,1)/[0,1[	[4]
Scale name for 10⁹	billion	billion (since 1974)	mil millones	mil millones	milliard	bilhão (short-scale exception)	mil milhões	Milliarde	[2][3]
Scale name for 10¹²	trillion	trillion	billón	billón	billion	trilhão	bilião	Billion	[2][3]
Teen-number structure	regular (thirteen–nineteen irregular in EN too)	same	dieciséis (fused)	dieciséis (fused)	seize (opaque root)	dezesseis	dezasseis	sechzehn (regular, but 21 = “einundzwanzig”, inverted)	[7], general knowledge (marked unverified for exact RAE dating)
70/80/90 word structure	regular (seventy/eighty/ninety)	same	setenta/ochenta/noventa (regular)	same	soixante-dix/quatre-vingts/quatre-vingt-dix (BE/CH: septante/nonante)	setenta/oitenta/noventa (regular)	same	siebzig/achtzig/neunzig (regular)	[7]
CLDR plural categories	one, other	one, other	one, many, other	one, many, other	one, many, other	one, many, other	one, many, other	one, other	[8][9]

Note: the interval-notation row for pt-PT/de-DE is marked “varies” because curricula differ by textbook/region and the Wikipedia source [4] documents the existence of the reversed-bracket (Bourbaki) convention without giving a country-by-country adoption table; treat as directionally correct, not independently confirmed for every named locale.

Findings

1. Decimal marker: BIPM/ISO position, and why Mexico is the outlier

The 22nd General Conference on Weights and Measures (2003) states the decimal marker “shall be either the point on the line or the comma on the line” — both are equally valid under SI [1]. ISO 80000-1 repeats this neutrality, though ISO/IEC editorial directives use the comma in the standards’ own text [1]. Digit grouping is a separate question: BIPM policy since 1948 (reaffirmed 2003) recommends a thin space for grouping thousands (e.g. 20 000, 1 000 000), specifically to avoid the comma/point ambiguity entirely [1]. In practice almost nobody in consumer software follows the thin-space recommendation; countries instead flip whichever symbol isn’t already their decimal marker into the grouping role — comma-decimal countries (Spain, France, Germany, Brazil, Portugal) use the point for grouping, and point-decimal countries (US, UK, Mexico, Canada-English) use the comma [1]. Mexico uses the point, unlike Spain, despite both being Spanish-speaking [1] — this is a documented split within the same language family and the single most likely place a “es” locale fallback breaks silently.

2. Comma-as-list-separator collision

Where the decimal marker is a comma, using comma as a list/argument separator is ambiguous (3,5 could be “3.5” or “the list 3, 5”). The conventional fix in comma-decimal locales is to use a semicolon as the list/argument separator (spreadsheet formulas in fr-FR/de-DE/es-ES do exactly this) [1, general practice]. This matters directly for any UI string that lists numeric values inline, and for CSV-like exports where a naive comma-joined string of decimal numbers is unparseable in a comma-decimal locale.

3. Division and multiplication symbols

English-speaking arithmetic instruction uses ÷; French and German instruction commonly use the colon : for division, consistent with the long-division layout below [5][6]. For multiplication, Germany’s educational convention favors the dot operator · over ×, in part because × visually resembles the letter x used as a variable, and in part because a raised dot doesn’t collide with the German comma-as-decimal when writing a·b next to decimal numbers [6]. The asterisk * is a computing-era convention (ASCII lacked ×) and is not a taught classroom symbol anywhere in our five languages [6] — it should appear only in code/input contexts (e.g., a calculator-style input field), never in rendered instructional content.

4. Long division layout — the single highest-risk item for a step-by-step tutor

Wikipedia’s long-division article documents at least four structurally different layouts relevant to our locales [5]:

• US/UK (“bus stop”/tableau): no ÷ or : symbol at all — a right parenthesis or vertical bar separates divisor from dividend, and the quotient is written above the dividend, separated by a vinculum (overbar). This is the layout most English-language ed-tech assumes is “the” long division.
• France/Spain/Portugal (“potence” or “galley”): the divisor sits to the right of the dividend, separated by a vertical bar; the quotient is written below the divisor, under a horizontal line, and intermediate subtractions cascade down the left column. Example: 127|4 with the quotient 31,75 appearing below the bar.
• Germany/Austria/Switzerland: long division is written as a horizontal equation — 127 : 4 = 31,75 — with the working shown as a separate vertical scratch column, not a boxed tableau [5].
• Mexico: uses the Anglo-style tableau visually, but with a pedagogical difference — only the result of each subtraction step is written down; the subtraction itself is expected to be done mentally, producing a visually sparser tableau than the US version [5]. (Mexican classrooms informally call this layout “galera” or “casita” — this colloquial naming is general knowledge from Mexican elementary pedagogy, not something the fetched Wikipedia text itself used, so treat the term, not the layout description, as unverified.)
• Brazil: unlike the rest of Latin America, Brazil (along with Bolivia, Paraguay, Venezuela per the same source) uses the European potence-style layout rather than the Anglo one [5] — meaning a single “es-LatAm vs pt-BR” locale split is not even sufficient; Brazil’s layout resembles Spain’s more than it resembles Mexico’s.

A tutor that shows “steps” for long division cannot use one hardcoded visual template — it needs at minimum four distinct renderers (US/UK, potence/European, German equation, Mexican-sparse) selected by locale, not by language.

5. Interval notation

ISO 31-11 documents two valid conventions for excluding an endpoint: replacing the bracket with a parenthesis ((0,1), [0,1)), or reversing the bracket (]0,1[, [0,1[) [4]. The reversed-bracket form was introduced by the Bourbaki collective (French) and is the form taught in French (and, per general knowledge not independently confirmed in the fetched text, Belgian) secondary curricula; the parenthesis form dominates English-, Spanish-, and Portuguese-language instruction, and German curricula use both depending on textbook [4]. This is a case where the “correct” rendering is a per-locale (sometimes per-curriculum) flag rather than a fixed mapping from language code.

6. Long scale vs short scale — five languages, five/six answers

The short scale (billion = 10⁹, each new term ×1,000) is used by the US always, and by the UK since a 1974 government decision publicly announced by PM Harold Wilson adopting “billion = 1,000 million” as the international/American convention [2]. The long scale (billion = 10¹², milliard/mil millones/mil milhões = 10⁹ as the intermediate term) is used by France (which reverted to long scale in 1948 after having originally popularized the short scale worldwide) [3], Spain and Mexico (long scale; “mil millones” is the everyday term for 10⁹ rather than a native “billón”-adjacent word) [2], Germany (Milliarde = 10⁹, Billion = 10¹²) [2][3], and Portugal (bilião = 10¹², mil milhões = 10⁹) [2]. Brazil is the outlier within Portuguese: unlike Portugal, Brazilian Portuguese uses the short scale — “bilhão” = 10⁹ [2]. So across our five languages/eight locales, the short-scale group is {en-US, en-GB, pt-BR} and the long-scale group is {es-MX, es-ES, fr-FR, pt-PT, de-DE} — the split runs through both English and Portuguese, not along language lines.

7. Number-word structure and its effect on learning to count

Three structural (not merely lexical) differences matter for early counting UI and TTS scripts:

• German inversion: two-digit numbers name the units digit before the tens digit and join them with “und” — 21 is “einundzwanzig” (literally “one-and-twenty”), the reverse of the written digit order. This is a genuinely different cognitive mapping between spoken and written form, not a translation choice.
• French vigesimal remnants: 70 is “soixante-dix” (sixty-ten), 80 is “quatre-vingts” (four-twenties), 90 is “quatre-vingt-dix” (four-twenty-ten) in Metropolitan French; Belgian and most Swiss French speakers instead use the regular decimal terms “septante” (70) and “nonante” (90), with 80 remaining “quatre-vingts” in Belgium and largely regular (“huitante”, historically “octante”) only in some Swiss cantons — Geneva, Neuchâtel, and Jura keep the Metropolitan forms [7]. A single “fr” locale cannot assume one set of number words even within francophone Europe.
• Spanish fused vs. separated teens: “dieciséis/diecisiete/dieciocho/diecinueve” (16–19) are the modern standard fused forms versus the historically attested separated “diez y seis” — this fusion/history is well documented in Spanish-language pedagogy generally, but the exact RAE ruling and date could not be independently confirmed via the sources fetched this session; treat the specific RAE date as unverified, though the existence of both forms is not in doubt.

The learning-science stakes of this are established in the cognitive-development literature: East Asian languages (Chinese, Japanese, Korean) construct number words with fully transparent base-10 structure (13 as “ten-three” rather than “thirteen”), and cross-national comparisons (Miura and colleagues, comparing China, France, Japan, Korea, Sweden, and the US) found this transparency correlates with stronger early place-value understanding and mental base-10 representations of number in young children [11][12]. A more recent line of work specifically tests and partially complicates the strength of this “language account,” finding the effect real but modulated by other instructional factors [13][14]. The practical takeaway for Math Challenge: German, French, and Spanish counting exercises in the youngest age band cannot be produced by literally translating an English or Chinese-style counting sequence — the counting words themselves encode different structure, so counting-sequence content must be authored natively per language, including the irregular ranges, not machine-translated.

8. Plural rules (CLDR) and German text expansion

CLDR plural categories are not binary “singular/plural” — they are a locale-defined set of grammatical buckets keyed by numeric properties of the operand (integer/decimal, trailing digits, magnitude), and the count of categories differs by language: English and German use two categories (one, other), each triggered specifically by i = 1 and v = 0 (an integer value of exactly 1, no visible decimal digits) [9]. French, Spanish, and Portuguese use three categories (one, many, other); notably in these languages the one category also covers 0 in some rule sets (French: i = 0,1), meaning “0 items” pluralizes like “1 item” rather than like “5 items” — the opposite of English’s default assumption that anything not exactly 1 is plural [9]. Any UI string with a count (“You solved {n} problems”) must route through ICU MessageFormat/Intl.PluralRules rather than a hardcoded n === 1 ? singular : plural check, or French/Spanish/Portuguese zero-count strings will read ungrammatically. Separately, German is well known to run 20–35% longer than English for equivalent UI strings due to compounding — this is a general, widely-documented localization fact rather than something re-confirmed via a specific fetch this session, and should be treated as a layout-budget constraint (test with pseudo-localization, not just real German copy, since German strings can spike far longer than the average on specific compound terms).

9. TTS voice availability per locale

This is an engineering/vendor-inventory question rather than a linguistics one, and could not be resolved with a citable, current source in this session (browser SpeechSynthesis.getVoices() coverage is OS/browser-dependent and changes without a stable canonical reference; Cloudflare Workers AI’s melotts model’s language list and any third-party TTS vendor’s locale/voice matrix need to be checked directly against the vendor’s current model card at implementation time, not assumed from this report). Flag as unverified and requiring a direct check against whichever TTS vendor is chosen, with particular attention to whether pt-BR and pt-PT get distinct voices (they often don’t) and whether es-MX and es-ES get distinct voices (increasingly yes, but not universally).

10. Intl.NumberFormat / Intl.PluralRules capabilities

Intl.NumberFormat natively handles decimal/grouping separator selection, digit script (e.g. Arabic-indic digits), and style: "unit"/"currency"/"percent" formatting per BCP-47 locale tag, and exposes formatToParts() for building custom-styled output and formatRange() for interval-like display [10]. It is locale-output aware but says nothing about locale-input parsing — there is no Intl.NumberFormat.parse(); parsing locale-formatted user input (a German child typing “3,5”) has to be handled by application code, typically by using formatToParts() on a known value to discover the current locale’s decimal/group characters and then normalizing user input against that discovered mapping before calling Number()/parseFloat(). Intl.PluralRules (paired with CLDR data, see §8) resolves the plural category for a given number in a given locale and is the correct primitive to drive ICU MessageFormat-style pluralized strings.

Design implications

1. Store items as a structured AST, not rendered text — verdict: AST. A math item (equation, interval, long-division problem) must be stored as a locale-agnostic semantic structure (operator, operands, precision, magnitude) and rendered to text/visuals only at the presentation boundary. Storing pre-rendered strings (e.g. “3,5 ÷ 2 = 1,75”) makes every locale a content fork; storing an AST makes locale a rendering parameter.
2. Answer parsing must accept locale-correct decimal input. A German or French child typing “3,5” must be accepted as 3.5; an es-MX or en-US child typing “3.5” must also be accepted. Implement a locale-aware normalizer (discover the locale’s decimal/group characters via Intl.NumberFormat().formatToParts(), strip/convert accordingly) rather than a single global regex.
3. Long division needs at least four distinct step-by-step renderers, selected by a locale (or explicit curriculum-region) setting, not by language code alone: US/UK tableau, France/Spain/Portugal/Brazil potence, Germany horizontal-equation, Mexico Anglo-sparse. Do not assume es implies one layout — es-MX and es-ES/Brazil diverge from each other on this axis.
4. Division and multiplication symbols are a locale-configurable display preference, not part of the item’s semantic content. Store the operator as an abstract DIVIDE/MULTIPLY node; render as ÷/: and ×/· per locale/curriculum setting.
5. Interval bracket style ((0,1) vs ]0,1[) is a per-locale/curriculum rendering flag, most relevantly for fr-FR (and possibly Belgian French), with de-DE and pt-PT ambiguous by curriculum — expose it as a configurable content-rendering setting rather than a hard per-language rule, and confirm with a native curriculum consultant before defaulting.
6. Large-number naming must route through a locale-aware number-to-words function that distinguishes long vs. short scale, and specifically must NOT assume scale correlates with language: short-scale locales are {en-US, en-GB, pt-BR}; long-scale locales are {es-MX, es-ES, fr-FR, pt-PT, de-DE}. A shared “pt” number-namer will misname billions for either Brazil or Portugal.
7. List/argument separators in generated strings must switch to semicolon (or Intl.ListFormat) in comma-decimal locales to avoid colliding with the decimal comma — any feature that renders a list of numbers inline (e.g., “possible answers: 2,5, 3,5, 4,5”) is actively ambiguous in fr/de/es-ES/pt without this.
8. Count-sensitive UI strings must use ICU MessageFormat/Intl.PluralRules with the full CLDR category set per language, not an n===1 check — French/Spanish/Portuguese route 0 through the one-like category in some rule variants, which an English-first pluralization helper will get wrong.
9. Reserve UI layout budget for German text expansion (roughly 20–35% longer than English on average, more on specific compounds) — validate layouts with pseudo-localization or actual long German strings, not just the English baseline, especially in constrained UI like buttons, badges, and mobile nav labels.
10. Counting-sequence and number-word content for the youngest age band must be authored natively per language, not machine-translated, because German inversion, French vigesimal 70/80/90 (plus septante/nonante regional variants), and Spanish fused teens are structural differences in how numbers are spoken, not just vocabulary substitutions. A word-for-word translation of an English or Chinese-style counting exercise will teach the wrong spoken form.
11. TTS voice coverage must be verified per locale before promising audio number-reading, with explicit attention to whether the chosen TTS vendor distinguishes es-MX from es-ES and pt-BR from pt-PT (this is unresolved in this report — flagged as an open item, see below) — build an explicit fallback matrix (e.g., pt-PT falls back to a pt-BR voice with a disclosed limitation) rather than silently mis-voicing a locale.
12. Adopt Intl.NumberFormat / Intl.PluralRules / Intl.ListFormat as the enforcement layer for all locale-sensitive number/text rendering, keeping a canonical numeric value (e.g., a decimal string, BigInt, or fixed-point representation — not a locale-formatted string) as the single source of truth, localizing only at the render boundary and de-localizing immediately at the input boundary.
13. Build a first-class “math locale config” table (decimal separator, grouping separator, list separator, division symbol, multiplication symbol, long-division layout key, number scale, interval bracket style) keyed by a locale-or-curriculum identifier, separate from ordinary UI-string i18n — standard gettext/ICU tooling handles plurals and string interpolation but has no native concept of “long division layout” or “number scale,” so this needs a custom, versioned, testable config alongside the translation files.
14. Mixed-number vs. improper-fraction display conventions differ by country/curriculum (heavier emphasis on mixed numbers in US/UK primary curricula vs. more consistent improper-fraction use in some European traditions) — this was not independently confirmed with a citable source this session and should be validated directly with curriculum consultants per locale before hardcoding a default; treat as an open item, not a settled convention.
15. Any spoken-number input/output feature (voice answer input, dictated-number exercises) must accept/produce both historically-attested word forms where they coexist (e.g., Spanish “dieciséis” vs. “diez y seis”) and correctly handle German’s spoken-order inversion when mapping a dictated number word to its digit form — this is a distinct parsing problem from typed decimal-separator normalization (implication 2) and needs its own locale-aware grammar, not a shared one.

Open questions for the project owner

• Do we commit to building 4+ distinct long-division renderers at launch, or ship one (which one?) with a documented “not authentic to this curriculum” caveat for the other locales?
• Is interval-notation bracket style (parenthesis vs. reversed bracket) a per-locale default, or a user/teacher-configurable setting per classroom’s textbook convention?
• Which TTS vendor will actually be used for number read-aloud, and does it have confirmed distinct voices for es-MX/es-ES and pt-BR/pt-PT? (Unresolved in this report — needs a direct vendor check.)
• Should the youngest-age counting content be commissioned from native-speaking pedagogy consultants per language rather than translated from a single source language, given the structural (not lexical) differences documented in §7?
• Do we need curriculum-region granularity below language (e.g., fr-FR vs. fr-BE vs. fr-CH for septante/nonante; de-DE vs. de-CH) or is language-level granularity acceptable for v1?
• Should the “math locale config” table (implication 13) live in the content-authoring system or in application code/config, and who owns updating it when a new locale is added?
• Is mixed-number vs. improper-fraction display a per-locale default we’re willing to hardcode, or does it need explicit curriculum-consultant validation first (see implication 14)?