Bilingual computer science education starts by separating logic from language

In a programming classroom, a learner can understand a loop, an algorithm, or the idea of a variable and still hesitate at the code. That hesitation is easy to misread. It may be described as a lack of ability when the real friction is that programming syntax is an additional language layer: English-heavy keywords, punctuation rules, abbreviations, documentation, and error messages all arrive at once.

This distinction matters for teachers, tutors, and curriculum designers. A language-aware classroom does not lower the intellectual standard of computer science. It makes the route to that standard easier to see and assess.

Why this is more than a translation problem

Translation can help, but bilingual computer science education is not simply a matter of putting every handout into another language. Some concepts do not map word-for-word; some students use more than one language while thinking through a problem; and code itself remains a formal system with its own conventions. The practical question is whether the learner can explain the underlying idea, not whether they can immediately phrase that explanation in one preferred language.

In work with SJSU research advisor Prof. Ethel Tshukudu and CS programs at Yerba Buena High School, I have been interested in this gap between conceptual understanding and syntax. The related poster, Exploring Bilingual Coding for Inclusive Computer Science Learning, was presented at the ACM SIGCSE Technical Symposium 2026. The study included 60 bilingual participants: 40 novice and 20 experienced participants. I am one of nine listed authors, seventh in author order.

Teach the concept and the syntax as related but separate tasks

A useful lesson makes the layers visible. For example, when introducing conditionals, identify the reasoning task first: compare a condition and choose one of two paths. Then identify the language task: write the comparison in the target language, use the required punctuation, and understand the branch syntax. A student who selects the right path in a diagram but misses a colon or brace has given a different kind of answer from a student who cannot yet describe the decision.

A simple classroom sequence

1. Start with meaning. Use a concrete situation, a trace table, or plain-language pseudocode to establish the decision or transformation.
2. Name the code form. Introduce the vocabulary and syntax as a representation of the already-discussed idea.
3. Compare examples. Put two short snippets side by side and ask what changes in behavior versus what changes only in notation.
4. Invite explanation before correction. Ask the student to describe what they intended before pointing to the syntax error.
5. Return to the concept. Have the learner test the program against the original situation, not just the compiler message.

Use errors as language data

Error messages can be unusually dense for a new programmer: they contain unfamiliar vocabulary, file locations, punctuation, and an implied model of how the language parser works. Instead of treating them as a final verdict, turn them into a routine. Locate the reported line, read the relevant syntax aloud, state the expected structure, and compare it with the written structure. This gives learners a repeatable procedure rather than a reason to avoid errors.

Tutors can also distinguish between an error caused by an incomplete programming model and one caused by a surface-level convention. The response should match the cause. A learner who has reversed a condition may need a trace; a learner who has omitted a parenthesis may need a deliberate syntax check. Both deserve care, but they are not the same intervention.

Build multilingual participation without forcing disclosure

Not every bilingual student wants to translate publicly or become the classroom representative of a language. Offer options rather than assumptions: private notes, bilingual glossaries, partner talk, labeled diagrams, and a chance to explain an idea in the language that helps them reason. The goal is agency. A student should be able to use linguistic resources without being asked to perform identity for the class.

This is particularly important when the instructor does not share the student’s language. Clear examples, stable terminology, and multiple ways to demonstrate understanding help without requiring the instructor to imitate fluency they do not have.

What to assess

Assessment should reveal which layer needs support. Pair a small code task with one question that asks for a trace or explanation. Review whether the student can predict an output, identify an invariant, or articulate the purpose of a variable. If code fails but reasoning is solid, make the next step explicit: syntax practice, documentation reading, or debugging routine. If reasoning is unclear, revisit the model with a smaller example.

The benefit is practical: teachers and tutors can give more precise feedback, and learners can see progress that a compiler alone cannot show. For a narrower discussion of the same distinction, read Programming syntax can be the barrier—not programming logic. The research context and exact poster citation are available on the research page.