Scratch 3 Project Translation QA | Dialogue, Variables and Game Logic

A Scratch project can appear wonderfully easy to translate: replace the English dialogue in its speech bubbles, change the instructions on its backdrops, and let the learner play. Yet translating a Scratch 3 game accurately is not merely a matter of replacing words. The language that a child sees, the values that the program tests, and the events that make the game move must continue to agree. This guide shows how to translate a Scratch project, localize Scratch game dialogue and check an .sb3 classroom activity without breaking its logic.

The quickest dependable method is to make a language inventory before editing, distinguish player-facing text from internal identifiers, translate visible speech, questions and graphics, and run the same test journey in the source and target versions. If the game asks a translated question but still expects an English word, the picture may look correct while the learner loses points for a correct response. A playable translation is the acceptance standard, not a tidy-looking list of sentences.

You do not need to know every detail of Scratch’s saved-file structure to conduct this check. Teachers and students can use the visual editor and a copy of the project; technical reviewers can inspect a downloaded project archive when necessary. The important discipline is to protect the original, record what each string does, and test inputs and state changes in the finished language. This chapter explains the mechanism, provides worked examples, identifies common failures and finishes with a repeatable classroom release checklist.

Contents: choose the section you need

Start by defining what must remain unchanged
Make a translation map rather than searching blindly for words
Protect blocks, targets, broadcasts and variables
Work the fraction question from sentence to program state
Translate art, costumes and visible labels without moving controls
Treat timing, sound and speech as part of the message
Design a test journey that catches the hidden branches
Diagnose translation failures by their mechanism
Build a release checklist that a teacher can actually use
Transfer challenge: a treasure game with three languages
When one translation must work in a mixed-language classroom
A final summary worth using
Frequently asked questions
Authoritative references and further reading
Suggested internal reading routes (verify destinations before WordPress publication)

Start by defining what must remain unchanged

Imagine a short mathematics adventure. A sprite named Explorer meets a gatekeeper, receives the question “What is three quarters of twenty?”, and cannot cross the bridge until the correct response is entered. An English version works. A Malay-speaking class needs equivalent instructions. You can translate the question into Malay while retaining the underlying answer 15; you can also translate the success message. But you must establish whether the program is evaluating a number, an English word, a menu choice or some combination. That one decision determines the boundary between prose and program logic.

The project has four kinds of things that often look like language but require different treatment. The first is visible prose: speech-bubble text, ask ... and wait prompts, instructions, stage labels, and names visible on monitors. The second is text that appears inside artwork or costumes: a title on a backdrop, the label of a drawn button, or a word printed on a sign. The third is control text: broadcast message names, variable and list references, costume references, and strings compared by operators. The fourth is editor text: block names and menus supplied by Scratch itself. Only the first two are normally translated as ordinary classroom copy. The third needs a functional decision; the fourth belongs to the editor language setting rather than your game’s content.

A good translation brief therefore states, in one sentence, the learning outcome the game must preserve. In our example, “The student should identify that three quarters of twenty equals fifteen and should reach the next stage after entering the number.” That is more useful than saying “Translate all English into Malay.” The brief tells a reviewer what a correct finished experience looks like, including a mathematical fact, a response format, and a game event.

Before touching the project, duplicate or remix it according to its applicable permissions, identify the authoritative source, and save an unchanged version. Give the translated copy a distinct descriptive name, such as “Fraction Bridge — Malay classroom version.” Record the source project’s author and any attribution required. A remix is a new project, not a justification to erase someone else’s authorship or claim to have designed an activity you adapted. The Scratch Help Center describes remixing and credit as part of its community practice; the relevant guidance is listed in the sources below.

Make a translation map rather than searching blindly for words

A translation map is a small table or worksheet in which every line of important text has a location and a purpose. One entry might read: Stage / opening backdrop / visible title / “Fraction Bridge” / heading / translate and check fit. Another could say: Explorer / first script / speech bubble / “Welcome, traveller!” / greeting / translate. A third might identify the gatekeeper’s ask prompt and another the comparison immediately after answer is returned. These are not identical translation tasks even if they use the same English vocabulary.

Work through the project by player journey, not by alphabetical string. Start with the green flag, continue through the expected path, then branch into wrong answers, help buttons, restarts and end screens. Write down the text visible at each step and the event that advances the user. A game with twenty strings and three branches may be harder to localize safely than one with fifty independent explanatory captions. Branch connections create the risk: the right words might appear on the wrong branch, or a learner might never reach a translated message at all.

For every entry, add four control questions. Who sees it? What triggers it? Does a computer compare its exact characters? Is it also present in artwork or audio? A speech bubble triggered only after two failures deserves special attention because ordinary successful play will never expose it. A button drawn on a costume needs both a visual replacement and a check that the correct sprite or hitbox is still associated with the button. An audio explanation may need a separately recorded translation even if a matching speech bubble has changed.

Do not assume identical English words should receive identical translations everywhere. “Stage” may mean the Scratch stage, a level in the game, or a theatre stage. “Run” may mean execute a script or move quickly. “Answer” may be a variable name, an instruction, or the value returned by the answer reporter. A translation map stores context so that reuse improves speed without turning ambiguous words into mechanical replacements. The map should also distinguish optional polish from errors that stop learning: a slightly awkward title is unfortunate; a correct answer being rejected is a release blocker.

A practical first pass usually takes less mental effort when the translator watches the activity once and captures screenshots at the decision points. This is an editorial technique, not a feature that automatically extracts all Scratch dialogue. The screenshots let the reviewer see whether text, buttons, character expression, and pedagogical purpose match. Write a short test ID beside each image, such as S01 for start, Q01 for first question, and R01 for a retry path. Later those IDs become an evidence trail for the target-language check.

Protect blocks, targets, broadcasts and variables

Scratch programs are constructed from blocks connected into scripts on the stage and individual sprites. The Scratch virtual machine represents the running state and relationships among those blocks; changing what a human sees is not the same operation as changing an identifier. If a program broadcasts a message named open_gate, another script may begin when it receives that message. Replacing the broadcast name on one side while leaving the receiver unchanged can break the event chain. Even if the name looks like ordinary English, treat it as an interface contract unless you deliberately update every connected use.

A similar risk appears with variables. Suppose a score variable is named points. If the variable monitor appears in the target-language game, it may be tempting to rename points to a translated label. Scratch can handle variable renaming through its editor, but external expectations, custom blocks, extensions or worksheets may refer to that name. Decide whether the variable name must be visible, whether a separate explanatory label could serve the child, and whether renaming through the editor is safer than direct saved-file manipulation. Never change a saved identifier because a spreadsheet says its English name is untranslated.

List names, custom-block parameters, sprite names, costume names and backdrop names can play both instructional and technical roles. When an activity switches to a backdrop by name or selects a costume, that name is connected to executable behaviour. A translated display title need not require a translated internal asset name. Conversely, a costume containing visible English words does need a visual-language review even though the costume file itself has no obvious translatable paragraph. The guiding distinction is whether the item is presented to the learner or used to link the program together. Some items do both, and those require coordinated editing and testing.

Scratch 3 projects can be saved as .sb3 archives with project information and media assets. Technical staff may extract and compare project.json to inspect preserved structure, but an archive is not a loose bag of replacement strings. A wholesale search-and-replace inside its JSON can alter internal references, quoted text, or Unicode sequences unintentionally. The safe classroom route is to edit intended visible text inside the Scratch editor, save a copy, and reopen it. Advanced checks may compare the unaffected script and asset structure, but they should confirm rather than replace play testing.

Consider a broadcast named quiz_finished. Translating it in the Scratch editor everywhere it is used might be technically possible, but offers no learner benefit when it is never shown. Leaving it unchanged is not an incomplete translation. It is the deliberate preservation of a private interface. By contrast, the speech bubble “Quiz finished — well done!” should be translated because the learner reads it. Confusing those two occurrences is the root of many avoidable localization faults in block-based projects.

Work the fraction question from sentence to program state

Build a tiny before-and-after test. The source scenario reads, “What is three quarters of twenty? Type your answer.” The learner enters 15. Scratch stores the most recent response in the built-in answer reporter, then a comparison directs the game to success or retry. A target-language reviewer needs to preserve the mathematical relation: three quarters of twenty is calculated as 20 × 3 ÷ 4 = 15. A correct translation may reorder the words but must not change the denominator or the whole amount. That invariant is independent of the language used to ask it.

Write the expected behaviour as a state table before editing. At Q01, the gatekeeper asks the question and waits. At Q02, input 15 advances the bridge and adds one point. At Q03, input 14 displays a helpful retry message and does not add a point. At Q04, blank input is handled consistently with the original project. At Q05, a restart resets the score and question state. The table does more than test grammar: it prevents translation changes from silently altering the scoring contract.

Now translate the learner-facing prompt. Keep the numeric content and the response format explicit. If the source expects digits, the target text should not invite the learner to type the answer in words. “Write the answer as a number” is not incidental wording; it is a condition of fair assessment. If a local language convention might cause a learner to enter 15.0, or if the project performs string equality instead of numeric comparison, test both expected and unexpected forms. Do not promise the application will normalize all forms unless the actual blocks show that behaviour.

For a more revealing case, change the source task to “Type north to follow the arrow.” The source program may compare answer with the literal characters north. A literal target-language translation of the prompt would now invite the learner to type a different word, while the program still accepts only north. You have three defensible options: accept the translated target word by changing the comparison safely, accept both language variants, or keep the required word in English and make that restriction clear. Which one is right depends on the educational purpose. A geography vocabulary lesson is not the same as a navigation logic exercise.

Testing should therefore include both the numerical case and a text-matching case. The numerical case catches changed facts, sign errors and response-format confusion. The text case catches hard-coded language assumptions. When the correct response is rejected, diagnose the comparator before rewriting the translation a second time. A beautifully translated question cannot repair a mismatched conditional.

Translate art, costumes and visible labels without moving controls

Not all Scratch text lives in a speech block. Teachers often paint words directly into a backdrop: “START”, “TRY AGAIN”, “LEVEL TWO”, or “FINISH”. When those words are part of an image, changing a script string will do nothing. Open the relevant costume or backdrop in a project copy and determine whether the text is editable as an object, part of a raster image, or incorporated into a larger design. The method of replacement varies, but the functional test is always the same: the label must be legible and still point to the intended action.

Take a button labelled NEXT. In the source game it occupies a rectangle near the lower-right corner. The localized label is longer and the translator moves the button’s visible design to make room. If the click detection is based on that sprite’s position or a separate transparent sprite, moving the artwork without the interactive target may leave the user clicking an inert area. Reviewers should click near the edges of translated buttons and confirm the same route as the source. Test both the intended area and its surroundings, so a child does not accidentally activate an option next to it.

A translated button should also be evaluated as an instruction rather than just a noun. “Continue” is not always equivalent to “Submit answer,” and “Retry” is not equivalent to “Reset all progress.” If the source button clears a score variable, a mild target-language word that implies only replaying one question can mislead the user. Read the underlying event and use a label that reflects the consequence. That is especially important in classroom assessment where students may be anxious about losing earned points or restarting a timed task.

Fonts and line length are another source of apparently mysterious failure. A speech bubble may wrap differently when the translated sentence expands. Text incorporated in a costume may lose characters when the font lacks the required script. Diacritics, syllabic scripts and right-to-left text need rendered checks, not confidence based on copied text. A translation can be linguistically correct and still invisible. Compare screenshots from the stage in the actual target language, and examine the longest anticipated value rather than the shortest example.

Keep a small artwork ledger containing the asset name, original visible text, new visible text, who edited it, and one before-and-after image. That modest discipline prevents a late-stage change to the backdrop from being mistaken for an updated script and protects the project if the reviewer must restore a layout after a collision. For the final release, use descriptive source-controlled filenames outside the game and preserve the editable art source if one exists.

Treat timing, sound and speech as part of the message

Some Scratch activities move through dialogue automatically. A character says “Find the area” for two seconds, switches costume, then plays a sound. The new sentence may be longer. If the screen advances before a learner can read it, the translated text is functionally absent. This is not solved by counting words alone, because script complexity, reading age, familiarity and font rendering all influence reading time. Observe a representative learner or use a conservative human review, then adjust pacing without changing the underlying learning sequence.

Timing changes should be local and evidence based. Consider three screens: an introduction, a question and a result. If the introduction requires more time in the target language, increasing only its wait is sensible. Increasing every wait in the game can make an otherwise lively lesson tedious and may alter synchronization with music or animation. Keep source and target timing observations next to the translation map. The change log should say which screen needed a different duration and why, not just “slowed down language.”

A Scratch project may use recorded narration, music with lyrics, or text-to-speech features. Each requires an independent check. If a speech bubble and narration convey different instructions, learners receive conflicting signals. If narration is not available in the target language, state that limitation in the classroom notes instead of pretending that changing the visible text has localized the audio. In some lessons a teacher-led reading is an acceptable planned alternative; in a self-guided remote activity it may not be.

Do not assume every voice, pronunciation, or language behaves identically across browsers and devices. Test with the actual playback environment that the class will use. Compare whether speech begins, whether it finishes before the next action, whether the volume is suitable, and whether the learner understands which sprite is speaking. A silent audio block can be a technical failure unrelated to translation; diagnose the sound asset and browser permission before changing approved wording.

Design a test journey that catches the hidden branches

A source-to-target comparison needs more than pressing the green flag once. Create a compact matrix covering starting conditions, one correct answer, one incorrect answer, a repeated wrong answer, an abandoned or blank answer, the help path, a restart, and completion. For each case, note which message appears, which variable changes, and whether the next script runs. If the program randomizes questions, set up a repeatable test path or run enough controlled cases to encounter the relevant questions. Avoid claiming every branch was tested when the playthrough did not reach it.

For a quiz with four questions, a basic coverage plan might contain sixteen observations: four correct-answer checks, four wrong-answer checks, four hint checks and four completion transitions. Sixteen is an illustrative checklist count, not an automated test guarantee. A single option could require additional testing for text encoding, longer answers, or a learner using the keyboard differently. The point is to make coverage visible rather than assume that a fluent first screen proves the whole project works.

Score integrity deserves explicit comparison. Record score before action, input, expected score afterwards, and actual score afterwards. Suppose a source game begins at zero, awards one point for each of three correct answers, and never awards a point for a retry. The expected final score is three after three successes. If the target build ends with four, investigate repeated event handling or a translated button triggering a score event twice. If it ends with two, identify which translated path stopped the success broadcast. Do not simply amend the instructions to match the broken number.

Tests should also include a clean start after reopening a saved .sb3. A project can appear to work while a session retains temporary state, costumes, variable values or cached assets. Save the localized copy, close and reload it, press the green flag and repeat essential tests. Where the browser environment is important, use the actual supported hardware rather than assuming the editor preview covers every learner device.

If multiple people review the project, designate one canonical copy and a clear hand-off. Parallel edits made in separate copies can cause one person’s translated dialogue to overwrite another person’s repaired condition. A single named release candidate with a change log is more reliable than several files named “final-final-really-final.” The purpose of the log is not bureaucracy: it makes the final tests reproducible when the class reports a confusing question days later.

Diagnose translation failures by their mechanism

A project can fail in at least six recognizably different ways. The wrong-language defect shows source text where target text should appear; check whether an overlooked script or artwork asset owns that string. The meaning defect shows fluent language that changes a fact or command; compare the specific worked problem and the expected learning outcome. The input defect occurs when a learner follows the target instruction but the conditional accepts only the original form; inspect the comparison and response guidance. The event defect arises when a broadcast or reference no longer connects; inspect identifiers. The visual defect hides or clips translated text; inspect rendering. The timing defect advances before reading or playback is complete; inspect waits and audio order.

These categories guide repair more accurately than a general “translation error” label. For example, if the correct Malay word appears in the prompt but the game says “Try again,” the first suspect is a string comparison. If no game state advances after clicking a translated label, the first suspect is event wiring or sprite interaction. If only one screen remains in English, the likely issue is an untracked location. The diagnosis prevents a translator from rewriting sound wording to repair an unsound program.

A strong bug report records the exact target version, test case, source string, target string, expected event, observed event, and a screenshot or short reproduction instruction. “Translation broken” cannot be acted upon; “At question 2, typing the displayed accepted word triggers the retry script because the condition still matches north” can. Assign the repair either to language review, project logic, design, media or release packaging. One issue can involve more than one owner, but the final acceptance test must still verify the whole experience.

Be cautious with improvements unrelated to translation. A reviewer may notice a mathematically weak prompt, a confusing game route, or a score rule that was already incorrect. These are valuable findings, but keep them distinct from language changes. Fixing the curriculum issue might be authorized, yet silently changing the intended question makes the target language no longer comparable with the source. Preserve two change categories: translation-equivalence repairs and separately approved pedagogy or logic changes.

Build a release checklist that a teacher can actually use

Before classroom use, ask five practical questions. Is the task objective still the same? Can the learner understand every instruction without guessing the source language? Do all accepted and rejected answers behave as intended? Are the images, sounds and buttons comprehensible? Can the completed project be reopened and used on the target classroom device? Each answer should be supported by a test, not solely the editor’s green flag.

A complete handover includes a copy of the original project, the localized .sb3 or shareable project, a short list of translated assets, a response-format note, and the final test matrix. It is useful to include a one-page teacher note stating the intended age or curriculum context as an editorial decision, not a claimed official Scratch certification. If a worksheet refers to visible names or vocabulary, update that worksheet too; otherwise learners may see two incompatible terms for the same sprite, place or action.

Release with a clear version label and date. Keep the original language and target language in the record, and record whether narration, artwork and assessment responses were included. A label such as “Malay dialogue only — English narration retained” is more informative than “100% translated,” especially when not every sensory channel is localized. This is part of honesty toward teachers and families: it allows them to provide the assistance that remains necessary.

Once a version passes the tests, protect it from casual last-minute changes. A tiny alteration to a button or a comparison can invalidate a previously successful test. If a change is essential, rerun the tests affected by that change and the final completion path. The quicker workflow is not the one with the fewest checks; it is the one that finds an error where it occurs and avoids a full emergency repair during a lesson.

Transfer challenge: a treasure game with three languages

Imagine a treasure hunt using a sprite that asks, “Type the colour of the safe door.” The scene shows a blue door. In the English source, the game tests the exact word blue and broadcasts door_opened after a match. Your class wants both Malay and Chinese versions. Draft the translation plan without opening the editor. Which strings are presented to learners? Which values are used only inside the program? Where could a translated prompt create an unfair answer rule? How would you test the three versions without accepting a different game objective?

The first step is to identify the player-facing prompt, button labels, feedback messages, and any word printed on the blue door. Those are language assets. The broadcast door_opened is an internal event and can remain unchanged in all three versions. The variable tracking treasures and the sprite’s internal name usually do not need literal renaming unless shown to learners. The main functional choice is whether learners must type a word, choose a colour from buttons, or enter a number corresponding to the door. If you retain typed answers, the comparison must accept the correct target-language form or explicitly instruct learners to use the original English term.

A sound test covers the correct word in each language, a wrong colour, case variation if the source rules allow it, an empty response, and a restart. A visual test checks scripts and fonts used for Chinese characters and the length of Malay feedback. If the game is a language-learning task, you may intentionally retain the English colour word as the desired answer, but then the translation must explain that the objective is to practise English vocabulary. That is a pedagogical decision, not something a machine translation system should infer.

Now change one condition: learners do not type; they click the painted blue door. The text-comparison problem disappears, but click-target placement and the artwork’s meaning become more important. This is transfer: the same translation objective moves to a different failure mechanism. The reviewer should not mechanically repeat the original checklist while overlooking the new interaction. The invariant remains that the learner who chooses the correct door reaches the intended next stage.

When one translation must work in a mixed-language classroom

A classroom may contain children who use the target language confidently, classmates who rely on English for certain technical terms, and others who understand spoken instructions but read them slowly. That variety changes testing priorities. The teacher does not have to abandon the new language or fill every speech bubble with multiple translations. Instead, decide where an explicitly bilingual cue supports the learning task and where it makes the stage too crowded. In a numerical fractions activity, keeping the digits 3/4 and 20 consistent while translating surrounding instructions can reduce ambiguity without changing the mathematics.

Build a simple comprehension check before full use. Invite one learner who knows the target language to tell you what the next action is after reading the opening screen. Ask another to explain what response format is required: digits, words, a button click or dragging an object. Then deliberately choose a wrong answer to verify that the feedback teaches rather than merely says “wrong.” Those observations test usability, not just grammar. They should be recorded as small practical findings, not advertised as a statistically representative classroom study.

If the activity introduces new vocabulary, an optional glossary screen can help, but treat it as a game feature with its own event and return path. Adding a glossary is not equivalent to changing two strings. Test whether the learner can open the help screen, return to the same question and keep the original score intact. A glossary button that resets the game or advances to the next question may harm learning more than a difficult word would. That feature also needs consistent language across its title, examples and close button.

The final teacher handover should state exactly what remains in the source language and why. A Scratch editor can display programming blocks in the editor’s chosen language while the game itself contains target-language dialogue. A shared project may also include variable names that a pupil sees only if they open the code. Neither fact proves a failed classroom localization; what matters is whether the planned learner experience is understandable and whether the promised scope is honest. A target-language game intended for independent use should be tested as an independent experience, without a bilingual adult rescuing every unclear instruction.

A final summary worth using

Scratch game translation works when the visible language, the expected answer format and the program’s control flow remain aligned. Inventory all speech, prompts and drawn labels; protect broadcast and variable relationships; keep numeracy, vocabulary and response rules faithful to the educational objective; then compare the same source and target playthroughs, including mistakes and restarts. The best shortcut is a testable definition of success before the first sentence is replaced.

The exercise generalizes beyond Scratch. Every interactive lesson has a presentation layer, a state or evaluation layer, and a way of advancing between activities. Separating them prevents the familiar problem of good translation attached to broken behavior. Teachers can apply the same reasoning to game makers, quizzes and animated lessons without pretending that their files share the same technical structure.

Frequently asked questions

Can I translate the Scratch block labels themselves inside a project?

Scratch’s editor interface language is separate from the visible words created by a particular project. Change the editor language using its supported language controls rather than trying to edit block-language labels inside one saved game. Translating project dialogue is a different task.

Should I rename variables and broadcasts into the target language?

Not automatically. Some names are internal program references and no learner sees them. If a visible variable name must be translated, perform the change carefully in the editor and test every dependent script, instead of applying a blind replacement to the saved archive.

Is an `.sb3` file just a text document?

No. A Scratch 3 project file is a packaged project containing structured project data and media resources. Technically inclined reviewers may inspect it, but hand-editing its internals can damage relationships. Preserve the original and test any changed copy in Scratch.

What if a correct translated word is rejected?

Inspect the program’s actual comparison with answer, including capitalization and string rules. The translated instruction and accepted response must agree. Either adapt the condition or explicitly keep the original answer language if that is the learning aim.

Do translated costumes require separate review?

Yes. Words baked into an image will not change when a speech block is translated. Check line length, font coverage, positioning and any associated clickable sprite or control area.

How can I test a project that chooses questions randomly?

Use a controlled test plan or enough repeatable runs to cover each important branch. Record which paths were actually visited. Do not claim exhaustive testing from a successful playthrough that skipped half the questions.

Do I need to translate narration?

It depends on the agreed scope. If the game is meant to be independently usable in the target language, untranslated narration may be a significant barrier. If the classroom teacher will narrate, note that support openly in the release instructions.

Is it acceptable to change a game rule during translation?

Only as a separate, documented teaching or functional change. A source and target comparison is difficult when the rules changed silently. Fix the translation equivalence first, and obtain agreement for other improvements.

What should I give to another teacher?

Provide the tested project, its language and version label, a quick-start note, the response format, and any known accessibility or audio limitations. A simple trace of the key test cases helps a new teacher trust and reuse the activity.

What is the most revealing final test?

Enter a correct response, a believable wrong response and the exact response invited by the translated prompt. Confirm the resulting messages, points and next stage match the design. Then close and reopen the saved copy to verify that the released asset—not merely the editing session—works.

Authoritative references and further reading

Scratch Foundation Scratch VM repository and current monorepo migration notice, for the role of blocks, targets and the virtual machine; the standalone repository is archived, so consult the linked monorepo for continuing development.
Scratch Foundation Scratch editor repository, for current editor/VM development context.
Scratch Help Center: Remixing and credit, for community practice when adapting shared work.
Scratch project file format background, for a community technical description of .sb3 packaging; this resource is supplementary, not an official complete schema.

How People Translate Quickly | Scratch 3 Project Translation QA: Dialogue, Variables, Broadcasts and Classroom Game Testing