Building and Operating a 2.500-Item Math Bank: What Real Learning Products Do

Ergebnisse

Wie viele Items haben reale Produkte tatsächlich

Veröffentlichte, verifizierbare Zahlen sind seltener als die Marketing‑Aussagen vermuten lassen. IXLs spanischsprachige Mathematik‑Seite gibt die Fähigkeitszahlen pro Klassenstufe an – Preescolar 73, 1. Klasse 117, 2. Klasse 127, 3. Klasse 183, 4. Klasse 130, 5. Klasse 125, 6. Klasse 112, 7. Klasse 108, 8. Klasse 144 – was 1.219 Fähigkeiten über 9 Klassenstufen ergibt [1]. Das sind Fähigkeiten, keine Items: Jede Fähigkeit ist eine vorlagenartige Kategorie, gegen die IXL dynamisch Übungsfragen generiert, sodass die Fragenanzahl pro Fähigkeit unbegrenzt ist, ähnlich wie bei einem WeBWorK‑Problem. Für die Übungsanzahl von Khan Academy, die Problemanzahl von Brilliant oder die Arbeitsblattanzahl von Kumon wurde in dieser Sitzung kein vergleichbar präzises Gesamt gefunden – diese Zahlen kursieren in Marketing‑ und Sekundärquellen, aber keine primäre Seite, die in dieser Sitzung abgerufen wurde, nennt eine Zahl, daher werden sie weggelassen statt geraten. Der Wikipedia‑Artikel „Item Bank“ beschreibt die Metadaten‑Lebenszyklus‑Elemente, die Item‑Banks verfolgen (Status: neu/Pilot/aktiv/retired; Nutzungshistorie) [item bank wiki], liefert jedoch keine konkrete Größe für ein genanntes Programm.

Parametrisierte Generierung vs. handgeschriebene Autorenschaft

Khan Academys Perseus ist die eigene Repository‑Beschreibung von „Khan Academys Übungs‑Frage‑Editor und Renderer“ – ein System zum Autorieren, Rendern und Bewerten von Übungsantworten, MIT‑lizenziert, aber für externe Beiträge gesperrt [2]. WeBWorKs PG („Problem Generation“)‑Sprache ist ein perl‑basiertes Autorierungsformat für Randomisierung: Dozentinnen schreiben ein Problem, und Parameterisierung lässt jede Sitzung unterschiedliche numerische Werte aus derselben Vorlage ziehen, wodurch ein praktisch unbegrenzter Item‑Pool aus einer einzigen Quelle entsteht [5] – das konkrete Muster „eine Vorlage, viele Items“, das dieses Projekt für K‑8‑Arithmetik und frühe Algebra benötigt. Brilliant.org beschreibt seinen Ansatz als hybrid: Inhalte werden „hand‑crafted“ von einem Team aus „Math‑PhDs bis zu Ingenieurinnen und Designer*innen“ erstellt, während Machine Learning „on‑the‑fly visuelle und interaktive“ Personalisierungsschichten darüber legt – und Brilliant gibt an, dass neuer Review‑Set‑Inhalt „human‑review[ed] everything“ sei, schrittweise ausgerollt aus diesem Grund [brilliant about page]. Das Muster über alle drei: Vorlagen und dynamische Generierung multiplizieren Volumen, aber ein Mensch entwirft weiterhin die Vorlage und deren Einschränkungen.

Der Wikipedia‑Artikel zur automatischen Item‑Generierung (AIG) fasst die Methode zusammen: „ein Test‑Spezialist erstellt eine Vorlage, das sogenannte Item‑Model; dann wird ein Computer‑Algorithmus entwickelt, um Test‑Items zu generieren“ – Algorithmen erzeugen dann „Familien von Items aus einem kleineren Satz von Eltern‑Item‑Modellen“, die „in einer gegebenen Zeit viel mehr Items erzeugen können als ein menschlicher Test‑Spezialist“, wodurch Kosten gesenkt werden [AIG wiki]. Kein Artikel gab in dieser Sitzung einen konkreten Items‑pro‑Vorlage‑Multiplikator oder prozentuale Kostenreduktion an.

LLM‑generierte Items: real, aber begrenzt (Forschung 2023–2026)

Ein konkreter, zitierbarer Datenpunkt: Feng, Lee, McNichols, Scarlatos, Smith, Woodhead, Otero Ornelas und Lan, „Exploring Automated Distractor Generation for Math Multiple‑choice Questions via Large Language Models“ (arXiv 2404.02124), testet In‑Context‑Learning und Fine‑Tuning zur Erzeugung von Multiple‑Choice‑Distraktoren auf einem realen Mathematik‑Datensatz. Die zentrale Erkenntnis ist exakt die Einschränkung, die das Schema‑Design dieses Projekts berücksichtigen muss: „obwohl LLMs einige mathematisch gültige Distraktoren erzeugen können, sind sie weniger geschickt darin, häufige Fehler oder Missverständnisse realer Schülerinnen vorherzusehen“ [arXiv 2404.02124]. In dem von dieser Sitzung abgerufenen Abstract war keine numerische Experten‑Review‑Pass‑Rate enthalten, daher wird keine Zahl zitiert – die qualitative Erkenntnis ist jedoch entscheidend: Ein LLM kann eine plausibel aussehende falsche Antwort schreiben, aber ob sie dem entspricht, was eine realer Schülerin tatsächlich denken würde, ist ein schwierigeres Problem, bei dem aktuelle Modelle unterdurchschnittlich abschneiden. Duolingos Forschungsseite listet „Jump‑Starting Item Parameters for Adaptive Language Tests“ (McCarthy et al., EMNLP 2021) [Duolingo research] auf und behandelt das benachbarte Cold‑Start‑Problem der Schwierigkeitsschätzung für frisch generierte Items, bevor reale Antwortdaten vorliegen – ein Problem, dem diese Bank für jedes neue Item am ersten Tag gegenübersteht.

Der Item‑QA‑Workflow und psychometrisches Screening

Die Klassische Testtheorie (CTT) definiert zwei pro‑Item‑Statistiken, die jede Produktionspipeline vor dem Vertrauen in ein Item benötigt: den p‑Wert, „den Anteil der Prüflinge, die in die vorgegebene Richtung antworten“ (Schwierigkeit – höherer p‑Wert bedeutet leichter), und die Item‑Diskriminierung, berechnet über die Punkt‑Biserial‑Korrelation zwischen der Item‑Punktzahl und der Gesamttest‑Punktzahl, verwendet „zur Bewertung von Items und zur Diagnose möglicher Probleme, wie einem verwirrenden Distraktor“ [CTT wiki; point‑biserial wiki]. Keiner der Artikel nannte einen numerischen Schwellenwert für „gut genug“ bei Diskriminierung oder Schwierigkeit, daher wird hier nichts behauptet. Dokumentiert ist jedoch: Computerized Adaptive Testing gibt an, dass „alle Items mit einer ausreichend großen Stichprobe vorgetestet werden müssen, um stabile Item‑Statistiken zu erhalten. Diese Stichprobe kann bis zu 1.000 Prüflinge erfordern“ [CAT wiki] – die einzige quantitative Stichprobengröße, die in dieser Sitzung gefunden wurde, und ein nützlicher Oberwert dafür, wie konservativ reale Programme sein können. Der Item‑Bank‑Artikel beschreibt die Metadaten‑Lebenszyklus‑Elemente, die reife Systeme verfolgen: „Item‑Status (z. B. neu, Pilot, aktiv, retired)“ und „Item‑Historie (z. B. Nutzungsdatum(e) und Reviews)“ [item bank wiki] – direkt relevant für das untenstehende Feld status.

Ein Item nach tausenden Antworten korrigieren

Keine Quelle behandelte Versionierung direkt, aber das Lebenszyklus‑Status‑Muster [item bank wiki] impliziert die Antwort: Ein Item mit angehängten Antwortdaten wird niemals an Ort und Stelle bearbeitet – Statistiken werden gegen den genauen Wortlaut berechnet, den die Schüler*innen beantwortet haben, und eine stille Änderung würde jede vorherige Antwort ungültig machen. Das sichere Muster: Eine neue Version erstellen, die alte zurückziehen (status: retired, nie gelöscht) und ein frisches Statistik‑Fenster starten.

QTI 3.0 – lohnt es sich für ein Startup?

1EdTechs QTI 3.0 ist der Standard für „den Austausch von Assessment‑Items, Tests, Nutzungsdaten und Ergebnisberichten zwischen verschiedenen Anwendungen“, konsolidiert frühere QTI‑Versionen und den APIP‑Barrierefreiheits‑Standard, mit nativer Computer‑Adaptive‑Testing‑ und Portable‑Custom‑Interaction‑Unterstützung sowie integrierter Section‑508 / WCAG 2.1 AA‑Barrierefreiheit [3]. Die eigene Implementierungs‑Leitlinie ist eindeutig, dass Konformität modular ist: „die Bedürfnisse des Assessment‑Programms bestimmen im Allgemeinen, welche der vielen QTI 3‑Funktionen verwendet werden“, und Konformität/Zertifizierung ist ein separates Dokument, genau damit Organisationen Teilmengen übernehmen können [4]. Ein minimaler Pfad – Kern‑XML/XSD‑Validierung, grundlegende Choice/Text‑Entry‑Interaktionen, Response‑Processing‑Templates, Standard‑Packaging, Kern‑Barrierefreiheits‑Markup – funktioniert, ohne adaptives Testing oder Portable Custom Interactions zu berühren [4]. QTI 3.0 ist also nicht alles‑oder‑nichts: Das Aufschieben von CAT/PCI bei gleichzeitiger Gewinnung von Interoperabilität und Barrierefreiheits‑Gerüst für die MVP‑Item‑Typen ist eine echte Option.

Lokalisierungs‑Workflow über 5 Sprachen

Keine Quelle beschrieb einen math‑spezifischen Übersetzungs‑Workflow, daher ist dies eine abgeleitete Überlegung. Die aus dem AIG/WeBWorK‑Material zu übernehmende Erkenntnis: Übersetzungskosten skalieren mit unterschiedlichem autorisiertem Inhalt, nicht mit der generierten Item‑Anzahl. Der feste Text einer Vorlage („What is __ + __?“) wird einmal pro Sprache übersetzt und deckt jede numerische Variante ab, die sie jemals erzeugt, während ein handgeschriebenes oder LLM‑erstelltes Item in voller Länge pro Item übersetzt wird – der größte Hebel im Kostenmodell unten.

Reale Kosten‑pro‑Item‑Zahlen aus der Assessment‑Industrie

Keine gefunden und in dieser Sitzung unabhängig verifiziert. Abrufversuche bei AIR, NCIEA und ETS‑Ressourcenseiten ergaben 404‑Fehler oder keine Kostenangaben; die ETS‑Forschungs‑Startseite nannte nur „11,9K publications“, keine Kostenangabe [ETS research page]. Branchen‑Blogs zitieren häufig Kosten pro Item im niedrigen Tausend‑Dollar‑Bereich – da jedoch keine primäre Quelle in dieser Sitzung live abgerufen wurde, wird diese Zahl nicht unten verwendet. Das Kostenmodell leitet sich stattdessen vollständig aus angegebenen LLM‑API‑Preisen und expliziten, gekennzeichneten Person‑Tag‑Annahmen ab.

Benchmarks‑Tabelle

Produkt / System	Item‑ oder Fähigkeitsanzahl	Generiert oder handgeschrieben	Quelle
IXL (Mathe, PreK–8)	~1.219 Fähigkeiten (9 Klassenstufen)	Kuratierte Fähigkeitskategorien; Fragen dynamisch pro Fähigkeit generiert	[1]
Khan Academy (Perseus)	Nicht verifiziert in dieser Sitzung	Hybrid: menschlich autorisierte Übungsdefinitionen, von Perseus gerendert/variiert	[2]
WeBWorK (PG‑Sprache)	Große Bibliothek; Anzahl nicht verifiziert	Vorlagenbasiert: ein PG‑Problem liefert unbegrenzt randomisierte Instanzen	[5]
Brilliant.org	Nicht öffentlich angegeben	Hybrid: hand‑crafted Basis + ML‑On‑the‑Fly‑Personalisierung, menschlich geprüft	[brilliant about]
Duolingo (Item‑Kalibrierungs‑Forschung)	k.A. — Sprachtest	Algorithmisch generierte Items; ML‑unterstützte Schwierigkeitskalibrierung für Cold‑Start‑Items	[Duolingo research]
NWEA MAP Growth (CAT)	Nicht verifiziert in dieser Sitzung	CAT‑Bank; Vor‑Test‑Stichproben bis zu 1.000 Prüflinge für stabile Statistiken	[CAT wiki]
Allgemeine AIG‑Praxis	Keine universelle Angabe	Test‑Spezialist erstellt ein „Item‑Model“; Algorithmus generiert Item‑Familien daraus	[AIG wiki]

Ein konkreter 2.500‑Item‑MVP‑Plan

Level‑Bänder und Item‑Anzahlen (Pyramide — die meisten Items dort, wo die meisten Nutzer*innen sind):

Band	Items
K–2	300
3–5	400
6–8	450
9–10	400
11–12	350
Undergraduate (intro)	350
Advanced undergrad / Masters	150
PhD / research	100
Total	2.500

Anteil nach Quelle, pro Band (der Anteil an Vorlagen sinkt und der handschriftliche Anteil steigt, je höher das Niveau — Vorlagen kämpfen mit beweisbasiertem, fortgeschrittenem Inhalt, und Nuancen von Fehlvorstellungen sind dort am wichtigsten, wo LLMs am schwächsten sind):

Band	Template % / Items	LLM‑erstellte % / Items	Handgeschriebene % / Items
K–2	70 % / 210	20 % / 60	10 % / 30
3–5	60 % / 240	25 % / 100	15 % / 60
6–8	50 % / 225	30 % / 135	20 % / 90
9–10	35 % / 140	35 % / 140	30 % / 120
11–12	30 % / 105	30 % / 105	40 % / 140
Undergraduate	20 % / 70	30 % / 105	50 % / 175
Advanced/Masters	10 % / 15	30 % / 45	60 % / 90
PhD	5 % / 5	25 % / 25	70 % / 70
Total	1.010 (40,4 %)	715 (28,6 %)	775 (31,0 %)

Das Review‑Gate (jedes Item durchläuft alle Stufen; nur der Aufwand pro Stufe unterscheidet sich): SME‑Autorenschaft / Vorlagendesign → redaktioneller Durchlauf → mathematische Genauigkeitsprüfung → Barrierefreiheits‑Review (Alt‑Text, screen‑reader‑sichere Notation) → Übersetzung (4 Zielsprachen) → Pilot (echte Antworten sammeln) → psychometrisches Screening (nur dann zu active befördern, wenn die Antwortzahl ausreichend ist — Implikation 4). Handgeschriebene Items starten bei „SME‑Autorenschaft“; LLM‑erstellte Items starten mit einem fertigen Entwurf, durchlaufen jedoch jede nachgelagerte Stufe; vorlagenbasierte Items überspringen die Autorenschaft pro Item, aber die Vorlage durchläuft das gleiche Gate einmal.

Item‑JSON‑Schema — erforderliche Felder:

item_id, version, status, level_band, topic_tag, source_type, template_id,
languages{locale: {stem, choices, correct_answer, worked_solution,
  misconceptions[]}}, stem_canonical, choices, correct_answer,
worked_solution_canonical, misconceptions[{trigger_answer, explanation,
  remediation_hint}], difficulty_estimate_initial, irt_parameters{a, b, c,
  n_responses, last_calibrated_at}, p_value, point_biserial,
accessibility_metadata{alt_text, mathml, contrast_notes}, media[],
authoring_metadata{author, reviewer, created_at, reviewed_at, notes},
qti_export_ref, curriculum_tags[], retirement_reason

Aufwand in Personentagen (jede Angabe ein gekennzeichneter Schätzwert; Rechnung angegeben):

• Vorlagendesign: 50 Vorlagen (≈20 Varianten/Vorlage für die 1.010 Vorlagen‑Items) × 0,5 Tag = 25 Tage; einmaliger Parameterisierungs‑Engine‑Aufbau ≈15 Tage (nicht pro Item).
• Review/Korrektur LLM‑erstellter Items: 715 × 0,15 Tag = ≈107 Tage.
• Handgeschriebene Autorenschaft: 615 Items (K‑2 – Undergrad, 0,5 Tag je) + 160 (Advanced + PhD, 1,0 Tag je, seltener Spezialist) = ≈468 Tage.
• Übersetzungs‑Review (bilingualer SME‑Spot‑Check der LLM‑Übersetzung, nicht unabhängige Neu‑Übersetzung): 50 Vorlagen × 4 Sprachen = 200 Einheiten, plus 1.490 Items × 4 Sprachen = 5.960 → 6.160 Einheiten × 0,05 Tag = ≈308 Tage.
• Redaktion‑ + Barrierefreiheits‑Durchlauf, einheitlich: 2.500 × 0,05 Tag = ≈125 Tage.
• Psychometrischer Batch‑Review: 2.500 / 50 pro Batch × 0,1 Tag = ≈5 Tage (exkl. Kalenderzeit für Pilot‑Antworten — eine Zeitplan‑Beschränkung, kein Aufwand‑Kosten‑Faktor).

Gesamt: 25+15+107+468+308+125+5 ≈ 1.053 Personentage, grob 4,2 Personenjahren. Ein 5‑köpfiges Team (2 Mathe‑SMEs, 1 Lokalisierungs‑Lead, 1 Editor/Psychometriker, 1 Engineer) schafft das in ≈1.053 ÷ 5 ≈ 210 Arbeitstage, etwa 10 Monate — eine abgeleitete Schätzung, keine zitierte Branchenzahl.

Geschätzte LLM‑Kosten für Entwurf + Übersetzung (Claude Sonnet 5 Standard‑Preise: $3,00 Input / $15,00 Output pro Million Tokens):

• LLM‑erstellte Items, erster Entwurf (~1.500 Input + ~800 Output‑Tokens/Item): (1.500×$3 + 800×$15)/1000000 = $0,0165/Item × 715 ≈ $12.
• Handgeschriebene Items, LLM‑unterstützte Fehlvorstellungs‑Erstellung nur (gleiches Token‑Profil): 775 × $0,0165 ≈ $13.
• Vorlagen‑Autorenschaft‑Unterstützung (~5.000 Input + 2.000 Output‑Tokens/Vorlage): $0,045/Vorlage × 50 ≈ $2.
• Übersetzung (~800 Input + ~900 Output‑Tokens/Einheit): $0,0159/Einheit × 6.160 Einheiten ≈ $98.

Roh‑Ein‑Durchlauf‑Gesamtkosten ≈ $125. Ein 5‑facher Sicherheits‑Multiplikator für realistische Iterationen (Validierungs‑Wiederholungen, Review‑ausgelöste Regeneration, Opus 5 für die schwierigsten Bänder) ergibt ≈ $500–$700 Gesamtkosten für den gesamten Entwurfs‑ und Übersetzungs‑Durchlauf — noch immer unter $1.500 verdoppelt für Eventualitäten, drei Größenordnungen unter den Personentage‑Kosten. Prompt‑Caching würde das weiter senken, ist hier aber nicht eingerechnet.

Designimplikationen

1. Parameterisierte Vorlagen für K‑8‑Arithmetik und frühe Algebra verwenden — eine WeBWorK‑artige Vorlage, die unbegrenzt numerische Varianten erzeugt [5], ist der wirkungsvollste Hebel in diesem Plan.
2. Budget für handschriftliche Autorenschaft für 11‑12 bis PhD reservieren, wo Vorlagen den geringsten Anteil (30 % → 5 %) haben, weil beweisbasierter Inhalt sich kaum sicher randomisieren lässt.
3. Vorlagen, nicht generierte Instanzen, übersetzen: 200 Übersetzungseinheiten decken 1.010 Vorlagen‑Items ab versus 5.960 Einheiten für Einzel‑Items — der größte Lokalisierungs‑Hebel im Modell.
4. p‑Values und Point‑Biserial‑Diskriminierung als provisorisch behandeln, bis Antworten gesammelt sind; CAT‑Literatur nennt Stichproben bis zu 1.000 Prüflingen für stabile Pre‑Test‑Statistiken [CAT wiki] — Item nicht zu active befördern, wenn nicht ein klar definiertes Minimum erreicht ist (offene Frage 4).
5. Items unveränderlich versionieren. Nie ein Item mit bereits vorhandenen Antworten editieren — neue Version erstellen, alte retire (status: retired, nie gelöscht), analog zum neuen/pilot/active/retired‑Lebenszyklus, der allgemein für Item‑Banks dokumentiert ist [item bank wiki].
6. QTI 3.0 schrittweise einführen — sein Konformitätsmodell ist explizit modular [4]; Kern‑Interaktionen und Barrierefreiheits‑Metadaten für das MVP implementieren, CAT/PCI‑Support später hinzufügen.
7. Das Review‑Gate als explizite Zustandsmaschine implementieren, die dem Feld status entspricht: draft → editorial → math check → accessibility → translation → pilot → psychometric screening → active/retired.
8. LLM‑API‑Kosten als vernachlässigbar (Hunderte Dollar) gegenüber den Personalkosten (Hunderttausende, laut obiger Personentage‑Rechnung) budgetieren — die eigentliche Beschränkung ist SME‑ und Übersetzerzeit, nicht Token.
9. Da Forschung 2023–2026 zeigt, dass LLMs mathematisch valide, aber fehlvorstellungs‑blind Distraktoren erzeugen [arXiv 2404.02124], muss jede LLM‑erstellte oder LLM‑unterstützte Item‑Fehlvorstellung von Menschen geprüft werden — nie ein unreviewtes LLM‑Fehlvorstellungs‑Erklärung an Larry ausliefern.
10. Erwartet, dass der ROI von Vorlagen stark am oberen Ende der Level‑Pyramide abfällt: Design‑Kosten pro Vorlage sind etwa fix, aber eine PhD‑Vorlage liefert viel weniger sicher nutzbare Varianten als eine K‑2‑Vorlage — der Plan gewichtet den Vorlagen‑Anteil bereits nach oben hin nach unten.
11. Übersetzung nach mathematischer Prüfung und Barrierefreiheits‑Review durchführen, nicht vorher — Übersetzung von Inhalten, die später die technische Prüfung nicht bestehen, verschwendet Übersetzerzeit.
12. Gemeinsamen Instruktions‑/Schema‑/Style‑Guide‑Text über Entwurfs‑ und Übersetzungs‑Aufrufe cachen; 715 + 775 + 6.160 Aufrufe teilen ein großes stabiles Prefix, sodass Prompt‑Caching die realisierten LLM‑Kosten weiter senken kann.
13. Planung für Item‑Exposure‑Kontrolle, sobald die Plattform adaptives Delivery unterstützt — selbst ein 2.500‑Item‑Bank profitiert vom Exposure‑Control‑Prinzip, das CAT‑Systeme nutzen, um ein Über‑Zeigen populärer Items zu vermeiden [CAT wiki].
14. Jeden Aufwand‑Tag und Kosten‑Wert hier als Schätzung verstehen, die gegen einen Pilot validiert werden muss, nicht als festes Ziel — keine Quelle lieferte einen verifizierten Items‑pro‑Vorlage‑Multiplikator oder pro‑Item‑Kosten für mathematischen Inhalt; die 20×‑pro‑Vorlage‑ und $/Item‑Zahlen sind modellierte Annahmen, als solche gekennzeichnet.

Offene Fragen für den Projekt‑Owner

1. Welchen geladenen Tagessatz sollten wir für SME/Übersetzer/Editor‑Zeit annehmen, um die ~1.053 Personentage oben in eine Budget‑Zahl zu überführen?
2. Ist 2.500 Items ein festes Ziel oder ein Minimum, mit Spielraum für Themen, die mehr Items benötigen, sobald Pilot‑Daten zurückkommen?
3. Welche der 4 Nicht‑Englisch‑Sprachen können LLM‑Übersetzung + Spot‑Check nutzen (wie oben modelliert), und welche benötigen von Anfang an unabhängige menschliche Übersetzung?
4. Welcher minimale Antwort‑Count sollte die Beförderung zu active steuern — die traditionelle CTT‑Daumenregel (oft ~30) oder der konservativere ~200–1.000‑Bereich, den die CAT‑Literatur für stabile Statistiken nennt [CAT wiki]?
5. Soll das Review‑Gate den QTI 3.0‑Export beim MVP blockieren oder das später zu einem post‑MVP‑Interoperabilitäts‑Meilenstein verschieben?
6. Advanced/Masters und PhD haben den niedrigsten Vorlagen‑Anteil und höchsten pro‑Item‑Kosten — sollten wir dafür einen spezialisierten Contractor‑SME budgetieren?
7. Soll Larrys Fehlvorstellungs‑Erklärungen einmal auf Englisch erstellt und dann übersetzt werden, oder pro Sprache unabhängig (z. B. Dezimal‑Komma‑ vs. Punkt‑Verwirrung in ES/FR/DE)?