To translate a WeBWorK PGML mathematics problem quickly and correctly, preserve its executable PG structure and answer evaluation while translating the learner-facing question, help, and solution prose. A reliable WeBWorK localization check must verify not only that the new wording is readable but also that it asks for exactly the same mathematical object the software grades. Translation of a PGML problem is a controlled problem-authoring change, not a whole-file text replacement.
A Secondary Mathematics pupil might read “find the greatest integer less than the solution” in English and a translated version that accidentally asks for an integer less than or equal to it. The difference of one small phrase changes the answer. A grader that still expects the old result now marks a reasonable response wrong. Even with a perfectly functioning online system, the teaching has failed because the assessment contract changed.
This guide focuses on one task: taking an existing WeBWorK .pg problem that uses PGML and making a target-language version whose mathematical meaning, randomized parameters, answer blanks, MathObjects, macros, and scoring behaviour remain equivalent. It covers extraction, syntax boundaries, worked examples, deliberate counterexample testing, classroom review, and release decisions. General translation advice, e-learning platform choice, and designing entirely new mathematics questions are outside this page’s ownership.
Know what a PG file actually contains
WeBWorK problem files are not simply web pages with some mathematics embedded. The PG language provides source code for constructing and grading a problem. It uses Perl alongside PG macros and the MathObjects system. Problem files can include a setup, random values, displayed question text, answer rules, and a solution. Modern examples often use PGML—PG Markup Language—to write learner-facing text and place mathematical expressions or answer blanks in it.
This mixture is the source of both power and danger. The visible instruction “Simplify your answer” is language the translator can usually change. The expression Context('Numeric') is a program setting; translating Numeric as if it were an English adjective can make the code fail. The $answer variable is an identifier, not a prose word. The answer blank syntax connects what students see with an evaluator that determines whether their response is accepted. If the translator moves or deletes that syntax, the assessment can break without an obvious visual warning in a document editor.
Start by viewing a problem as two contracts joined together. The pedagogical contract states what the learner must understand and do. The machine contract says which inputs, parser rules, and values the system accepts. Localization must preserve their alignment. A question can compile while making a different demand; it can also read correctly while the code fails to compile. Testing must address both directions.
Map the six working regions before editing
A practical PG file may contain metadata, initialization and macro loading, parameter setup, student-visible text, answer evaluation, and solution text. The exact arrangement varies with problem style, but this functional map is more useful to a translator than the order of every line. It tells us why some parts are editable as language and others are responsible for mathematical behaviour.
In metadata, the problem title and descriptive hints may be human-readable, but tags used for catalog indexing should follow the repository’s editorial rules. Initialization calls load macros and establish contexts; these should be protected. Setup selects numbers, formulas, intervals, and sometimes units; it needs a mathematics author, not an ordinary copy editor, to change. The visible statement and solution are prime translation candidates, but they contain inline code and mathematics notation that need to remain intact.
Answer evaluation may be implicit in PGML answer-rule syntax or explicit through ANS and comparison methods. Either way, reviewers must not assume that a translated instruction automatically changes grading. If a localized question changes from “round to one decimal place” to “round to the nearest whole number,” but the answer checker remains set for decimals, the problem has become internally contradictory. The safe plan is to treat that as a meaning-changing defect rather than quietly adjusting code to match a translation mistake.
A small example with a stable mathematical core
Consider a problem that randomly selects the number of blue and red counters, asks for their total, and checks the learner’s numerical answer. The following is an illustrative PGML authoring pattern using familiar WeBWorK macros; it should be tested in the intended WeBWorK installation before classroom release because macro versions and local conventions can vary.
DOCUMENT();
loadMacros('PGstandard.pl', 'PGML.pl', 'MathObjects.pl', 'PGcourse.pl');
Context('Numeric');
$a = random(2, 6, 1);
$b = random(1, 7, 1);
$answer = Compute("$a+$b");
BEGIN_PGML
A box contains [$a] blue counters and [$b] red counters.
How many counters are there altogether?
[_____]{$answer}
END_PGML
BEGIN_PGML_SOLUTION
Add the two quantities: [$a] + [$b] = [$answer].
END_PGML_SOLUTION
ENDDOCUMENT();A translation should preserve DOCUMENT(), loadMacros, the variable definitions, random ranges, Compute, [_____]{$answer}, PGML delimiters, and ENDDOCUMENT(). It may translate “A box contains,” the colour nouns, the question sentence, and the explanatory solution words. It should also preserve the meaning of “altogether” as addition rather than subtraction or comparison. The mathematical expression displayed through PGML is part of a dynamic result and must remain bound to the same variables.
This example helps because the maths is easy enough to verify by hand. The translator can take a = 4 and b = 3 and ask a bilingual teacher whether both versions demand seven counters. If one translation asks for red counters remaining after removal, the discrepancy is instantly visible. More complicated functions, intervals, and inequalities follow the same principle but require richer test cases.
Separate visible language from executable syntax
The safe way to extract PGML text is to identify prose spans within a recognized problem structure. Even between BEGIN_PGML and END_PGML, not everything is ordinary language. Square brackets can introduce mathematical expressions or answer rules. Braces may refer to evaluators. Variable interpolations draw from code-defined parameters. A translation tool that treats those fragments as normal sentence punctuation may corrupt the problem while showing a convincing target-language sentence.
For example, [$a] is not a decorative way to write the letter a. It may display a randomized number chosen for the current learner. Replacing it with a translated word or changing its brackets means the sentence may no longer display the chosen value. Similarly, [_____]{$answer} is not a blank meant to be translated. It is part of the answer entry and checking arrangement. The translator needs to know what it does but should not alter its internal structure.
A useful extraction sheet therefore includes the source phrase, the untouched inline PGML tokens, the intended task, and a short context example. Many safe implementations protect tokens during translation and restore them by stable identifier. Restoration should be checked by code-level comparison, not by the translator’s memory. If an item has three references to $a, all three must still refer to the same parameter after import.
Mathematical meaning lives in tiny logical words
Some of the shortest words in a mathematics question do the heaviest conceptual work. “At least” means greater than or equal to; “more than” means strictly greater than. “No more than” means less than or equal to; “less than” excludes equality. “Exactly,” “approximately,” “each,” “total,” “remaining,” “distinct,” and “nonzero” can change the mathematical task. A translator who optimizes only for conversational naturalness can lose these constraints.
Imagine the instruction “Find all integers greater than 3 and less than 8.” The solution set contains 4, 5, 6, and 7. A target phrase that effectively says “at least 3 and at most 8” includes 3 and 8, so the answer set changes. The software might still be checking the original four values. This is not merely a minor language preference; it is a grading contradiction. The correct translation should be checked against both an ordinary-language paraphrase and symbolic inequalities.
Build a small logical-word ledger for reviewers. Record how each source condition is expressed in the target language and the mathematical relation it represents. Before release, ask a bilingual mathematician to convert both versions back into symbols independently. If the symbols differ, stop and repair the wording. This check is especially efficient because it focuses on the few terms that create large answer-space changes.
Do not confuse a word problem with a story rewrite
A word problem has a narrative surface and an underlying mathematical model. Translators may feel free to replace settings, names, or objects to make the story more familiar. Some contextual adaptation is reasonable, but it must not quietly change the quantities or relationships used by the answer checker. Even apparently cosmetic changes can shift a ratio, unit, or assumption about whole objects.
Consider a problem about buying three packets containing five pencils each. If the translated story substitutes three loose pencils and five boxes, the multiplication structure may disappear. A learner might respond using addition or counting instead. A different cultural example involving currency may require conversion and rounding rules, which the original evaluator does not support. The simplest safe route is often to retain the numeric structure and translate the surrounding story without introducing a new operational assumption.
If a context needs substantial localization, treat it as a problem-authoring revision with explicit mathematical approval. Write down the preserved invariants: number of groups, size of group, units, allowed answer format, and conditions. Then test a representative random seed. The translator’s job in this series is to preserve the original assessment contract, not to make a new problem that happens to resemble the old one.
Identify the answer object before choosing words
A problem may expect a scalar, interval, ordered pair, set, equation, vector, function, or symbolic expression. These objects are not interchangeable. A target-language instruction that says “give the value” when the checker expects an interval can confuse learners even if it sounds like natural mathematics. The visible wording should name or clearly imply the object the grader accepts.
In an algebra example, “Solve for x” may expect a number. “Give the solution set” may expect a set or interval. “Write an equation” may be graded through an assignment parser rather than a numeric comparison. WeBWorK’s PG and MathObjects features offer powerful answer checking, but the translation has to align with whichever type the original author chose. The reviewer should inspect the evaluator or an author-provided specification rather than infer the expected answer solely from an English instruction.
For each item, create a one-line answer contract: mathematical object, allowed notation, expected precision, permitted order, and whether equivalent forms are accepted. Use that contract to check the translated sentence. This prevents a common QA mistake: the reviewer sees the same displayed formula and assumes the question is equivalent, while the target text asks for a different representation or level of simplification.
Randomization changes how you must test
Many WeBWorK problems use random parameters, which makes one successful preview weak evidence. The translated text may work for one choice of numbers and fail for another. An English template might use a singular or plural noun depending on a random value, or refer to “a positive root” under an assumption that only some seeds satisfy. A target language may require grammatical agreement based on gender, number, or case that the original code does not generate.
Imagine a translation of “There are [$n] solutions” into a language with different forms for one, two, or many. If the random parameter can produce all three, a single hard-coded noun phrase may be wrong for some students. Worse, the wording “the larger of the two roots” becomes false if a random seed yields a repeated root. The original code may already contain that problem; localization should reveal it rather than silently cover it with a vague translation.
Test a deliberate set of seeds or parameter outcomes: minimum, maximum, zero where permitted, negative values where permitted, equality boundaries, and exceptional algebraic cases. The exact number of cases depends on the generator and the stakes. Record whether every test rendered clearly and asked a mathematically valid question. Translating quickly means testing intelligently, not testing a random single instance and hoping the rest behave the same way.
Preserve the distinction between expression and equation
A particularly costly error is turning an expression into an equation, or the reverse. “Simplify the expression” asks for an equivalent form. “Solve the equation” asks for values of a variable satisfying an equality. When a translation uses a generic verb like “calculate” for both, students may enter an expression where the checker expects a root, or a root where it expects a formula.
Take 2(x + 3) as an expression. Expanding yields 2x + 6. If the source asks students to expand, the answer contract may accept equivalent polynomial forms depending on the checker settings. If the translation instead asks for the value of x, that is impossible without an equation or extra condition. A bilingual reader should be able to distinguish the action from the translated instruction alone, without guessing that the machine probably wants expansion.
Build a verb map for each mathematics domain: expand, factor, simplify, substitute, solve, evaluate, estimate, sketch, prove, state, list, and justify. These are not stylistic variations. They correspond to different cognitive jobs and answer objects. The goal is not to impose awkward literal English grammar, but to find the locally accepted instruction that triggers the same mathematical action.
Interval questions expose boundary mistakes
Interval problems are excellent for stress testing translation because tiny wording changes alter whether endpoints are included. An item might ask, “For what values of x is the graph above the x-axis?” The answer depends on strict positivity. If the target language inadvertently says “on or above the axis,” zeros at the intercepts become part of the solution and the interval endpoints change from open to closed.
Official WeBWorK examples show interval contexts and endpoint-sensitive comparisons. A translator should not touch Context('Interval') or an interval answer object simply because the target sentence expresses the idea differently. Instead, derive a test point at each boundary, one point inside the interval, and one point outside. Ask whether the original and translated instructions classify all four consistently. If not, the target condition needs correction.
For a quadratic graph, a learner may visualize the curve touching the axis and reasonably think that “above” excludes that location. The teacher can reinforce the distinction with precise wording, but should not introduce an extra explanation that changes the task from identifying an interval to naming individual intercepts. Use the existing mathematical goal as the fixed reference for translation, and treat ambiguity as a review issue.
Units and precision are part of the grader’s expectations
A word problem may ask for metres, centimetres, dollars, percentages, or rounded decimals. Units can be displayed in prose, appended to answer blanks, or handled by specialized checkers. The translator must determine whether the answer should include a unit or only a number. “Express your answer in centimetres” and “convert the quantity to metres” are different instructions even if both discuss length.
Suppose an English problem asks for the length of a desk in centimetres, and the checker expects 120. A localized sentence that asks for metres invites the mathematically valid answer 1.2, which the unchanged checker might reject. If a translation uses a different currency or measurement example, the problem may require conversion logic outside the original scope. This is why semantic adaptation should be separated from literal language localization.
Precision words matter too. “Nearest tenth,” “three significant figures,” and “round to two decimal places” produce different accepted forms. Test values near rounding boundaries, not only neat integers. If a locale uses a comma as a decimal separator, check what the actual answer parser accepts; changing the displayed punctuation is not the same as changing parser configuration. A localized worksheet is honest only when its stated input rules match the deployed evaluator.
Solutions are not just decorative explanations
WeBWorK may include a BEGIN_PGML_SOLUTION section providing worked steps. The solution can contain instructional language, formulas, and references to random variables. It deserves its own translation review because a problem can grade correctly while teaching the wrong reasoning afterward. The learner may see the right result but an explanation that reverses a causal step or uses an unfamiliar term incorrectly.
A good solution translation preserves not only the final number but the logical sequence. If the source explains that total cost is price per item multiplied by number of items, the translated prose should not imply addition. If it discusses dividing both sides of an equation by a nonzero coefficient, keep the nonzero condition. Math notation should remain linked to the same PG variables unless the author explicitly approves a code revision.
Review the translated problem and solution together. Ask whether a learner who gets the question wrong can follow the explanation to understand the mistake. A solution with fluent sentences but missing transitions is less useful than a concise explanation that clearly relates each equation to the preceding step. The best localization may use natural target-language educational phrases while preserving exact mathematical reasoning.
Feedback labels and partial credit need attention
Some problems provide partial correctness feedback or allow unordered answers. The translator should determine whether the student sees localized instructions for entering several values and whether the grading logic depends on their order. An official PG sample uses UNORDERED_ANS so the answers can be entered in any order. A target sentence that says “write the first, second, and third answers in order” would misrepresent such an evaluator.
Conversely, an ordered pair question may require a particular order, and a translation that says “give the two coordinates” without mentioning the order could be too vague. Do not “repair” this inconsistency by changing the checker unless the user has commissioned an authoring redesign. Record it as an alignment problem and correct the wording or ask the problem owner to authorize a code change under a separate task.
Feedback itself may include app-level messages outside the PG file. A translator preparing an individual problem should not claim to have localized the whole WeBWorK interface. Separate the body of the assessment from shared system strings such as submit labels and scoring notices. This keeps one dominant reader job per article and prevents a file-level QA report from misleading administrators about platform-wide accessibility.
Parser settings are not translation synonyms
The PG MathObjects context controls what kinds of expressions are accepted and how they are interpreted. A problem can define numeric, complex, interval, or specialized contexts, sometimes with flags affecting notation. These settings must be treated as code. Changing them for a supposed language improvement can alter the accepted answer space even when the visible text stays exactly the same.
For example, a specialized complex-number problem may allow a simplified Cartesian or polar form. The translation should communicate those permitted forms. It must not silently change the context to an ordinary real-number parser merely because the target educational textbook uses different terminology. A reviewer who looks only at the rendered problem might never see that the parser was changed; grading failures then appear random to students.
The practical check compares relevant macro calls, contexts, evaluator methods, and answer-rule structures before and after localization. Where a team needs locale-specific answer entry behaviour, such as decimal separators or notation, treat it as an implementation and assessment policy decision requiring direct testing. Linguistic translation alone cannot guarantee that the parser will accept every culturally familiar mathematical notation.
Protect code from automated translation systems
A machine translator may alter variable names, quote characters, control tokens, or the visible order of equations. It might also insert invisible Unicode characters that make a line display attractively but change how the PG parser reads it. These are reasons to extract prose rather than submit an entire .pg file as plain text. Code fences in a document do not prevent an external translation service from trying to translate their content unless the workflow explicitly marks them as protected.
For a robust extraction, assign each translatable span an identifier that points to an exact source location. Capture placeholders and PGML inline expressions as immutable tokens. The translator works on the text segments and supplies a target sentence that still contains the protected tokens. On import, run a structural diff: macro calls, variable definitions, answer rules, and delimiters should match the source baseline for a localization-only project.
Even a source file that parses is not necessarily safe. Compare the actual logic and evaluator configuration, not simply the number of code lines. A moved answer blank might still be syntactically legal but now sit beside the wrong question. The final verdict comes from rendered mathematical equivalence plus student input tests.
Work the first example: a ratio question
An English problem says, “For every 2 blue counters there are 3 red counters. If there are 12 red counters, how many blue counters are there?” The correct reasoning is that four groups of three red counters correspond to four groups of two blue counters, so the answer is 8. Suppose the original PG setup encodes a suitable ratio, a selected multiple, and the answer object 8 for one seed.
A hurried translation may reverse the ratio wording to “for every 3 blue there are 2 red.” That sentence is grammatical, but it now asks for 18 blue counters when red counters total 12. The unchanged evaluator will reject a mathematically consistent response. Another error is translating “for every” as “in total,” which changes a proportional relationship into a sum. The appropriate check is to restate the relationship symbolically in both languages before looking at the answer field.
Repair the target sentence so two blue counters correspond to three red counters, preserve the problem’s randomized numbers and checker, and test another seed as well. If the source randomly chooses multiples of three, verify a low and high multiple. A bilingual teacher should approve both the mathematical relation and the language naturalness. This is faster than debugging complaints after pupils receive different random instances of a misworded problem.
Work the second example: probability and complement
A probability item asks, “What is the probability that at least one of three independent trials succeeds?” The complement method calculates one minus the probability that none succeed. A translator might render “at least one” as “exactly one,” especially where the phrase has no straightforward local equivalent. The expected answer changes substantially. For a success probability of one half in each trial, at least one success has probability seven eighths, while exactly one success has probability three eighths.
The difference is not stylistic. The target text directs learners toward a different event. The code can continue to compute seven eighths and the student can reasonably enter three eighths based on the translated instructions. To catch this, have a reviewer enumerate a simple three-trial outcome space. The English and target conditions must include the same sequences. This test is accessible even when the underlying PG implementation is complicated.
The solution translation must preserve the complement reasoning. It should make clear that “none succeed” is the complement of “at least one succeeds.” If the target-language instructional tradition uses a different but equivalent phrase, accept that natural form after mathematical verification. The assessment contract is the event being counted, not the English word order.
Work the third example: ordered and unordered answers
Suppose a problem asks students to list three zeros of a polynomial. If the evaluator accepts any order, the instructions should not imply that only an ascending list is valid. The source may use UNORDERED_ANS or another technique to compare an unordered collection of entered values. A translation that adds “in increasing order” creates an unnecessary restriction for the learner while the machine continues accepting many orders.
Now suppose the original instead asks for the coordinates of a turning point as an ordered pair. Replacing “ordered pair” with “two numbers” weakens the task because (2, 5) and (5, 2) usually identify different points. The reviewer needs to inspect the actual answer object and its checking policy before deciding which words are essential. A translated instruction should make the same expectations clear, neither adding new restrictions nor silently removing existing ones.
Test by entering the correct answers in alternate orders. Observe whether the displayed system response matches the text. Then enter a deliberately reversed ordered pair and check that the expected rejection occurs. This is an example of black-box testing complementing source-code inspection: even an apparently unchanged evaluator might behave differently after an import, update, or context change.
Work the fourth example: signs and parentheses
A source item says, “Evaluate the expression for x = −2.” The visible expression includes 3x^2 without parentheses around the substitution. Students must understand that squaring x before multiplying by 3 gives 12 for x = −2. A translator who rewrites the expression into an ambiguous plain-text form might instead make it appear that the entire term 3x is squared, yielding 36. The number of words changed is tiny, but the mathematical structure changes.
Use the original mathematical markup and variable placeholders, and translate only the instruction around it. If a locale uses different conventions for multiplication or negative signs, test the rendered mathematical notation, not just the source string. A screenshot may help a teacher see layout, but the actual PG rendering and answer evaluator remain authoritative for behaviour. Check both the source and target sentences with x = −2 and x = 1 so sign-sensitive differences are visible.
The solution text should clearly show the sequence of substitution, exponentiation, multiplication, and simplification. If the source omits a step and the translated teacher wants to add it, record this as a deliberate pedagogical enhancement. Keep it separate from a direct translation batch so the original and target versions do not drift without approval.
Work the fifth example: a graph inequality
An algebra problem displays a parabola and asks when its value is greater than zero. The original correct answer is a union of intervals outside two roots. A target phrase that says “greater than or equal to zero” includes the two roots. A problem using a strict interval evaluator may reject the added endpoints even though the learner followed the translated instruction accurately.
To validate, identify the roots, choose a point strictly inside a positive interval, choose a point at a root, and choose a point where the graph is negative. Compare how both language versions classify each point. If the question asks for intervals, ensure the translation expresses an interval rather than the roots themselves. Check parentheses and brackets in any displayed interval notation; they are mathematical symbols, not punctuation to be localized creatively.
This example demonstrates the value of boundary tests. A fluent translator might not notice that an equivalent of “at least” has entered the sentence. A bilingual subject expert who explicitly tests equality at a root will catch the difference. The workflow gains speed by using a mathematical counterexample rather than a prolonged debate about the intended nuance of one word.
Work the sixth example: significant figures in measurement
An applied problem asks for a measurement rounded to three significant figures, with the answer checker configured for a particular tolerance or format. A target-language version says “round to three decimal places.” For the quantity 12.3456, the former gives 12.3 while the latter gives 12.346. These are different tasks. Students can follow the new sentence perfectly and still be marked wrong.
A reviewer should compute two contrasting test numbers: one with many digits before the decimal point and another much smaller than one. If both language versions produce the same required formatted result, the precision language is likely aligned. If not, the target should be repaired. This is an especially common problem when the school uses translated mathematics handouts alongside international examination conventions.
Do not promise that a translated phrase automatically changes how WeBWorK treats numerical tolerance or significant figures. The original author may have used a numeric comparer that accepts more forms than the prose suggests. Document the actual checker behaviour and, when necessary, raise a content-owner query. The translation objective is a faithful version of the existing task, not an unapproved correction to the grading policy.
Test the learner journey, not just the file
Source-level comparison is necessary but cannot show the full experience. A good release test renders the target-language problem in the intended WeBWorK installation, checks the statement and math layout, enters correct and incorrect answers, submits them, and inspects feedback and solution behaviour. Include the question’s most error-prone seeds. If the student interface falls back to English, record that limitation rather than claiming the whole course is localized.
Test from a student role when possible. An instructor preview may show additional solutions, diagnostics, or answer information that learners cannot see. A translated instruction that looks clear beside an answer key might be ambiguous without it. Observe whether right-to-left or non-Latin text renders correctly, whether inline mathematics remains in logical order, and whether the answer blank stays associated with the intended sub-question. A working parser is not sufficient if the form’s visual ordering misleads the student.
Finally, inspect a failure case deliberately. Enter a common wrong answer and see whether the response helps the learner understand the issue. If the feedback is not part of the PG file, note its separate owner. This avoids turning a targeted problem-localization article into an inaccurate claim about platform-wide language support.
Accessibility and language direction require careful preview
Mathematical content combines symbols, words, and interactive fields. In languages written right to left, the prose direction may differ from the usual direction of an equation or variable name. A web renderer can display these segments imperfectly if directionality is not handled appropriately. Translators should avoid inserting manual directional controls into executable PG tokens without technical review; that can corrupt the problem or produce inconsistent behaviour across browsers.
Test keyboard navigation between instructions and answer fields, especially when a problem has several blanks. A screen reader may announce the mathematical expression differently depending on the configured renderer and accessibility features. If a localized caption is disconnected from an answer blank, a learner relying on assistive technology may not know what to enter. In that case the translation is not operationally complete for that audience even if the mathematics still grades correctly.
Use the software’s supported markup and accessibility options rather than inventing ad hoc Unicode tricks in source code. Ask a reviewer familiar with the target language and assistive technology to examine a representative item. Document what was tested: browser, problem type, language, display mode, and role. This evidence is stronger than a generic assertion that the file is accessible because its text was translated.
Know what to do when the source problem is itself wrong
Localization often exposes a flaw in the original. Perhaps the source uses “positive” when it means “nonnegative,” or the solution assumes a divisor is not zero without preventing zero in the randomized parameters. The temptation is to repair the mathematics in the translated version and leave the source alone. That creates inconsistent assessments across language groups and makes later maintenance difficult.
The safe process is to log the defect with its seed, expected answer, actual checker behaviour, and the two conflicting statements. The problem owner can then correct the source and coordinate both language versions under an explicit revision. Until that decision, the localized item may need to remain unpublished. Students should not be assigned an unverified version solely because the translator can imagine what the author intended.
Separating defect discovery from unauthorized code change protects accountability. Translators contribute valuable quality evidence but do not silently become exam-setters. A release note can state that a particular item is awaiting source clarification. That is preferable to a language-specific fix that is impossible to reconcile with the shared question bank later.
Build a compact risk-based acceptance matrix
Not every mathematics question needs the same testing effort. A simple addition problem may be validated with a few seeds and a clear grammar review. A complex interval question needs endpoint checks. A probability question needs event-set checks. A multivariable symbolic expression needs order and parser checks. A units problem needs conversion and precision tests. The matrix maps a semantic risk to a specific form of evidence instead of repeating one generic test for every item.
For each problem, record the student task, answer object, randomization range, protected code, critical language conditions, and a handful of chosen test inputs. Reviewers can tick whether the original and target demand the same mathematical result, whether a correct answer is accepted, whether a plausible wrong answer is rejected, and whether the solution remains meaningful. Use a hard stop for differences in answer space or broken evaluation, and a review flag for minor register preferences that do not change mathematics.
This system is efficient because it distinguishes important defects from harmless stylistic variation. The best target-language wording may not follow English sentence order. It is acceptable if it preserves the same action, constraints, and answer expectations. The focus is on mathematical equivalence within the deployed software.
A changed-context exercise: translate a compound inequality
A Secondary 3 algebra problem asks, “Find all real x such that 2 is less than x and x is less than or equal to 7.” The original answer is the interval (2, 7]. A translation says, “Find all real x from 2 through 7 inclusive.” A reviewer proposes keeping it because the sentence is shorter and more natural. Explain whether the translation preserves the answer contract and devise the fastest test.
It does not preserve it. The target phrase includes 2, whereas the original strict lower bound excludes 2. Test x = 2, x = 7, and x = 5. The original rejects 2 but includes 7 and 5. The translated condition includes all three. A correct repair must clearly exclude 2 while retaining 7. The answer evaluator and PGML interval object should remain unchanged under this localization-only job.
Now suppose a different source explicitly asks for all x satisfying 2 ≤ x ≤ 7. In that version an inclusive phrase is correct. The transfer principle is not that inclusive wording is inherently bad; it is that the translation must match the exact mathematical relation in the source. This same approach works for strict probability thresholds, rounding rules, ordered pairs, and function domains.
Transfer to other automated assessments
The method extends to systems beyond WeBWorK. Any assessment that connects a prompt to a machine-readable answer schema has the same vulnerability. A quiz engine may use a numeric tolerance; a programming grader may expect a function signature; a language exercise may depend on exact token positions. Translating the visible question without checking the evaluation contract can produce correct student work that the software rejects.
The reusable method is to define the learner job, protect the machine structure, identify meaning-critical conditions, and test both correct and deliberately wrong responses. For WeBWorK, PGML and MathObjects provide a concrete setting for those checks. Other platforms may have different tokens and evaluators, so their exact implementation details require separate documentation. The structural principle transfers, not the literal source-code syntax.
This matters for teachers who want educational technology to serve students in more than one language. Translating quickly is useful only if assessment remains fair. A bilingual pupil should not face a stricter inequality or different rounding rule merely because a word in the source prompt was rendered incorrectly. Faithful localization protects equal access to the intended mathematics.
A practical review checklist
Preserve a source snapshot and identify the PG macros and exact answer-checking method. Extract only student-visible prose and carefully controlled metadata. Protect variables, PGML directives, mathematical notation, answer blanks, parser contexts, randomization logic, and solution bindings. Check each translated action verb and quantifier against the intended mathematical operation and answer object. When adapting narrative examples, record any assumptions introduced by the new context.
Before approval, compile or render the target problem in the intended WeBWorK environment. Test selected seeds, boundary values, correct responses, common mistakes, and the solution panel. Check units, significant figures, interval endpoint wording, and representation requirements. If the source question was defective, raise a separate content issue rather than silently altering code during localization. Do not report success for a problem that has not been tested in the actual installation.
The final sign-off should identify who verified language, who verified mathematics, and what was tested. A green syntax check is useful but insufficient; a fluent paragraph is useful but insufficient. The translated problem is ready only when the student is asked the same task and the machine treats equivalent mathematical answers equivalently.
Summary: protect the assessment contract
PGML translation works by separating the learner’s reading task from the code that constructs and grades it. Translate the words pupils need to understand, but do not edit random parameter generation, inline PGML tokens, contexts, or evaluators as though they were ordinary language. Check the small logical words that carry inequality, order, precision, and quantity. Then verify representative correct and incorrect answers in the real client.
The aim is not to make an English problem look multilingual on a page. It is to ensure that students working in another language face the same mathematical reasoning challenge, receive the same grading treatment, and can understand the same solution. That is the standard by which a quick translation becomes a dependable educational resource.
Frequently asked questions
Can I translate an entire .pg file through a general machine translator?
That is unsafe without structural protection. PG files mix visible prose with executable macros, variables, answer rules, and mathematical expressions.
What does PGML add to a WeBWorK problem?
PGML supports readable problem statements with inline mathematical markup and answer-rule syntax while the PG program manages parameters and evaluation.
Should variable names like $answer be localized?
Not in a language-only job. They connect displayed text to program state and answer checking.
Why are “at least” and “more than” so important?
They describe different sets: one includes equality and the other excludes it. A mismatch can change the expected answer.
Is one correctly rendered random question enough for QA?
No. Test meaningful parameter boundaries and special cases, including plural forms, zeros, and equality limits when permitted.
May the translator change the accepted answer object to match the new wording?
Not without separate authoring approval. The target wording should preserve the original assessment contract.
How should units be checked?
Compare the displayed unit, target-language instruction, expected numeric representation, and actual evaluator behaviour using a concrete test value.
What about solutions after students submit answers?
Translate solution prose while keeping its mathematical steps, variables, conditions, and conclusions aligned with the source.
Can an English UI still host a translated PGML question?
Possibly, but that is only problem localization. Do not claim that platform menus or shared feedback are localized unless separately verified.
What defect must block publication?
Any changed mathematical task, broken answer checker, misassociated blank, incorrect inequality or precision condition, or unverified random case that can disadvantage learners should block the affected item.
Authoritative sources
- WeBWorK PG authoring references, official sample problems and documentation.
- WeBWorK, Unordered Answers PG sample, showing PGML and unordered evaluators.
- WeBWorK, Interval Evaluator sample, illustrating endpoint-sensitive interval contexts.
- WeBWorK wiki, Web Conference Notes: Problem Authoring, explaining PG file structure and MathObjects.
Suggested internal links
- Vocabulary: What Is an Entailment Test?
- Vocabulary: What Is a Lexical Gap?
- Translate names, numbers, dates and units without changing facts — a complementary factual-identity check.