There is a quiet assumption inside most technology education: that it happens in English. The tools are in English, the documentation is in English, the error messages are in English, and so, by inheritance, the teaching is in English.
For a student whose schooling is already in English, this is invisible. For the much larger number of students whose classroom runs in Hindi, Marathi, Tamil, Bahasa Indonesia, Thai or Vietnamese, it is a barrier placed before the subject even begins. They are not being asked to learn technology. They are being asked to learn technology in a second language, while simultaneously being assessed as though the only variable is technical aptitude.
What actually happens in the classroom
Cognitive load is finite. A student working in a second language is spending part of their capacity on comprehension and translation. That leaves less for the actual difficulty of the material — which, in a technology subject, is where the learning is.
The visible consequence is a student who appears slower than they are. The invisible consequence is worse: they conclude the subject is not for them. That conclusion is usually permanent, and it is usually wrong.
There is a second effect that gets less attention. Technology education is supposed to produce students who can explain their reasoning, argue for a design decision and document what they built. A student working at the edge of their language competence will produce the minimum viable sentence. Their thinking is not visible, so it cannot be taught into.
The objection, taken seriously
The most common objection is worth stating properly, because it is not silly: the industry works in English. A student who cannot read English documentation will hit a ceiling.
That is true, and it is not an argument for English-only instruction. It is an argument for sequencing.
Technical English is a specific, learnable, relatively small vocabulary. It is far easier to acquire once you already understand what the words refer to. A student who has built a loop, felt a program fail and understood a variable in their own language will pick up the English terms quickly, because the concepts are already in place and only the labels are new.
The reverse — learning the labels first and hoping the concepts arrive — is what currently happens, and it produces students who can recite terminology they cannot use.
The practical answer is bilingual by design: instruction and reasoning in the language of the classroom, with technical vocabulary introduced deliberately in English alongside it, so students end up with both.
Why translation is not localization
A common shortcut is to translate the student-facing material and leave everything else. This produces a programme that looks multilingual and is not.
Genuine language adaptation touches four layers:
Curriculum. Concept sequencing sometimes has to change, because the terms available in a language carry different intuitions.
Project material. Briefs, instructions, checkpoints. This is where translated-only programmes fail first — the student can read the concept and not the task.
Teacher resources. The most important layer and the most frequently skipped. A teacher delivering in Marathi from English lesson notes is translating live, every session, while also teaching.
Interface. The environment the student actually works in.
Skip the teacher layer and you have not built a multilingual programme. You have added a burden to the person the programme depends on.
Architecture, not aspiration
This is why language handling has to be a structural decision made at the start rather than a feature added later. A curriculum that hardcodes its examples, its variable names, its analogies and its assessment language cannot be adapted afterwards without being rebuilt.
Designing for it means keeping content separate from presentation, keeping technical vocabulary explicitly tagged rather than embedded, designing examples that survive translation — a project about local water use travels; a wordplay-based exercise does not — and treating teacher material as a first-class translation target.
None of this is exotic engineering. It is the difference between a product designed for one market and a product designed for many.
The honest position
Building a multilingual education product is slower and more expensive than building a monolingual one. Every language is real work: translation, review, teacher material, examples, assessment. Anyone claiming otherwise is describing machine translation, which in an education context produces material that is fluent, plausible and quietly wrong in exactly the places that matter.
So the honest position for any organisation in this space is architectural readiness plus market-by-market activation with real educators. Not a dropdown with forty flags in it.
The stake is simple enough. Somewhere there is a student who would have been extremely good at this, and who concluded early that it was not for them — because the first barrier they met was not the subject.