PICO-8 localization requires more than translating English labels into another language. This complete PICO-8 game translation guide explains how to organize Lua language tables, handle the P8SCII character set, plan custom pixel fonts, measure PRINT layout, respect cartridge constraints and test multilingual releases. The audience is game developers and translators who need readable international editions inside the fantasy console’s deliberately tight boundaries.
The official manual specifies a 128-by-128-pixel display, a limited cartridge format, P8SCII and text-drawing functions rather than unrestricted Unicode document rendering. Its PRINT function can help measure where text ends; its font and control-code capabilities require platform-specific care. Source-level include features and editor shortcuts cannot be assumed to become external runtime translation files after export. Those technical realities should shape the language plan before the words are rewritten.
We will follow a small space game in which a pilot reads oxygen warnings, purchases fuel, accepts a rescue mission and chooses whether to land or abort. The text must preserve the actual danger and cost of each choice while remaining visible beside counters and controller prompts. We will use that scenario to connect source strings with program variables, text placement, character coverage, runtime states, exported cartridges and real player comprehension.
Quick answer: translate a PICO-8 cartridge reliably
- Inventory every player-visible line, control prompt, warning and ending.
- Choose a compact language-table or separate-edition strategy within actual budgets.
- Treat P8SCII codes and program identifiers as protected technical material.
- Confirm target-script glyphs and custom-font behavior with real sentences.
- Measure printed text and preserve critical screen space and reading time.
- Keep fuel, score and game-state arithmetic independent from display language.
- Test every packaged cartridge and browser export from a clean environment.
Contents
- Why constrained displays change translation
- One complete pilot mission example
- Thirty-three technical and editorial decisions
- Troubleshooting real symptoms
- Three publishing approaches
- A four-week localization plan
- FAQs and the official manual
What a translated tiny screen must accomplish
A cockpit alert has at least four responsibilities: it names the hazard, communicates severity, shows what choice is available and gives the pilot time to choose. Translating only the hazard noun leaves the rest of the interaction uncertain. But a complete sentence may collide with the fuel counter on a 128-pixel screen. The right response is neither a dangerously short phrase nor a beautiful sentence that cannot be seen. It is a coordinated design that preserves the decision using appropriate text, font, timing and layout.
Build a reference route in the source language. Start at the title and mission selector, inspect fuel, read the oxygen alert, purchase fuel if needed, approach the rescue target and choose Land or Abort. Record the numeric state and the player consequence before and after each action. The target-language version should communicate the same conditions and lead to equivalent results. A fluent reviewer can judge the wording; a play tester must verify the state changes.
Next, inspect the actual character repertoire. P8SCII supports special glyphs and control features, but a desktop editor’s ability to paste a foreign character does not establish that it renders correctly in a cartridge. Test sample names, punctuation, numbers, low-oxygen warnings and all mission verbs at the intended screen scale. Some writing systems need additional engineering that a simple language table cannot provide. State such limits openly.
Thirty-three PICO-8 translation decisions
1. Understand the fixed display
PICO-8’s documented display is 128 by 128 pixels. Every text line competes with the playfield, controls, counters and moving sprites.
Inventory messages with screen coordinates, available width, expected duration and consequence before translating.
A long warning remains fully readable without hiding the abort button or fuel counter.
Consider this during the space game’s actual rescue approach, with the fuel counter and a decision prompt on the same tiny display. A translated sentence may be technically grammatical and still hide the available action. Review the complete screen with its neighboring graphics and what the player must decide. Keep the visual proof tied to the build and language.
2. Treat P8SCII as a platform constraint
PICO-8 uses its own character encoding and special control codes, not a general guarantee of arbitrary Unicode rendering.
Study the official P8SCII appendix and list the target language’s real characters before selecting text and font architecture.
Full target-language words render in a cartridge rather than being accepted only by a desktop text editor.
The goal is not to mimic the number of English characters. Different languages need different word order, writing conventions and amounts of screen space. Judge each option by whether the player understands the same condition and consequence. If shortening is necessary, protect the hazard, quantity and actionable verb before reducing decorative words.
3. Use PRINT’s measurable output
The official manual describes PRINT drawing text and returning the rightmost x position reached, which is useful for checking layout.
Create a test scene that draws candidate strings and compares measured width with a defined textbox boundary.
Warnings and selection labels fit their allotted coordinates in the actual game.
A developer can diagnose this most accurately by isolating the code and visual layers. Numeric state remains program data, language tables supply text and PRINT draws that text in a chosen position. Confusing those layers creates hard-to-find gameplay bugs. Record the relevant state and output together so a future revision cannot accidentally change the rules.
4. Separate language tables from game rules
Lua-style tables can store different strings for a stable identifier, but the game’s fuel, score and input conditions should remain separate.
Use intent-bearing keys such as fuel.buy.confirm and oxygen.low.warning rather than translating internal state symbols.
Changing English wording does not change the purchase cost, mission result or key bindings.
Use the distributed artifact as the final authority. A development cart may include source files, editor configuration or an untested font that differs from the PNG cartridge or web export. Freeze the relevant source, run the real export and test a clean launch. Retain the precise build identifier with the screenshots.
5. Choose edition packaging carefully
A multiple-language runtime selector adds tables, code, glyphs and menu complexity to a small cartridge.
Compare separate fully tested language carts with a runtime language option; choose according to actual budget and user needs.
The released selection or edition system works for every supported language rather than changing a title alone.
For an important prompt, let a fluent reviewer read it once and predict what will happen before pressing the button. This direct test can reveal an unclear synonym, a weak warning or a misleading control glyph. Then compare the actual event result. If the two differ, repair the words or the code at the appropriate layer.
6. Start with core player actions
The space-game pilot must understand Launch, Abort, Buy Fuel and Land before any decorative story copy matters.
Prioritize messages tied to controls, costs, hazards, mission completion and recovery, then translate lower-impact commentary.
A first-time player makes the correct high-stakes choice without English.
Do not treat an unsupported language as completed merely because a few glyphs can be drawn. Readability includes full words, punctuation, numbers, direction and normal play speed. Test the longest required sentence and representative failure messages. When constraints cannot be met responsibly, choose a different release design and explain its limitations.
7. Never parse a translated amount as game logic
The fuel count may be shown with words and separators appropriate to a language, but the underlying state is numeric.
Keep arithmetic and conditions in numeric variables and format text only when drawing the display.
Fuel and score values remain unchanged by language choice.
Consider this during the space game’s actual rescue approach, with the fuel counter and a decision prompt on the same tiny display. A translated sentence may be technically grammatical and still hide the available action. Review the complete screen with its neighboring graphics and what the player must decide. Keep the visual proof tied to the build and language.
8. Avoid English fragment concatenation
A label formed from You have plus a number plus fuel units assumes English word order and a simple plural rule.
Store whole message patterns or language-specific variants, then insert actual numeric values through a documented formatter.
Zero, one, two and maximum fuel values are grammatical in each language.
The goal is not to mimic the number of English characters. Different languages need different word order, writing conventions and amounts of screen space. Judge each option by whether the player understands the same condition and consequence. If shortening is necessary, protect the hazard, quantity and actionable verb before reducing decorative words.
9. Budget the available glyphs
A game using custom letterforms may not have enough glyph slots for a writing system that demands many distinct characters.
Build a corpus of real warning text, names, punctuation and numbers, then determine which characters and font method are feasible.
A fluent reader checks all planned words before the project promises a locale.
A developer can diagnose this most accurately by isolating the code and visual layers. Numeric state remains program data, language tables supply text and PRINT draws that text in a chosen position. Confusing those layers creates hard-to-find gameplay bugs. Record the relevant state and output together so a future revision cannot accidentally change the rules.
10. Inspect custom-font support
The manual describes custom font facilities and attributes, but they have layout and memory constraints that must be tested.
Measure the cost and behavior of any selected custom glyphs, keeping source and export versions together.
The same phrase appears correctly in the editor, exported binary and hosted web package.
Use the distributed artifact as the final authority. A development cart may include source files, editor configuration or an untested font that differs from the PNG cartridge or web export. Freeze the relevant source, run the real export and test a clean launch. Retain the precise build identifier with the screenshots.
11. Protect control codes
Some P8SCII codes change how the printed text appears; treating them as ordinary punctuation can break a translated line.
Identify protected control characters and keep a technical token reference for translators.
A localized warning changes line or font behavior only as intended.
For an important prompt, let a fluent reviewer read it once and predict what will happen before pressing the button. This direct test can reveal an unclear synonym, a weak warning or a misleading control glyph. Then compare the actual event result. If the two differ, repair the words or the code at the appropriate layer.
12. Review punctuation deliberately
A punctuation mark may not belong to the available P8SCII repertoire or custom font, yet it can distinguish a warning from a question.
Select a supported equivalent with fluent review and preserve the question, negation or urgency of the source.
A target-language player can still recognize which message asks for confirmation.
Do not treat an unsupported language as completed merely because a few glyphs can be drawn. Readability includes full words, punctuation, numbers, direction and normal play speed. Test the longest required sentence and representative failure messages. When constraints cannot be met responsibly, choose a different release design and explain its limitations.
13. Handle proper names consistently
A pilot or ship name may recur in the title, cockpit, status screen and ending.
Use a small glossary with approved target spellings and map those characters into the available font.
The same person or vessel is recognized everywhere without missing glyphs.
Consider this during the space game’s actual rescue approach, with the fuel counter and a decision prompt on the same tiny display. A translated sentence may be technically grammatical and still hide the available action. Review the complete screen with its neighboring graphics and what the player must decide. Keep the visual proof tied to the build and language.
14. Measure longer translations at full scale
A phrase that looks compact in a desktop editor may cover a score counter when drawn at the normal cartridge resolution.
Place the target sentence in the exact screen region with real neighboring graphics; change layout before deleting essential words.
The fuel status and warning can be read simultaneously.
The goal is not to mimic the number of English characters. Different languages need different word order, writing conventions and amounts of screen space. Judge each option by whether the player understands the same condition and consequence. If shortening is necessary, protect the hazard, quantity and actionable verb before reducing decorative words.
15. Plan multi-line messages
A single line may be too short for an accurate safety sentence. Splitting it carelessly can make a conditional instruction ambiguous.
Use tested line breaks and a clear continuation cue where needed, preserving condition, consequence and player action.
The pilot reads all parts in order before making an irreversible decision.
A developer can diagnose this most accurately by isolating the code and visual layers. Numeric state remains program data, language tables supply text and PRINT draws that text in a chosen position. Confusing those layers creates hard-to-find gameplay bugs. Record the relevant state and output together so a future revision cannot accidentally change the rules.
16. Keep timing aligned with language
A fast alert may disappear before a translated message can be read even if its words are correct.
Allow adequate display time or user-controlled continuation for high-consequence messages without breaking play mechanics.
A new reader can explain the low-oxygen warning at normal game speed.
Use the distributed artifact as the final authority. A development cart may include source files, editor configuration or an untested font that differs from the PNG cartridge or web export. Freeze the relevant source, run the real export and test a clean launch. Retain the precise build identifier with the screenshots.
17. Treat color as supplemental information
With a limited palette, the designer may signal danger solely by red text that not every player can distinguish reliably.
Pair color with an understandable warning word or icon and check contrast against moving backgrounds.
The player identifies the danger without using hue as the only clue.
For an important prompt, let a fluent reviewer read it once and predict what will happen before pressing the button. This direct test can reveal an unclear synonym, a weak warning or a misleading control glyph. Then compare the actual event result. If the two differ, repair the words or the code at the appropriate layer.
18. Preserve the meaning of Abort
Abort is an irreversible mission decision in this space game, not merely a pause or temporary hiding of a window.
Explain the precise result in translator context and use a term that conveys the intended consequence.
A player predicts that selecting Abort ends the attempt rather than simply freezing the game.
Do not treat an unsupported language as completed merely because a few glyphs can be drawn. Readability includes full words, punctuation, numbers, direction and normal play speed. Test the longest required sentence and representative failure messages. When constraints cannot be met responsibly, choose a different release design and explain its limitations.
19. Clarify the meaning of Burn
In a spaceflight context a burn can refer to a propulsion maneuver, not an uncontrolled fire.
Keep a terminology note explaining the actual game mechanics and avoid misleading literal translations.
The player understands which control uses fuel to alter the vehicle’s path.
Consider this during the space game’s actual rescue approach, with the fuel counter and a decision prompt on the same tiny display. A translated sentence may be technically grammatical and still hide the available action. Review the complete screen with its neighboring graphics and what the player must decide. Keep the visual proof tied to the build and language.
20. Distinguish title and mission text
A creative game title has different naming needs from cockpit warnings that must be immediately operational.
Allow editorial adaptation in title copy while protecting technical and consequential language from unexplained changes.
A good title still identifies the game, and an abort prompt still tells the truth.
The goal is not to mimic the number of English characters. Different languages need different word order, writing conventions and amounts of screen space. Judge each option by whether the player understands the same condition and consequence. If shortening is necessary, protect the hazard, quantity and actionable verb before reducing decorative words.
21. Respect cartridge code budgets
The manual specifies an 8192-token code limit and separate limits for some saved or exported cartridge formats.
Track token and compressed-size changes when adding dictionaries, switch logic and font code; prioritize functional text rather than decorative duplication.
The final cart satisfies the intended format’s actual limits and builds successfully.
A developer can diagnose this most accurately by isolating the code and visual layers. Numeric state remains program data, language tables supply text and PRINT draws that text in a chosen position. Confusing those layers creates hard-to-find gameplay bugs. Record the relevant state and output together so a future revision cannot accidentally change the rules.
22. Use INFO and export checks
The official documentation describes tools to inspect cartridge size and constraints, including INFO for code usage.
Run documented size checks before final approval and test the exact distribution file rather than a less constrained development source.
A cart that runs in development actually saves and exports to its promised format.
Use the distributed artifact as the final authority. A development cart may include source files, editor configuration or an untested font that differs from the PNG cartridge or web export. Freeze the relevant source, run the real export and test a clean launch. Retain the precise build identifier with the screenshots.
23. Understand include flattening
The manual explains source-level #include behavior and that certain exported formats flatten included files into the cartridge.
Do not assume a separate development language file can be swapped dynamically after exporting a cartridge.
The released cart contains the intended approved translation without an external source dependency.
For an important prompt, let a fluent reviewer read it once and predict what will happen before pressing the button. This direct test can reveal an unclear synonym, a weak warning or a misleading control glyph. Then compare the actual event result. If the two differ, repair the words or the code at the appropriate layer.
24. Avoid editing program delimiters
A translator who edits full Lua source may accidentally remove quotation marks, code separators or escape characters.
Exchange clearly delimited translatable values and validate syntax after integrating new text.
The translated game still runs, and buttons, score and route states work.
Do not treat an unsupported language as completed merely because a few glyphs can be drawn. Readability includes full words, punctuation, numbers, direction and normal play speed. Test the longest required sentence and representative failure messages. When constraints cannot be met responsibly, choose a different release design and explain its limitations.
25. Give translators context
An isolated string Burn or Return can have several meanings; only the spacecraft state tells a translator which is intended.
Show an in-game screenshot, player action, danger level and expected consequence for each meaningful key.
A fluent reader explains the instruction before seeing its English original.
Consider this during the space game’s actual rescue approach, with the fuel counter and a decision prompt on the same tiny display. A translated sentence may be technically grammatical and still hide the available action. Review the complete screen with its neighboring graphics and what the player must decide. Keep the visual proof tied to the build and language.
26. Test custom input glyphs
The official editor supports special controller-button characters and related display codes, which may be mishandled by external editors.
Keep input glyphs technically valid and use them consistently across every menu and language edition.
A controller-only player sees the correct prompt and can act accordingly.
The goal is not to mimic the number of English characters. Different languages need different word order, writing conventions and amounts of screen space. Judge each option by whether the player understands the same condition and consequence. If shortening is necessary, protect the hazard, quantity and actionable verb before reducing decorative words.
27. Review tutorial and host-page instructions
A player can receive a translated game but still face an English-only download page and control guide.
Provide language-specific or clearly navigable instructions, edition names and accessibility notes beyond the cartridge.
A visitor finds the right download and learns controls without translating the host page.
A developer can diagnose this most accurately by isolating the code and visual layers. Numeric state remains program data, language tables supply text and PRINT draws that text in a chosen position. Confusing those layers creates hard-to-find gameplay bugs. Record the relevant state and output together so a future revision cannot accidentally change the rules.
28. Test browser export separately
Web deployment introduces browser focus, input, audio and screen scaling differences from the creator’s editor.
Open the built HTML/JavaScript package in a clean browser and on appropriate mobile devices where input support is intended.
Every gameplay choice and translated instruction works in the actual public environment.
Use the distributed artifact as the final authority. A development cart may include source files, editor configuration or an untested font that differs from the PNG cartridge or web export. Freeze the relevant source, run the real export and test a clean launch. Retain the precise build identifier with the screenshots.
29. Check fonts under real scaling
The tiny pixel display can appear different when stretched on a large monitor or compressed on a phone.
Assess character shapes, contrast and readability at the viewing sizes the audience will use.
Unusual glyphs, counters and warnings remain distinct at ordinary scale.
For an important prompt, let a fluent reviewer read it once and predict what will happen before pressing the button. This direct test can reveal an unclear synonym, a weak warning or a misleading control glyph. Then compare the actual event result. If the two differ, repair the words or the code at the appropriate layer.
30. Treat complex scripts honestly
P8SCII and custom fonts do not establish complete Unicode shaping or bidirectional typography for all world languages.
Treat unsupported script features as an engineering limitation requiring extra renderer work or a different edition approach.
A script is announced as supported only after fluent review of full real sentences.
Do not treat an unsupported language as completed merely because a few glyphs can be drawn. Readability includes full words, punctuation, numbers, direction and normal play speed. Test the longest required sentence and representative failure messages. When constraints cannot be met responsibly, choose a different release design and explain its limitations.
31. Make missing-key fallback deliberate
An absent language-table key can display nil, a raw identifier or an empty message if the project does not handle it safely.
Specify a fallback and a development-only coverage report, especially for high-consequence alerts.
Removing a harmless key in testing reveals a predictable response rather than a broken screen.
Consider this during the space game’s actual rescue approach, with the fuel counter and a decision prompt on the same tiny display. A translated sentence may be technically grammatical and still hide the available action. Review the complete screen with its neighboring graphics and what the player must decide. Keep the visual proof tied to the build and language.
32. Verify all alternate mission states
Successful landing alone does not cover fuel shortage, unsafe oxygen, refusal, death or score screens.
Build a route matrix that triggers all critical messages with known starting state and expected outcome.
Every visible branch is understood and tested in each released locale.
The goal is not to mimic the number of English characters. Different languages need different word order, writing conventions and amounts of screen space. Judge each option by whether the player understands the same condition and consequence. If shortening is necessary, protect the hazard, quantity and actionable verb before reducing decorative words.
33. Keep reproducible build manifests
A screenshot may show a corrected translation while the uploaded PNG cartridge or browser build is still old.
Record locale, source and language-table revision, font set, format, package identifier and tested route.
A player report can be tied to the exact released edition and reversed if necessary.
A developer can diagnose this most accurately by isolating the code and visual layers. Numeric state remains program data, language tables supply text and PRINT draws that text in a chosen position. Confusing those layers creates hard-to-find gameplay bugs. Record the relevant state and output together so a future revision cannot accidentally change the rules.
Troubleshooting by the visible failure
Translation defects in a tiny cartridge often look alike to a player. A wrong glyph can be mistaken for a spelling error, a clipped instruction for a missing translation, and an incorrect fuel deduction for a mistranslated price. Begin with the actual scene, state, language, output and release format. The following cases identify the likely boundary and a concrete way to verify repair.
1. A pasted accented letter becomes a symbol
What may be happening: The character is not represented by the expected P8SCII code or custom-font glyph.
Repair: Inspect actual encoding and font coverage rather than silently removing important letters.
Check: Read the entire affected word in the exported cart.
Reproduce the defect with a clean cartridge state before modifying a phrase. Compare the same screen in the source-language edition, including the neighboring counter and button. The aim is to tell the difference between a display error and a game-state error.
2. A warning covers the fuel counter
What may be happening: PRINT draws a longer translated string beyond its allocated region.
Repair: Measure the actual output width and redesign the message region or approved wording.
Check: Trigger the warning with changing fuel values on screen.
After the correction, measure the output at real 128-pixel resolution and inspect the actual exported format. A preview at a larger desktop scale can make an overlap or unclear character easy to miss.
3. A control glyph turns into punctuation
What may be happening: A special button character or text control code was changed in an external editor.
Repair: Restore its documented representation and protect the token in the translation sheet.
Check: Run every menu using a controller alone.
Use a fluent target-language reader for consequential messages. Ask them what action the game permits and what the cost might be before they act. Record their interpretation alongside the actual result, not merely a pass mark.
4. The cartridge exceeds its size budget
What may be happening: Additional language tables, fonts and runtime switching increased token or compressed size beyond the chosen format limit.
Repair: Inspect documented INFO and export constraints, then simplify architecture without hiding critical warnings.
Check: Export and run the actual final file.
Keep the corrected condition as a regression scenario with source revision, selected locale, action and expected screen. A new translation table or font adjustment can then be tested against a known risk rather than reviewed only for appearance.
5. An include file is missing after export
What may be happening: The author assumed source-level #include files remain runtime external resources.
Repair: Review flattening and package behavior in the manual and rebuild for the target format.
Check: Run the exported cart without the development source directory.
Reproduce the defect with a clean cartridge state before modifying a phrase. Compare the same screen in the source-language edition, including the neighboring counter and button. The aim is to tell the difference between a display error and a game-state error.
6. Buy Fuel changes the wrong amount
What may be happening: The game reads a localized label rather than using the numeric price state.
Repair: Keep price computation separate and show translated text only in the UI.
Check: Compare balances before and after purchases in two languages.
After the correction, measure the output at real 128-pixel resolution and inspect the actual exported format. A preview at a larger desktop scale can make an overlap or unclear character easy to miss.
7. A translated warning disappears too fast
What may be happening: The text is longer but its display duration remained tuned for the English original.
Repair: Increase readability with explicit continuation or sufficient duration, respecting game action timing.
Check: A first-time reader can explain the warning before choosing a response.
Use a fluent target-language reader for consequential messages. Ask them what action the game permits and what the cost might be before they act. Record their interpretation alongside the actual result, not merely a pass mark.
8. A question mark is missing
What may be happening: The target punctuation is unavailable in the selected font or was dropped when shortening text.
Repair: Provide a supported glyph or linguistically acceptable equivalent without changing interrogative meaning.
Check: A native reader recognizes the confirmation prompt.
Keep the corrected condition as a regression scenario with source revision, selected locale, action and expected screen. A new translation table or font adjustment can then be tested against a known risk rather than reviewed only for appearance.
9. A Lua string is syntactically invalid
What may be happening: Translated quotation marks or backslashes broke the source literal when pasted into code.
Repair: Use a controlled string-replacement process and validate the cart after integration.
Check: The complete translated game runs and reaches the affected message.
Reproduce the defect with a clean cartridge state before modifying a phrase. Compare the same screen in the source-language edition, including the neighboring counter and button. The aim is to tell the difference between a display error and a game-state error.
10. Only the opening menu is localized
What may be happening: HUD, hazard alerts, pause, failure and ending text were never inventoried.
Repair: Audit every player-visible state and add missed keys before release.
Check: Finish and fail the mission entirely in the target language.
After the correction, measure the output at real 128-pixel resolution and inspect the actual exported format. A preview at a larger desktop scale can make an overlap or unclear character easy to miss.
11. Web export and local cart disagree
What may be happening: The developer built the two distribution targets from different revisions or font configurations.
Repair: Freeze resources and regenerate both builds, tracking exact release identities.
Check: Compare all critical screens from clean launches.
Use a fluent target-language reader for consequential messages. Ask them what action the game permits and what the cost might be before they act. Record their interpretation alongside the actual result, not merely a pass mark.
12. Abort is interpreted as Pause
What may be happening: The chosen target word softened the irreversible consequence into a temporary interruption.
Repair: Translate with the game outcome visible and recheck the player’s expectation.
Check: A first-time reader predicts a mission termination before selecting it.
Keep the corrected condition as a regression scenario with source revision, selected locale, action and expected screen. A new translation table or font adjustment can then be tested against a known risk rather than reviewed only for appearance.
Three complete publication journeys
A solo creator building a second-language edition
A developer chooses to ship a separate Spanish cartridge rather than fit multiple language tables into one first version. They inventory mission warnings, controls, fuel and ending labels, and test the target glyphs with a compact display cart before translating the full story. They keep game-state variables numeric and protect P8SCII commands in the language material. They play through low-oxygen warnings, purchases, aborts and landings in a clean exported cartridge. The public download is labeled with its language and build revision; a later runtime selector can be considered only if there is enough technical and testing capacity.
The acceptance test remains practical: from a fresh start, an unfamiliar player can understand the oxygen hazard, buy the correct amount of fuel, choose a safe maneuver and explain why the mission succeeds or ends. A written translation can contribute to that outcome, but only a functioning, legible artifact demonstrates it.
A translator and Lua programmer working together
The programmer provides stable string keys, exact screens and notes about what the pilot must do. The translator can revise a warning without editing mission logic or code delimiters and can ask for extra screen space when no accurate short wording exists. The programmer integrates language-table values, measures PRINT output and validates size limits. A fluent reviewer checks urgency and interpretation; a tester checks the fuel cost and mission outcome. Differences are resolved against an executable scenario rather than a dictionary alone.
The acceptance test remains practical: from a fresh start, an unfamiliar player can understand the oxygen hazard, buy the correct amount of fuel, choose a safe maneuver and explain why the mission succeeds or ends. A written translation can contribute to that outcome, but only a functioning, legible artifact demonstrates it.
A publisher releasing cartridges and browser editions
A publishing team freezes project and translated-table revisions and tests both the cartridge and the hosted web export. Its manifest records the P8SCII character approach, custom-font revisions, code-size measurements, target input methods and all high-consequence routes. The public page identifies the intended language and controller instructions, and screenshots correspond to the actual version available. If a rendering defect is reported, the team can reproduce it and restore the previous tested file instead of improvising a fix in production.
The acceptance test remains practical: from a fresh start, an unfamiliar player can understand the oxygen hazard, buy the correct amount of fuel, choose a safe maneuver and explain why the mission succeeds or ends. A written translation can contribute to that outcome, but only a functioning, legible artifact demonstrates it.
Four-week implementation roadmap
Week 1: inspect constraints and source copy
Map every title, HUD label, warning, tutorial, menu, ending and host-page instruction. Record where each appears in the 128-by-128 display and which control it accompanies. Inspect P8SCII and the intended font repertoire, and choose separate editions or a runtime model based on real budget. Freeze the source state for the first translation pass.
Do not equate a completed calendar milestone with tested language support. Record the exact cartridge, locale, game state, observed text and outcome for every high-consequence route. A reader should be able to repeat the check without the developer’s machine or untranslated notes.
Week 2: localize one complete pilot journey
Translate mission selection, oxygen warning, fuel purchase, landing or abort and final result. Keep arithmetic and input logic intact. Create a test cart that measures and displays the longest phrases with the actual font and any control symbols. Ask a fluent reader to interpret warnings and costs before acting. Fix meaning, line breaks and timing together.
Do not equate a completed calendar milestone with tested language support. Record the exact cartridge, locale, game state, observed text and outcome for every high-consequence route. A reader should be able to repeat the check without the developer’s machine or untranslated notes.
Week 3: cover edge states and export targets
Trigger insufficient fuel, unsafe oxygen, refusal, failure and all endings. Test extreme numeric values, uncommon glyphs, punctuation and mixed text where relevant. Inspect token and format size constraints, then export the chosen cartridge and web formats. Run both independently and check input, scaling and readable text.
Do not equate a completed calendar milestone with tested language support. Record the exact cartridge, locale, game state, observed text and outcome for every high-consequence route. A reader should be able to repeat the check without the developer’s machine or untranslated notes.
Week 4: freeze and publish a verified edition
Freeze the approved language tables, custom-font files and source revision. Run final INFO and export checks appropriate to the release format, then test exact distributed artifacts in clean environments. Check language labels, control instructions, credits and known limitations on the publication page. Keep a last-good package and the test evidence for repair or rollback.
Do not equate a completed calendar milestone with tested language support. Record the exact cartridge, locale, game state, observed text and outcome for every high-consequence route. A reader should be able to repeat the check without the developer’s machine or untranslated notes.
Frequently asked questions
Can PICO-8 show any Unicode string?
No. Its documented character system is P8SCII with specific built-in and custom-font features. Real target-language characters need explicit support.
Check the actual version of the official PICO-8 manual and test the targeted export format. The right answer depends on glyph coverage, language design, code resources and the player experience; avoid promising general Unicode or runtime language switching from an isolated example.
How do I measure text width?
The manual describes the PRINT function’s return value as the rightmost x position printed. Test with real target strings and selected font settings.
Check the actual version of the official PICO-8 manual and test the targeted export format. The right answer depends on glyph coverage, language design, code resources and the player experience; avoid promising general Unicode or runtime language switching from an isolated example.
Is a separate language cart acceptable?
Yes, when clearly labeled and completely tested. A custom runtime selector is useful only if its code, font and packaging fit the game.
Check the actual version of the official PICO-8 manual and test the targeted export format. The right answer depends on glyph coverage, language design, code resources and the player experience; avoid promising general Unicode or runtime language switching from an isolated example.
Does #include create runtime language files?
The manual describes source composition and flattening into certain export formats. Do not assume dynamic external files survive exports.
Check the actual version of the official PICO-8 manual and test the targeted export format. The right answer depends on glyph coverage, language design, code resources and the player experience; avoid promising general Unicode or runtime language switching from an isolated example.
What if language tables exceed the code limit?
Inspect the format-specific code and compressed-size budgets and consider separate editions or a smaller architecture, while preserving critical instructions.
Check the actual version of the official PICO-8 manual and test the targeted export format. The right answer depends on glyph coverage, language design, code resources and the player experience; avoid promising general Unicode or runtime language switching from an isolated example.
Can I support Arabic and Hebrew automatically?
Do not assume complete shaping or bidirectional text from P8SCII. Test full sentences with a suitable renderer and fluent reviewers before promising support.
Check the actual version of the official PICO-8 manual and test the targeted export format. The right answer depends on glyph coverage, language design, code resources and the player experience; avoid promising general Unicode or runtime language switching from an isolated example.
What makes a warning translation good?
Its words must preserve severity, condition and consequence; the actual game must display it long enough and in a readable location.
Check the actual version of the official PICO-8 manual and test the targeted export format. The right answer depends on glyph coverage, language design, code resources and the player experience; avoid promising general Unicode or runtime language switching from an isolated example.
Should browser builds be tested separately?
Yes. Input, focus, scaling and resource packaging may differ from local development. Test the actual public artifact.
Check the actual version of the official PICO-8 manual and test the targeted export format. The right answer depends on glyph coverage, language design, code resources and the player experience; avoid promising general Unicode or runtime language switching from an isolated example.
Official documentation
For broad principles of preserving meaning, see Master Art of Translation. Find additional platform-specific implementation guides in the Translate Like a Pro series index. This guide addresses PICO-8’s specific glyph, Lua, screen and cartridge constraints, rather than generic methods for translating quickly.
Final principle: tiny displays still owe players clear decisions
A localized PICO-8 cart succeeds when the pilot knows whether oxygen is low, what buying fuel costs and what Abort actually does, all while the text remains readable beside the controls. That requires attention to meaning, grammar, character encoding, measured pixels, timing, code budgets and packaged results. The best international edition is not the one with the most translated fragments. It is the one an unfamiliar reader can actually play and trust.