Translating a PhET interactive simulation quickly means making its controls and scientific labels understandable in another language without changing what students think the simulation is showing. A dependable PhET simulation translation QA workflow checks target-language strings in the actual simulation, not only in a spreadsheet. It protects scientific distinctions, units, variable labels, and inquiry actions while fitting words into a compact interactive interface.
A learner exploring a circuit may need to distinguish “current” from “charge,” “voltage” from “energy,” and “open switch” from “closed switch.” A mistranslated label can cause the learner to form the wrong explanation even when the simulation’s numerical model works perfectly. If the translated button says “stop” when it really pauses time, a student may misread what has happened to the physical system. The language is part of the experiment, not decoration around it.
This article teaches one reader job: review a localized PhET science or mathematics simulation so that students using the target language can operate controls, interpret quantities, and investigate the same conceptual relationships as students using the original. It addresses current HTML5 translation practice, older legacy utilities, scientific terminology, contextual QA, failure modes, testing, and transfer. It does not offer an unauthorized way to edit PhET’s production translations or replace the platform’s own approval process.
Start with the simulation and the learning question
A simulation is a model designed for exploration. Its labels tell the learner which variable can be changed, what to observe, and how to interpret feedback. Those words may be very short because the interface has limited room. Before translating a single string, open the simulation in the source language and ask what a student is meant to investigate. Is the task to compare two forces, adjust a resistance, predict a graph, build fractions, or explore the effect of mass on motion?
Without that learning question, a translator can choose a perfectly ordinary word that points students toward the wrong concept. For example, “strength” might refer to field strength, force magnitude, or brightness depending on the simulation. The same English noun can require different target expressions in different scientific contexts. A bilingual teacher who understands the model can often resolve the question faster by manipulating the control than by comparing dictionary definitions.
Record the simulation title, version or date if visible, delivery format, target locale, and the intended education level. A translation that looks fine in an older build may be incomplete in a later release with extra controls. Avoid treating a screenshot from an unrelated simulation as proof of correctness. The test artifact is the actual simulation version that students will launch, with its current strings and its real interactions.
Understand the available translation routes
PhET’s current translator information distinguishes HTML5 simulations from legacy Java and Flash pathways. Its public translator page says HTML5 simulation translation is performed through a browser and that the HTML5 Translation Utility is available to trusted translators. The older Translation Utility page describes a downloadable JAR-based workflow for legacy simulations, including testing and submitting string files. These are not interchangeable methods for every simulation in the catalog.
This distinction matters when preparing instructions for a school team. Do not tell a translator working on a current browser-based HTML5 simulation that downloading the Java legacy utility is the standard required path. Equally, do not assume a school can directly edit production strings simply because a public repository contains translation data. Access, contribution, review, and publication remain subject to PhET’s processes. The QA workflow in this article can be used by authorized translators and also by teachers reviewing existing localized simulations without modifying PhET resources.
Start at PhET’s official “For Translators” page, confirm the route for the specific simulation, and follow the current instructions. A teacher who only wants to report an incorrect word should use the project’s issue-reporting channel rather than making an unofficial fork and presenting it as a PhET translation. Accurate content and accurate provenance go together.
Separate scientific UI, teaching resources, and website text
A PhET experience may involve a simulation, its surrounding website, a teacher guide, classroom instructions, and downloadable materials. These are related but different localization surfaces. A simulation control can be translated correctly while the associated lesson plan remains in English; the reverse is possible too. A single successful QA pass should not be described as having translated the entire PhET ecosystem.
For this reader job, concentrate on strings embedded in or displayed by the interactive simulation: panel titles, control labels, graph axes, readouts, tooltips where present, accessible descriptions where relevant, and other learner-facing instructions. Teacher Tips and activities may require separate authoring and review, while the website has its own translation workflow. PhET’s translator page explicitly distinguishes those resources and provides separate guidance for Teacher Tips.
This boundary helps the team work quickly. It can prioritize the strings that influence interaction and scientific interpretation instead of attempting to review every website page. It also makes the QA report meaningful: “The current circuit simulation’s Malay control labels were tested in the browser” is a concrete claim, whereas “PhET is translated into Malay” is too broad and may mislead the next teacher who opens an untranslated resource.
Model the interface as a sequence of decisions
A student does not encounter interface words randomly. The learner reads an objective, locates a relevant control, changes a quantity, observes an effect, and explains the result. Each stage depends on the language of the previous stage. If a control is mislabeled, the student may change the wrong variable. If the readout is mislabeled, the student may observe a valid result but interpret it incorrectly. If the graph label is wrong, the final explanation may be conceptually reversed.
A useful review map follows that action path. Write down the initial state, the control the learner should adjust, the observable or graph that responds, and the intended causal statement. For example, in a hypothetical circuit task, the learner increases resistance while holding another factor constant, observes the current reading, and explains the change. The reviewer needs to ensure that the translated terms consistently distinguish resistance, current, and voltage through the whole task.
This mechanism-first view is more efficient than checking strings alphabetically. It directs attention toward interactions whose language can change the science. A menu item containing a harmless stylistic variant may be lower risk than a one-word axis label that determines whether a graph shows speed or acceleration. Review effort should follow educational impact, not string length.
A short scientific word can carry several meanings
“Current” is an excellent example. In everyday English it can mean present-day, while in electricity it refers to an electric quantity. In a lesson about water it may refer to flow. A translation memory that selects one target phrase for every occurrence will fail across domains. The translator needs the simulation context and sometimes a short demonstration of how the quantity is measured.
Other words have similar ambiguity: “charge,” “work,” “power,” “force,” “potential,” “weight,” “mean,” “field,” “rate,” and “normal.” Their meanings are not interchangeable. The label “work” in physics refers to energy transfer associated with force and displacement, not merely effort. A word for “power” that means authority in ordinary speech may be wrong for watts. When students already use established subject terminology at school, respecting that conventional meaning reduces confusion between digital exploration and formal lessons.
Create an evidence-based term sheet keyed to the simulation and concept rather than a global dictionary entry. Include the source label, intended physical or mathematical meaning, unit where applicable, likely misconception, and chosen target phrase. The aim is not perfect literal symmetry; it is consistent scientific reference. Short labels should be evaluated against the complete concept they name.
Controls must describe actions accurately
Buttons such as play, pause, reset, step, switch, show, and hide appear simple. Yet their exact behaviour can differ. A control that pauses a clock is not necessarily equivalent to stopping an experiment and clearing its state. A reset button may restore initial values while a pause button preserves a configuration. A translated interface that conflates them can cause learners to lose a setup they intended to compare.
Test every action label by clicking it in the actual simulation and observing the state transition. Do not guess from an icon’s appearance. A circular arrow may reset one panel, restart a simulation, or restore only a particular control. A checkbox labeled “Show forces” may overlay arrows without changing the physical model. If the translation implies that the forces are turned on rather than merely displayed, a student could mistake visualization for intervention.
In the term sheet, classify controls as changing model state, changing visualization, changing time progression, or changing the user interface. That distinction guides wording. For example, “Show values” is an observation action; “Increase voltage” is an intervention. The translation should preserve the difference, especially in inquiry activities where students are learning what counts as an independent variable.
Preserve what the model does and what the display shows
Interactive science tools often separate underlying quantities from the way they are visualized. A slider may change mass, while an arrow simply shows a vector’s direction and magnitude. A display toggle may reveal energy bars without creating energy. Translators must ensure that labels for visibility and labels for variable changes are not confused. Otherwise students infer cause where the software is only offering representation.
Suppose a hypothetical motion model includes “Show velocity vectors” and “Adjust friction.” A translation that turns “show” into “increase” changes the meaning of the first control. A student may believe clicking it changes the object’s speed, when it actually only displays arrows. The simulation continues to behave consistently, but the learner’s explanation may become inconsistent because the control wording makes a false claim about causation.
The reviewer should perform a simple manipulation test. Toggle the display feature while leaving physical settings unchanged and note whether the underlying motion changes. Then adjust the actual model parameter and observe the response. The translated labels should allow a student to distinguish these experiments. Language verification becomes a way to protect understanding of variables, controls, and observations.
Preserve numerical meaning and units
Readouts can display quantities with units such as volts, amperes, newtons, metres, kilograms, seconds, or degrees. The symbol often remains stable while the accompanying words change. A translator should not convert units or reinterpret a quantity without a deliberate simulation design decision. Replacing a label for mass with a familiar word for weight, for example, could mislead students because mass and gravitational force are different physical quantities.
The distinction becomes visible in numerical tests. A mass of 2 kg does not become 2 N simply because the target-language everyday vocabulary uses “weight” loosely. A graph labeled “position” should not be translated as “distance travelled” if negative positions or direction matter. Similarly, “average speed” differs from “average velocity” when direction changes. If a localized axis name blurs the distinction, the simulation can still plot accurate numbers while learners describe the wrong variable.
Review each numerical field with its dimension, symbol, and one concrete example. Have a subject specialist write a sentence interpreting a displayed value. If the target phrase cannot support the same sentence, revise it. Where decimal separators or digit shapes vary, test the actual deployed interface; do not assume the translation utility changes numeric formatting solely because a locale code is present.
Placeholders are data boundaries, not loose punctuation
Some localization strings include runtime placeholders for numbers, object names, or values. In older PhET technical descriptions, parameterized strings used Java MessageFormat-style tokens such as {0}. The exact mechanism may vary between simulation generations and should be checked against the current tool’s guidance. The general invariant is the same: preserve the token identity and test whether its position and surrounding grammar are correct in the target language.
Imagine a label reading “Voltage: {0} V.” A translator might remove {0} because it looks like a code artifact or move the unit into a grammatically awkward place. The real simulation later substitutes a live number, and the displayed readout becomes incomplete. A second error occurs when a source language orders the quantity before the noun but the target language requires a different order. Reordering may be legitimate if the localization format supports it, but dropping or altering placeholder syntax is not.
Check tokens in context rather than only comparing counts. If a string contains two placeholders, ensure that each still refers to its intended quantity; matching the number of braces alone does not guarantee correct association. Test at least two runtime values so singular/plural behaviour or units do not mislead learners. When uncertain about a format, mark it for technical review instead of improvising a parser rule.
Graph axes are part of the mathematical statement
Many simulations let students interpret graphs and plots. The meaning of a plotted line depends on the axis variables, units, scale, origin, and sometimes sign convention. Translating the graph title while mislabeling an axis changes the apparent relationship. A pupil might say that velocity increases over time when the graph actually shows position. The underlying data remains valid, so the error can escape software testing.
Consider a position-time graph where the line’s slope represents velocity. If the target y-axis label means “distance travelled,” the graph may seem to prohibit negative positions or imply cumulative travel. The learner’s interpretation then diverges from the source. For a velocity-time graph, positive and negative regions have different implications for direction and displacement. A single ambiguous word can make an inquiry prompt about area under a graph much harder to answer honestly.
Check each graph as a mathematical sentence: “The vertical axis represents X, measured in Y, against the horizontal axis Z.” Verify that a student can say this naturally in the target language. Test a graph region with positive, zero, and negative values when supported. This exposes labels that sound acceptable for positive-only examples but fail under the actual range of the simulation.
Visual labels must fit without losing conditions
Interactive controls often sit in narrow panels. Translating from English into another language can expand the text. A longer phrase may overlap a slider, wrap beside a unit, or hide part of an instruction. The temptation is to shorten the target aggressively. Yet dropping a qualifier such as “net,” “average,” or “per second” can change the scientific claim. The correct QA priority is meaning first, then workable presentation.
When a target label is too long, try a standard accepted abbreviation, a shorter scientific term, or an approved interface adjustment if the PhET translation workflow supports one. Do not invent cryptic abbreviations that only a teacher can decode. A caption that clips one word can be worse than an English fallback because it may appear to assert a different quantity. Subject specialists and language reviewers should agree on the shortest phrase that preserves the important distinction.
Test the layout in the real browser or application window at the size students will use. Include a narrow display, not only a large desktop monitor. Inspect when sliders are at their extremes and when tooltips or additional panels are open. If the platform itself cannot display the necessary text clearly, report the issue to the authorized maintainers instead of hiding it by changing scientific meaning.
Distinguish translations from pedagogical adaptations
A PhET simulation may be used with an English-language lesson or a locally developed activity sheet. Translating interface strings does not mean replacing scientific examples, changing equations, or rewriting the classroom sequence. Those choices might improve relevance in a local setting, but they are instructional adaptations that require separate subject approval and may fall outside the simulation translation tool.
Suppose a teacher wants to use a familiar local power-grid example for a circuit inquiry. That could belong in the teacher’s worksheet, but it should not automatically change every UI label about voltage or power. The core simulation must remain consistent across classrooms. A translator may suggest clarifying explanations or glossary notes for the worksheet, especially for terms whose everyday meanings differ from physics, while protecting the labels that directly describe the model.
This separation is useful for eduKate families. Students benefit when the simulation’s scientific terms match school vocabulary, but the teacher can still choose examples and reflection questions suited to the syllabus. Keeping interface localization distinct from lesson authoring lets both improve without creating conflicting versions of the underlying experiment.
Work a circuit example: current versus charge
Imagine a learner is using a translated circuit simulation to explore batteries and resistance. The English source distinguishes electric charge from electric current. Charge describes an electrical property and quantity; current refers to the rate of charge flow through a section of the circuit. A translation that uses the same undifferentiated target phrase for both can encourage the misconception that current is a stock of charge stored in one component.
A bilingual science reviewer should open the simulation, manipulate an appropriate circuit, and inspect each displayed term beside its symbol and unit. A label associated with amperes should not be interpreted as a total count of electrons. A label associated with charge should not be described as “per second” unless the model specifically means a rate. The reviewer should ask a student-style question: “What changes when resistance increases?” The answer must name the variable actually shown in the readout.
If the target vocabulary contains established local curriculum terms, use them consistently. Where the language has an everyday ambiguity, the teacher may introduce a short glossary in the lesson activity. Do not rewrite the model or invent new controls. The acceptance test is whether the translated interface supports the same correct causal discussion as the source-language interface.
Work a force example: net force versus applied force
Suppose an interactive mechanics model shows an applied force arrow, a friction force arrow, and a net-force result. The label “net force” must not become simply “force” if the unqualified phrase can refer to any individual force. Students need to understand that net force is the vector sum of forces, not an extra independent force acting on the object. A mistranslation may make the simulation appear to contain one more force than it actually models.
Test a configuration where two equal opposing forces produce zero net force. If the translated result suggests “no forces” rather than “zero resultant force,” it fails the science. The interface may correctly display two arrows of equal magnitude while a pupil, guided by the wrong label, believes the forces vanished. The best target phrase is one the pupil can use to describe this situation without contradiction.
Check changes across several states: applied force greater than friction, applied force equal to friction, and applied force less than the opposing effect where the model permits it. The translated labels should continue to distinguish individual forces, direction, and net result. This is a better test than approving a dictionary synonym for “net” without ever observing a vector diagram.
Work an energy example: kinetic, potential, and total
A hypothetical energy simulation shows kinetic energy, potential energy, and total energy in bars. The labels must preserve those distinctions. Translating all three as “energy” removes the comparison the learner is meant to make. Students may then see bars changing and conclude that total energy randomly appears or disappears because the specific forms are not named clearly.
For a simple scenario in which an object moves downward, a student should be able to say that gravitational potential energy decreases while kinetic energy increases, subject to the model’s assumptions. In a system including friction, thermal energy may also matter. The target-language labels should make each category identifiable so the learner’s energy account can follow the model’s representations. Do not add a conservation claim that the current model does not support or omit a visible energy form merely because its target term is long.
The review method is to point at each bar, say what quantity it represents, and predict how the display changes after one controlled action. Repeat in the target language with the same task. If the resulting explanation changes its physical meaning, repair the vocabulary. This test connects translation to conceptual transfer rather than evaluating labels in isolation.
Work a graph example: position and distance
A motion simulation might show position along a line and allow a student to move an object left and right. The word “distance” could mean total path length, while “position” specifies location relative to a reference point. A translated label that swaps the two can create a major misconception about what a negative value means or why returning to the start does not mean zero distance travelled.
Ask the reviewer to begin at zero, move a model object three units right, then two units left. The final position is one unit right, while the distance travelled is five units in this simple path. If the target interface calls the position readout “distance travelled,” a student may reasonably expect five, not one. The software has not failed, but the localized science has. This is a direct conceptual counterexample, not a subtle matter of style.
The correct term should refer to the measured variable in the readout, and any lesson activity should preserve the distinction. Repeat the test with movement past the origin or a change of reference direction when supported. A translation that survives those situations is more credible than one checked only in an easy positive-direction example.
Work a fraction example: numerator and denominator
A mathematics simulation may represent fractions using partitioned shapes and numerical labels. The numerator describes how many equal parts are selected; the denominator indicates how many equal parts make a whole. A translation that reverses these terms can make every visual example seem contradictory. Even when icons and symbols remain correct, the child’s spoken explanation will invert the mathematics.
Use a fraction such as three fourths and have a reviewer describe the picture and its notation in the target language. There should be four equal parts in the whole and three selected parts. Then change the denominator while holding the numerator where the simulation allows. The learner must still be able to explain what changed. If one label has an ambiguous classroom meaning, use the established mathematical term rather than a casual everyday paraphrase.
This worked case shows why a simple numeric example is so effective. The translator may be highly fluent but uncertain about formal subject vocabulary. A bilingual mathematics teacher can verify the mapping by asking the same conceptual question students would face. Accurate words enable students to transfer between visual models and symbols, which is often the educational purpose of the simulation.
Work a units example: mass versus weight
An interactive model might display an object’s mass in kilograms and forces in newtons. In everyday speech, people frequently say “weight” when they mean mass. If a translation adopts that looseness in a scientific label, it can undermine a lesson about gravity. The student may think the object’s measured mass changes merely because the gravitational field changes, when mass remains a separate property.
Test an example with a 2 kg object and compare the labels to the units. The term beside kilograms should correspond to mass, not force. A displayed value in newtons may correspond to weight or another force, depending on the model. The reviewer should not replace terms based only on which word sounds common in casual conversation. In the classroom, precision matters most where two everyday senses are deliberately separated by the curriculum.
If the model represents weight explicitly, a target-language distinction must remain consistent across sliders, axis labels, and teacher directions. In an education portal, a short explanatory note outside the simulation can help pupils bridge everyday words and technical ones. It should not require corrupting the model’s own label to accommodate informal speech.
Scientific negation and qualifiers are high-risk
Words such as “not,” “always,” “sometimes,” “maximum,” “minimum,” “constant,” “total,” and “net” may be short enough to disappear when a translator compresses a label. However, they often determine the exact proposition a learner is meant to infer. A question asking whether a quantity remains constant is different from asking whether it changes. A label for maximum acceleration does not describe an ordinary instantaneous acceleration value.
Use logical counterexamples to check these words. If a button says “show only positive charges,” verify that negative charges remain hidden while positive charges are displayed. A translation that drops “only” may promise all charges instead. If an instruction says “keep temperature constant,” manipulate another variable and confirm that the learner still understands temperature as controlled rather than observed. These checks align language with experimental reasoning.
A useful risk register separates harmless stylistic variations from science-changing omissions. The latter should block the affected string or simulation release. Fluency should be assessed after the scientific proposition is fixed, because no degree of natural wording can rescue a label that names the wrong quantity.
Layout testing should include realistic classroom devices
Teachers may launch simulations on a large display, while students use smaller laptop screens or tablets. Longer translations can wrap into adjacent controls, cover values, or create clickable areas that appear misaligned. A simulation might work during an office desktop review and fail during a classroom session. The safest QA checks the relevant platforms listed by PhET for that simulation and uses realistic viewport sizes.
On small screens, inspect control panels, graphs, legends, popovers, and labels at both minimum and maximum parameter settings. A live value may add digits that make a translated label overflow. Check whether a long target phrase pushes the unit symbol out of view, which could lead pupils to report a dimensionless quantity. If the interface supports zoom, test its normal operating range. Do not alter scientific wording simply to hide a layout problem without checking with the project maintainers.
Record the exact conditions in the QA ledger: simulation title, locale, browser, viewport, interaction state, observed defect, and screenshot where appropriate. A specific report such as “the resistance label overlaps the slider thumb at tablet width in the target locale” is actionable. A generic “language looks odd” report is harder to reproduce and may be dismissed even when it conceals a serious science problem.
Include keyboard and accessible meaning in the review
PhET works toward accessible interactive learning, but accessibility features vary by simulation. A translation review should check the controls and descriptions actually provided by the chosen build, without assuming that every simulation has identical screen-reader, keyboard, or alternative-input support. The purpose is to preserve access to the same meaningful interactions wherever those features exist.
A control may have a visible label and a separate accessible description. If the visible label is translated but the accessible text remains incorrect or out of sync, users relying on assistive technology may receive different instructions from sighted peers. A button whose accessible name says “increase voltage” but whose visual action adjusts resistance creates an especially serious ambiguity. Reviewers should use the real target-language interface and assistive pathway, not only inspect text in a resource repository.
When a language is written right to left, test mixed mathematical notation and units carefully. Logical order of symbols should remain stable even when the surrounding prose direction changes. If accessibility or directionality defects cannot be fixed through the authorized translation tool, report them with exact reproduction steps. An untested claim of universal accessibility is less helpful than a clear statement of what was verified and what still needs specialist attention.
Use teacher inquiry prompts as an independent check
A simulation’s labels should support the reasoning task a teacher assigns. An effective QA technique is to give a bilingual reviewer a simple inquiry prompt: “Predict the effect of increasing this parameter; change one variable; observe the result; explain the relationship.” The reviewer uses the localized simulation without consulting the English strings and attempts the task. If labels are ambiguous, the difficulty becomes obvious when the reviewer cannot decide which control to change.
A second reviewer can perform the same task in the original language and compare predictions and explanations. The aim is not identical sentence structure. It is that both readers identify the same independent variable, observation, and relationship. If one language user describes a graph of displacement while the other believes it represents distance, the translation has changed the investigation. A term spreadsheet might never reveal that failure.
This approach is especially useful in tuition and classroom settings because it asks whether the translation actually supports learning. It also helps translators prioritize: strings connected to core inquiry actions deserve more careful review than decorative surrounding text. The method remains lightweight enough for a small team with limited time.
Make a compact string-context ledger
For every high-risk string, record its identifier where available, source wording, target wording, simulation version, screenshot or interaction context, science concept, unit or symbol, and verification status. Include a field indicating whether the string is UI control, scientific readout, visualization option, explanatory label, or accessibility text. This structure helps the team distinguish similar English words used in different ways.
A current label may be attached to a readout in amperes, while another occurrence of “current” in the website text means “current version.” The ledger prevents a global memory from applying one translation to both. It also makes the next update easier: when a simulation adds a new string, the translator can see established decisions for the same concept without reinterpreting all previous labels. A note about an approved abbreviation can prevent future re-expansion that would break narrow panels.
Protect placeholders and resource keys according to the official translation workflow. A string identifier is not a sentence to translate. A QA report should show what was edited and which system values remained unchanged. This is more credible than claiming that a translation is correct because a word count in the source and target files matches.
Build an efficient pilot before reviewing a full simulation
Start with one high-impact control, one readout, one graph label, and one explanation or help string if the chosen simulation contains them. Translate or review these in the authorized workflow, then test the actual interactions. Choose cases that expose potential misunderstanding: a numeric placeholder, a label with a scientific false friend, a long string, and a state where two variables move in opposite directions.
The pilot reveals whether the localization tool’s preview matches the deployed simulation, whether language tags route correctly, and whether the target fonts and directionality display cleanly. It also establishes a shared term sheet and a clear method for reporting PhET issues. If access to the current HTML5 Translation Utility is unavailable, a teacher can still review the existing localized build and document errors; that is a read-only QA task, not a substitute for an authorized translation submission.
As the review expands, group strings by interaction path rather than alphabetically. Test all labels needed to perform one experiment, then move to the next. This connects individual words to a coherent learning experience. It is more efficient than validating hundreds of phrases without knowing whether students can complete a single inquiry correctly.
A changed-context exercise: a graph appears correct but teaches the wrong thing
A teacher uses a hypothetical motion simulation in which the vertical graph axis is position and the horizontal axis is time. Students move an object right, then left, returning to the origin. The localized graph axis is labelled “total distance travelled,” while the numerical trace returns to zero at the end. A reviewer says this should pass because the plotted line is unchanged and the words are grammatical.
The reviewer’s conclusion is wrong. Position and total distance are different quantities. Returning to the origin makes final position zero in this scenario, while total distance travelled remains positive after movement. A student who follows the translated axis label is being asked to interpret a value the graph is not displaying. The repair is to use the established target-language term for position while preserving the graph data and model behaviour. Test at least one round trip, not just one-way motion.
Now vary the scenario. Suppose the graph really is total path length over time and never decreases during motion. A “distance travelled” label may be correct. The transferable test is to compare the conceptual variable, units, and time behaviour rather than to prefer one phrase universally. A good translator asks what the graph measures before deciding what its label should say.
Transfer to other interactive science software
The principle extends beyond PhET to simulations built with other tools, digital laboratory dashboards, and inquiry animations. The software may expose sliders, graph labels, toggles, instructions, and runtime values; a localization that changes how students interpret a control can change the apparent experiment without changing the code. Protecting variable identity, quantity, units, and action semantics is broadly useful across educational technology.
The exact contribution pathway will differ. A custom school simulation might use editable JSON, while PhET has its own translator programs and approved submission processes. Do not transfer specific utility steps or file formats blindly between platforms. Transfer the reasoning: identify the intended inquiry, classify strings by function, translate scientific labels in context, protect placeholders, and test actual interactions. This is a much stronger method than translating from screenshots alone.
For learners, the benefit is conceptual continuity. A student reading in Malay, Chinese, Tamil, or another language should be able to ask the same question of a model and reach the same scientifically defensible explanation. The interface is successful when it becomes a trustworthy bridge to understanding, not merely a translated surface.
Prioritize defects by educational consequence
A translated label may be slightly awkward yet still allow a learner to identify the correct variable. Another may be smooth and compelling but refer to the wrong physical quantity. These defects need different priorities. High-severity issues include wrong unit names, swapped numerator and denominator, current versus charge confusion, misleading control action, missing negation, and graph labels that cause incorrect interpretation. They should block the affected release or prompt correction through the official channel.
Medium-severity issues might include overlong labels that still render completely but slow recognition, minor register inconsistencies, or accepted synonyms used differently in related panels. Low-severity preferences such as punctuation choices should not take attention away from mathematical truth. The severity framework helps a small educational review team allocate effort sensibly while still acknowledging that interface polish matters for everyday use.
Every issue record should state what the learner would wrongly believe or do, not merely which word the reviewer dislikes. “Current label could be read as charge stored in the battery” is a more useful diagnosis than “bad translation.” It tells translators what concept must be preserved and tells maintainers how to reproduce the problem.
Practical acceptance checks for a localized PhET experience
Open the named simulation in the actual target locale and confirm the version. Review core controls, units, graph titles, and readouts against the source concept and the relevant school terminology. Operate each important control, observe changes, and check whether the translated action word matches the observed effect. Test runtime numeric values and longer labels across realistic window sizes. Keep the scientific model and simulation identifiers unchanged; do not treat translation as permission to alter parameters.
Next, run one inquiry from start to finish as a learner. Ask the reviewer to predict, manipulate, observe, and explain in the target language. Check whether the same controlled-variable logic and scientific relationship are accessible as in the source. Where the simulation provides accessibility text, review its meaning through the actual supported pathway. Record untested platform or assistive combinations honestly rather than implying universal coverage.
Finally, use the current authorized PhET translation or reporting process for changes. Distinguish review of a publicly available translation from submission of a new one. A verified defect is useful even when the local team cannot directly edit the production resource. QA is finished when the issue has clear evidence and an accountable route to correction, not when someone privately modifies a file that students will never receive.
Summary: the interaction is the real sentence
The core mechanism of simulation localization is causal interpretation. Students read a control, take an action, see a response, and form a scientific explanation. Translate each label in relation to that chain rather than as an isolated word. Preserve distinctions such as position versus distance, current versus charge, mass versus weight, and display versus intervention. Keep placeholders and mathematical symbols tied to their original meanings, and test the rendered simulation.
A fast translation becomes dependable when a learner in the target language can carry out the same inquiry and describe the same relationship as a source-language learner. That standard gives teachers a practical way to judge quality without pretending that fluent prose alone guarantees correct science.
Frequently asked questions
Can anyone directly edit the production strings of an HTML5 PhET simulation?
PhET’s official translator information says HTML5 Translation Utility access is limited to trusted translators. Reviewers should follow the current contribution or issue-reporting route.
Is the legacy Java Translation Utility the standard route for all PhET simulations?
No. The JAR-based instructions concern legacy pathways. PhET provides a separate browser-based route for current HTML5 simulations.
Why check scientific terms inside the simulation rather than a spreadsheet?
The same English word can refer to different concepts depending on the control, graph, unit, and experiment. Context determines the correct target term.
Should units be translated like ordinary nouns?
Unit names may have conventional target-language forms, but the quantity and its symbol must remain scientifically consistent. Do not silently change the unit system.
What if a translated label is too long for the control panel?
Seek an approved concise scientific term or report a layout defect. Do not remove conditions or qualifiers that change meaning merely to save space.
Are graph labels just visual decoration?
No. An axis label defines the quantity being plotted. A wrong label can make the same graph appear to support a false scientific conclusion.
How should placeholders such as {0} be handled?
Protect the placeholder syntax required by the relevant resource format, preserve the identity of dynamic values, and test real substituted numbers.
Does translating the simulation also translate Teacher Tips and website pages?
Not necessarily. PhET distinguishes those resource types and their workflows. Report precisely which surface and simulation were reviewed.
Can a teacher report an error without having translator access?
Yes. PhET provides an issue-reporting route. A teacher can collect reproducible evidence from the existing localized build.
What is the final acceptance criterion?
A learner should be able to operate the target-language simulation, interpret the correct quantities, and complete the same scientific inquiry without being misled by its labels.
Authoritative sources
- PhET Interactive Simulations, For Translators, current public guidance accessed 27 October 2026.
- PhET Interactive Simulations, Translation Utility, legacy Java/Flash translation documentation.
- PhET Interactive Simulations, Translated Simulations, current discovery page for localized simulations.
- PhET project, Babel translation-string repository, public repository description and workflow context.
Suggested internal links
- Vocabulary: What Is a Lexical Gap?
- Vocabulary: What Is an Entailment Test?
- Translate names, numbers, dates and units without changing facts — a complementary factual-identity check.