Keyman Developer is a toolkit for building Unicode keyboards for languages that are difficult to type with a standard input layout. If you are searching for a Keyman Developer tutorial, custom keyboard layout development, Keyman context rules, dead keys, touch keyboard design or multilingual typing quality assurance, begin with the text people actually need to write. The reliable outcome is not a clever keyboard diagram: it is valid, searchable, editable Unicode text that writers can enter confidently on their devices.
Creating a language keyboard requires several connected decisions. The orthography defines the writing system; Unicode defines text identity; keyboard rules map user actions to that text; fonts and shaping engines make it readable; and people decide whether the layout feels natural. Keyman Developer provides project, compilation and testing tools, including the kmc command-line compiler. However, an installation that succeeds technically can still fail in everyday writing through awkward accent sequences, unexpected contextual replacement or poor mobile ergonomics.
This practical guide explains how to design, build, test, document and maintain a Keyman keyboard for translators, literacy teams, dictionary editors, researchers and community writers worldwide. It distinguishes keyboard engineering from font design and text-encoding migration, offers realistic failure cases, and shows what evidence to collect before distributing a layout. Follow the version-specific Keyman documentation for exact compiler options and platform capabilities; do not treat examples as a substitute for testing the actual application.
- Identify the real language-writing workflow and the users’ devices before assigning keys.
- Map each action to intended Unicode characters and preserve orthography decisions.
- Test context rules, dead-key recovery, combining sequences and punctuation in real applications.
- Review desktop and mobile layouts independently with representative writers.
- Separate keyboard output, font rendering and language correctness during QA.
- Version source, packages, instructions and regression tests together.
- Publish only with an accountable maintenance and feedback process.
What a dependable language keyboard should accomplish
The practical target is simple: a person can compose a message, correction, translation or dictionary entry without silently creating ambiguous text. They can see what they typed, delete mistakes, switch languages and paste a paragraph into another tool without losing character identity. That means design decisions must be judged by actual writing tasks rather than an attractive chart of symbols. A keyboard exists inside a workflow of people, hardware, software, teaching materials and archives.
1. Begin with the language, not the keyboard graphic
A keyboard layout is a practical agreement about how people enter text, not a picture of an alphabet. Identify the language, orthography, target users, writing direction, punctuation and devices before choosing key positions. Ask speakers to type ordinary messages and observe where they pause.
Collect fifty representative words, ten full sentences, names, borrowed words and punctuation examples. Mark which characters have dedicated keys, which require sequences, and which are only found in specialist texts. Decide whether an existing input method already solves the problem before starting a new project.
Compare the proposed typing system with real community expectations. If writers already use a well-known keyboard, a new mapping that rearranges common letters can create substantial learning costs. Obtain permission to share test data and record what users found inconvenient, not merely what the designer intended.
Build a baseline sample pack of greetings, family names, numbers and loanwords from the speakers who will use this keyboard. Record the original spelling decisions and the device on which each sample was entered. This is the reference against which layout proposals should be judged, rather than a character chart assembled from memory.
2. Separate characters, glyphs and key labels
One Unicode character is not necessarily one visible mark, and one visible syllable can use several code points. A keyboard decides what text to emit. A font decides how that text appears. Confusing these responsibilities causes incompatible documents when a design looks correct on one machine but fails elsewhere.
For each key action, write the intended Unicode sequence and a human-readable description. Check code points with a character inspector rather than guessing from appearance. Make keycaps understandable but do not treat an attractive touch layout as proof that the underlying text is right.
Test the emitted sequence in a plain text editor, a browser form, and a document application with different fonts. Copy the text between applications. If the appearance changes while code points stay correct, investigate font or shaping support; if the code points change, investigate input rules.
Create a two-column inventory showing the intended Unicode sequence and its visible appearance for every nontrivial key. Include marks that look alike but have different code points. Test pasting those sequences into an unformatted text editor, since visual resemblance in one font cannot establish that the keyboard supplied correct characters.
3. Choose the keyboard project format deliberately
Keyman Developer supports keyboard projects and can compile keyboard source into deployable files. A .kmn source file and a compiled keyboard are different artifacts; a package adds installation and supporting resources. The project must have a predictable build path and a record of what was released.
Keep source, documentation, sample text, test cases and release notes in a version-controlled project. Use descriptive file names and store the intended language tag as project metadata where supported. Check the installed Keyman Developer version and relevant help pages before relying on a specific editor feature.
Create a clean build from source on another machine. If only the author’s laptop can produce the keyboard, the community does not yet have a maintainable artifact. Archive the source and the compiled outputs together, identifying which one users should install.
Ask a second maintainer to rebuild the .kmn or project files after checking out the archived source. Record the Keyman compiler version and the output artifacts, then install the package in a clean account. A rebuild that depends on undocumented files or an author’s private fonts fails the maintenance test.
4. Understand context-sensitive rules
Many alphabets require more than one-to-one substitutions. In Keyman keyboard rules, context and a keystroke can determine output. Such rules are useful for sequences that add marks or transform a previous input, but they can also accidentally consume unrelated text.
Write down a rule as a readable sentence: when a particular preceding sequence exists and the user presses a particular key, replace or extend the text in a specified way. Keep the simplest possible contexts and add longer contexts only when actual orthographic cases require them.
Test the same sequence at the beginning of a line, after a space, inside a word and after punctuation. Verify Backspace and correction behavior. A rule that works only in a demonstration word may become destructive during normal typing.
Type contextual-rule examples after punctuation, after a space and in the middle of a longer sentence. Then move the caret and repeat the same sequence. Preserve expected and actual text as code points, not just screenshots; a rule that is safe at the end of a word may delete unintended context elsewhere.
5. Treat dead keys as a usability decision
A dead key may wait for the next key before producing a character or mark. This can be efficient for diacritics that appear across many letters, but the user must know what state the keyboard is in. Invisible state often feels like a broken key.
Design a clear convention for mark-first and base-first input. Document whether pressing a combining mark alone generates nothing, a spacing mark, or a sequence; test multi-mark vowels and any prescribed ordering. Avoid making rare marks harder to enter than ordinary punctuation without a reason.
Ask testers to repair mistakes by deleting and retyping. Look for cases where a dead-key sequence creates an unexpected character at word boundaries. Provide memorable examples in the user guide and put the most frequent input operations within comfortable reach.
Document how users recover from an unfinished dead-key sequence. Have a new tester type the accent alone, press Backspace, enter an unrelated letter and repeat with two consecutive accents. The preferred behavior is whatever the community has agreed is predictable, not whatever a demonstration happens to produce.
6. Keep normalization and combining marks visible to reviewers
Unicode can represent some text in more than one canonically equivalent sequence. Combining mark order and normalization can affect searching, database comparisons and text processing even when strings look similar. Do not silently rewrite all source text in the name of tidiness.
Establish a normalization policy based on the language and receiving systems. Capture samples as hexadecimal code points and normalize only as a documented stage of the pipeline. Distinguish canonical equivalence from spelling or orthography changes; they are not interchangeable.
Compare search, copy-and-paste, sorting and round-trip storage for representative strings. Test cases with multiple combining marks, leading combining marks and copied legacy text. A correct keyboard is one piece of a larger Unicode data quality system.
Compare canonically equivalent text samples with an inspector and a search operation. Explain whether the project’s preferred representation is normalized when entered or only when imported. Retain test cases containing multiple marks so future contributors do not confuse normalization with correcting an orthographic variant.
7. Design touch layouts for actual fingers
Mobile typing is not a reduced desktop keyboard. Touch keys have dimensions, reach and long-press behavior that shape whether learners can use the language comfortably. A symbol reachable through several layers may be mathematically available but practically inaccessible.
Make a touch layout plan based on frequent characters and realistic phone sizes. Test portrait and landscape, long words, left- and right-handed use, visual contrast and accessibility labels. Choose popups only where they clarify related variants instead of hiding the main alphabet.
Ask participants to type a shopping list, a family message and a short paragraph. Observe errors per sentence and time to recover from them. If a touch layout is visually attractive but pushes frequent diacritics three actions away, redesign it before distributing widely.
Run a timed mobile task on a small screen: enter ten common words, make three corrections and write a mixed-language message. Track accidental popups, missed letters and the number of actions required for the frequent marks. Ask users to suggest positions before finalizing the touch layout.
8. Do not confuse lexical prediction with keyboard correctness
A lexical model may offer suggestions or predictions, but a keyboard still needs to produce valid text without them. Prediction errors can reinforce unpopular spellings and may introduce privacy or language-standardization concerns if training material was not authorized.
Begin with deterministic key behavior and baseline spelling tests. Add a predictive feature only when there is an appropriate corpus, a clear review process and community agreement about the variants it may suggest. Treat person names, dialects and new words as legitimate text.
Evaluate suggestion quality separately from input fidelity. Turn predictions off and repeat typing tests. If the core keyboard cannot express every approved word without the model, the input method is incomplete.
Turn off predictions and type uncommon names, new loanwords and ordinary inflections. If an accepted word cannot be entered without choosing a suggestion, the keyboard rules need improvement. Test the prediction feature separately using authorized language data, and report unwanted correction of dialectal spellings.
9. Test platforms without assuming identical behavior
Desktop applications, web editors and mobile apps do not share one text-entry implementation. The same keyboard may behave differently when an application handles composition, selection, shortcuts or embedded forms in unusual ways.
Build a test matrix with operating system, input application, font, language sample and keyboard build number. Include browsers, messaging tools, document editors and offline environments relevant to users. Record whether faults affect output codes or only the displayed font.
Test selected text replacement, mid-word insertion, undo, Backspace, keyboard switching and paste. Report the smallest reproducible keystroke sequence rather than saying the keyboard sometimes fails. Each reproducible bug should become a future regression test.
Create a reproducible platform matrix containing keyboard build, operating system, app, font and input sequence. Include selection replacement and mid-word insertion. A problem report should say whether the underlying Unicode string changed or whether only rendering did, which helps distinguish the keyboard from a host-app defect.
10. Use Keyman build tools with version awareness
The official Keyman command-line toolset includes kmc, with build capabilities for keyboard and package sources. Commands and supported file types evolve across releases; follow the documentation matched to the installed version, and never rely on an unverified legacy command.
For a basic project, inspect the current command help and use commands such as kmc build on supported project or source files. Capture the tool version in the release notes. Automating compilation is valuable only when the input project, fonts and test expectations are also controlled.
Review build warnings as possible editorial defects. A successful compiler exit says the artifacts were produced, not that every orthographic case works. Keep human typing tests and code-point assertions alongside automated builds.
Run the documented kmc help command before packaging and capture the compiler version used. Build from a clean workspace, preserve warnings, and identify the exact package distributed to the testers. Follow with keyboard behavior tests; successful compilation is not a substitute for valid words and comfortable corrections.
11. Document the everyday typing contract
A keyboard guide should explain the few decisions users need to make while writing: how to enter accented letters, how to type borrowed words, which keys produce punctuation, and what happens after a mistake. A long technical specification does not replace a short usage guide.
Prepare a one-page cheat sheet with familiar words, physical and touch key illustrations where helpful, and the most common special sequences. Translate the guide into the users’ preferred language. Avoid assuming everyone recognizes English names for keys or diacritics.
Give the guide to someone who has never seen the project. Ask them to type a paragraph without coaching. Any repeated question reveals either unclear documentation or an input design that deserves another look.
Ask a first-time reader to type the cheat-sheet examples without guidance and then explain how to undo a mistake. Revise instructions when the same question is asked more than once. The guide should show actual keystrokes and approved words, not technical terms that only the developer understands.
12. Make release labels meaningful
Users cannot troubleshoot a mysterious file called final-new2.kmp. A release needs a recognizable keyboard name, version, language label, supported platforms and an honest change log. Release notes should mention any change to keystroke behavior, not only new characters.
Maintain a versioned manifest with source revision, build tools, fonts, licenses, test outcomes and download checksum where appropriate. Keep older verified releases accessible so teams can investigate a report against the exact binary that was installed.
Before replacing a community’s established layout, consider compatibility. If a key sequence changes, provide migration advice and show its effect on existing typing habits. Never claim seamless backwards compatibility without testing.
Publish a release manifest describing version, source revision, supported platforms, language tag and changed key behavior. Ask testers who used the previous version whether any familiar sequences changed. If they did, provide a migration note so a classroom does not continue teaching the old keystrokes.
13. Protect ownership, consent and community stewardship
For many language communities, the alphabet, lexical examples and teaching materials are not anonymous development inputs. The project needs agreement on who may approve orthography decisions and how sensitive examples are stored. Software distribution rights and language authority are different questions.
Record permissions for source text, sample audio, artwork and font assets. Invite relevant language users to determine accepted spelling variants and naming. Use synthetic test words when personal details are unnecessary and avoid publishing contact information collected during testing.
Build a route for correcting harmful or inaccurate examples. A technically sound keyboard still needs accountable stewardship, documentation in accessible language and a reliable maintainer contact.
Review the rights of every sample sentence, keyboard graphic and bundled font. Replace private conversations with consented or synthetic examples. Let language stakeholders distinguish a keyboard design recommendation from an officially adopted spelling rule, and provide a contact route for correcting the project.
14. Integrate typing tests into translation work
Translation teams frequently discover keyboard problems only after importing a large corpus into a dictionary, subtitle file or publishing platform. That is expensive because errors are copied into translation memories and terminology systems.
Before a major translation sprint, run a small typing acceptance test using the project’s real script, punctuation and word forms. Export plain Unicode text and test it in the target content system. Confirm reviewers can reproduce accents and correct mistakes without special workarounds.
Maintain a shared list of tricky words and sequences. After each keyboard update, type them again and compare raw text. When a problem originates in a font or XML import stage, assign it to the right owner rather than corrupting the keyboard mapping to hide it.
Import a small batch of newly typed words into the actual translation or dictionary software and export it again. Confirm characters, mark order, punctuation and lookup results. Keep difficult approved forms in a repeatable acceptance set; an interface may transform text even when the keyboard originally emitted it correctly.
15. Separate input, rendering and editorial QA
Three different reviews are needed: keyboard output correctness, font and shaping display correctness, and language-content correctness. A word can be spelled correctly but rendered badly; it can render beautifully while containing the wrong character; it can pass both tests yet be linguistically wrong.
Assign one reviewer to inspect Unicode sequences, another to inspect cross-application rendering and qualified language speakers to assess spelling and practical usability. Test against the same versioned sample pack so disagreements can be traced.
Record failures with expected and actual sequences, exact platform and a screenshot where helpful. Fix the layer that caused the defect, then rerun all three reviews before saying the keyboard is ready.
Assign code-point inspection, visual font review and language approval to reviewers with different responsibilities. Record each outcome for the same sample text. When only one stage fails, fix that stage and retest the others; changing the keyboard to work around a font bug can compromise data portability.
16. Plan an accessible long-term maintenance route
A keyboard is infrastructure that may outlive its original author. Future maintainers need editable source, test examples, release instructions, and a decision log explaining why unusual sequences exist. Community users should not lose the ability to type because one individual disappears.
Choose a public or appropriately access-controlled repository, document how to build without private credentials, and identify review authority. Record supported Keyman versions and use simple dependency tracking. Separate contributor feedback from instructions that a single volunteer must obey.
At handover, ask a second person to compile, install and validate the keyboard from archived source. Their success is stronger evidence of sustainability than a polished screenshot of the author’s own system.
Hand the source archive to someone who did not develop the keyboard. Ask them to locate the documentation, build a package, install it and run the sample tests without private credentials. Record every missing step before announcing that the community can maintain the layout independently.
Twelve worked keyboard design and release situations
The cases below are exercises rather than universal prescriptions. Communities may choose different layouts for good reasons. Each case shows how to identify the responsible layer, select a proportionate response and define a test that an independent reviewer can perform.
Case 1: A vowel with two marks
A literacy team has approved a vowel written with two combining marks. The designer initially assigns a key that enters only the base vowel and relies on a particular font to appear correct.
Map the full intended sequence, document the mark order and test the input in two fonts and two applications. Preserve the approved orthographic form instead of drawing an imitation precomposed glyph.
The test file must reveal the exact code points. A search for the word must find the typed instance, and copying it into a dictionary should not lose either mark.
The acceptance record should contain a word with both marks, its exact sequence and the result after pasting into a dictionary. Ask a fluent reviewer to confirm the spelling and a technical reviewer to confirm that neither code point was lost or exchanged for a lookalike.
Case 2: A borrowed word with unusual punctuation
People often switch between the community language and a national language in the same message. A keyboard whose punctuation keys have all been repurposed makes ordinary addresses, numbers and borrowed words hard to write.
Keep common punctuation accessible and offer an obvious path to borrowed characters. Ask actual writers which switching burden they prefer rather than assuming a full remapping is ideal.
Test an email address, a currency amount, a school name and a mixed-language sentence. No one should require a second installation simply to type common metadata.
Record the shortest way to type a mixed-language sentence, an address and a number. Have people who regularly use both languages compare the proposed punctuation access with their current practice, then document whether any convenience gain justifies a new learning burden.
Case 3: A mobile layout with too many popups
The first prototype hides the four most frequent modified consonants behind long-press popups to save visual space. Users make repeated mistakes and the long-press delay interrupts conversations.
Measure character frequency and place high-frequency letters on a primary layer when practical. Group true variants under discoverable popups, then test on smaller phones.
Compare error rate and completion time on the same thirty-word passage, not just preferences about appearance.
Give the same thirty-word passage to several phone users and record the slowest sequences. A design choice is justified when it improves common typing, not when it maximizes the number of displayed letters on a layout screenshot.
Case 4: An application breaks contextual replacement
A keyboard behaves correctly in a word processor but fails when the caret sits in the middle of a browser form. The team suspects an orthography problem, although the preceding context is not being handled consistently.
Reproduce the failure with exact key order, browser version and selection state. Test simpler rules in the same field and verify whether any platform limitation is documented.
Keep a focused issue report, avoid changing spelling conventions to compensate for a browser bug, and include an interim typing workaround if one is safe.
Attach a minimal browser test with the caret position, selected text and precise key order. Compare a standard text area with a rich-text editor. The bug report should identify which environment mishandles contextual replacement and whether an accessible workaround exists.
Case 5: A font makes a correct keyboard look wrong
A team sees disconnected letters and assumes the keyboard emits incorrect text. The same text renders properly in another font.
Inspect Unicode code points first. If they are right, try a font with appropriate OpenType shaping and compare using a relevant rendering engine. Do not emit presentation forms just to force a single visual appearance.
Keep a text sample and screenshots showing the original failure and corrected rendering. The release note should distinguish keyboard and font requirements.
Preserve one text file showing the intended Unicode code points and two screenshots from fonts with different script support. If the same string works in a capable font, do not change the key mapping to insert shaped presentation glyphs.
Case 6: A user cannot undo a dead-key mistake
A novice presses the accent dead key twice and the next vowel appears wrong. They cannot determine whether Backspace removed the vowel, the accent, or the pending keyboard state.
Document the input sequence and expected Backspace behavior. Test recovery from half-completed combinations and provide a predictable way to restart the sequence.
A new user should repair the word unaided after reading a short instruction. Confusing correction is a serious usability fault even if successful input is possible.
Ask a novice to intentionally enter a wrong accent and repair it three ways. Observe deletion of partial sequences and whether keyboard state remains active. Use the evidence to choose predictable correction behavior and to improve the first-use instructions.
Case 7: A shared corpus contains incompatible sequences
Two translators use different keyboard versions. Their documents look alike but some sequences normalize differently and searches return inconsistent results.
Capture versions and code-point samples. Establish a documented normalization and accepted spelling policy before importing large quantities of text.
Run equality and search tests across newly typed examples, past archives and database exports. Preserve originals when migration changes data.
Retain examples from both keyboard versions and compare their code-point sequences in search and export operations. If normalization or character choices differ, create a documented import policy instead of quietly overwriting years of approved entries.
Case 8: A school wants classroom deployment
A school intends to install a community keyboard on shared computers but lacks administrator privileges and has machines with different operating systems.
Prepare a supported deployment plan with the school’s IT staff, permitted installation paths and a small pilot. Provide classroom-ready exercises and an uninstall route.
Verify that ten learners can type the assigned passage and switch back to the system keyboard without losing work. Record problems by machine rather than treating the pilot as a success because one station worked.
Have the school’s IT team test an installation and removal procedure on one representative locked-down device. The classroom pilot should include exercises, accessibility needs and a safe way to return to the default keyboard without losing student work.
Case 9: A package is redistributed without documentation
An installer spreads through community chats with no clear maintainer or license. People cannot tell whether it is current or how to report a problem.
Publish a canonical download location, file version, minimal release notes and trusted contact. Avoid making unofficial mirrors the only source of installation files.
Have a volunteer download the package from the announced link, identify its version and reproduce the first-use instructions. Retire confusing old links without deleting historical source artifacts.
Confirm that the published download clearly identifies maintainer, license, supported platforms and version. Ask a user to locate release notes and report a bug using only the information in the package; missing answers are part of release QA.
Case 10: A reviewer disputes an orthography choice
Two proficient speakers prefer different punctuation or diacritic conventions. A developer is tempted to settle the dispute through a hard-coded key sequence.
Document the variants and consult the relevant community authority or agreed style process. If both are legitimate, design input access for both rather than silently declaring one invalid.
The acceptance checklist should separate mechanical usability from unresolved editorial choices. Record who approved any required restrictions.
Keep the disputed orthographic forms visible in the design record and seek a decision from the relevant community process. Where variants are recognized, test entry of each one. A keyboard’s ability to type a form is not a declaration that it is the preferred spelling.
Case 11: Typing changes during a project update
A new release simplifies a keystroke sequence but also changes what existing training sheets teach. Experienced writers interpret the new result as a keyboard defect.
Keep a compatibility note with old and new sequences. Pilot the change, update the cheat sheet and provide a staged adoption route where possible.
Ask testers using the previous release to complete a familiar text. Record whether retraining costs outweigh the measurable usability gain.
Test the proposed new sequence with experienced users and compare it against the old lesson sheet. Publish a migration example showing both keystroke paths, and note any change that could confuse writers who already rely on muscle memory.
Case 12: A language archive needs reproducible text
An archive receives documents created with an undocumented legacy keyboard. The letters look familiar, but their underlying bytes are not Unicode.
Do not promise that a new Keyman keyboard can repair the old files. Preserve originals, investigate encoding conversion separately, and provide a correct modern keyboard for new entries.
Validate old and new material using character inventories and sample words. Keep the migration audit trail so future researchers can distinguish repaired historic data from freshly typed text.
Preserve an unchanged old document and document the separate encoding-conversion method needed to interpret it. The new Unicode keyboard should be validated on fresh input; do not present it as a tool that automatically repairs legacy file bytes.
Quality-control worksheet for a keyboard release
- Language and orthography owner identified; representative text approved.
- Code-point inventory checked independently of typography.
- Desktop and mobile workflows tested where applicable.
- Dead keys, combining marks, punctuation, Backspace and cursor edits tested.
- Keyboard-only writing works with predictions disabled.
- Mixed-language documents and real receiving applications exercised.
- Regression tests stored with source revision and compiler version.
- Installation, uninstall, update, license and user instructions reviewed.
- Community feedback and long-term maintenance responsibilities documented.
Treat this worksheet as a record of evidence, not a certificate. A missing review must remain marked as missing. Testing one desktop text field cannot establish that an Android messaging application works, and a rendered screenshot cannot establish Unicode identity. If an application-dependent failure remains, describe its scope clearly in the release notes. The objective is a keyboard that the intended community can trust and improve over time.
Frequently asked questions
Is Keyman Developer a translation engine?
No. It helps create input methods, keyboard packages and related resources. Translation remains a language task performed or reviewed by qualified people. A keyboard makes approved writing practical but cannot select the right wording.
Start the evaluation by asking a fluent writer to translate a short message without assistance. If the typing method causes errors, diagnose input access; if wording is wrong, assign the issue to language review. These are different responsibilities.
Does a Unicode font replace a keyboard?
No. Fonts control display; keyboards provide input sequences. Both matter, but a beautiful glyph is not evidence of the correct underlying character. Inspect text values separately when troubleshooting.
Test a plain Unicode string in two fonts and record whether the character values remain identical. If they do, a visual discrepancy points toward rendering, fallback or shaping rather than a keyboard mapping defect.
Can one keyboard cover desktop and mobile?
Projects may target multiple platforms, but touch design and application behavior require separate testing. A desktop layout that compiles is not automatically a usable phone layout.
Do not sign off on a phone release using only desktop results. Record the exact handset, operating system, on-screen layout and text field tested, including how users recover from common typing mistakes.
Should every accent have its own key?
Not necessarily. Frequency, device size, memory and user preference decide whether a dedicated key, long press or composition sequence is sensible. Test frequent words rather than designing from a character chart alone.
Count how often each mark appears in approved sample material, then measure the actions needed to enter it. Frequency and user ergonomics provide stronger evidence than the idea that one key per symbol must be ideal.
How can I check what a key emitted?
Paste the result into a Unicode-aware character inspector and record code points. A screenshot is useful for visual review but insufficient for sequence verification.
Inspect an input sequence in hexadecimal notation and save it alongside the visible word. This helps distinguish code-point identity from a glyph that merely happens to look right in the reviewer’s selected typeface.
What does a successful kmc build prove?
It proves the compiler produced accepted artifacts under the specified tool conditions. It does not prove orthographic approval, mobile ergonomics or correctness in every consuming application.
Keep compiler output with a real language test. A successful build verifies generation of artifacts; learners need confirmation that familiar words, marks, deletion and punctuation work inside actual applications.
What should a keyboard release contain?
Include an installable package or other appropriate artifact, version, supported platforms, user guide, license, changelog, source access or stewardship plan, and reproducible test examples.
Before distribution, have an unrelated user install the exact package, find the user guide and report its version. A release is incomplete if the compiled file is usable only with the developer standing nearby.
Can prediction fix an incomplete layout?
No. Prediction should not be the only way to enter an approved word. Users must be able to produce the required characters deterministically, including unfamiliar names.
Try novel names and rare inflections with prediction disabled. This reveals whether the keyboard offers genuine expressive coverage or relies on a dictionary of suggested words to mask missing input rules.
How do we handle spelling variants?
Distinguish recognized variants from typing errors. Speak with language authorities and users, document editorial decisions and ensure the keyboard is not silently enforcing unsupported assumptions.
Have orthography stakeholders label examples as accepted variant, deprecated spelling or actual input error. Encode the distinction in editorial guidance, not through unreviewed automatic correction of writers’ text.
Why does text change after copying between apps?
Possible causes include normalization, font fallback, shaping, encoding conversion or an application’s input handling. Compare underlying code points before attributing the problem to the keyboard.
Compare the same string before and after copying and note both code points and rendering engine. When one layer changes, investigate it specifically rather than changing all project settings at once.
What tests matter most before public release?
Prioritize frequent words, difficult diacritics, punctuation, Backspace, caret movement, mixed-language text, mobile touch, accessibility, package installation and cross-application copying.
Select ten words with difficult marks and five cases of correction, then test them on the actual deployment devices. Keep failure examples as permanent regression tests after bugs are fixed.
Where are authoritative instructions?
The official Keyman Developer help, current kmc command reference and Keyman Developer Server testing documentation are appropriate starting points. Match the guide to the installed version.
Use the version-matched help pages for the installed compiler and testing server, and save exact links in the project documentation. A community maintainer needs stable instructions more than an unsourced command pasted from an old forum.
Official documentation and connected reading
- Keyman Developer documentation: https://help.keyman.com/developer/
- Keyman kmc command reference: https://help.keyman.com/developer/20.0/reference/kmc/cli/reference
- Keyman Developer Server testing: https://help.keyman.com/developer/20.0/context/server
- Related guide: Translate Like a Pro 12370 — Scripture App Builder: https://edukatesg.com/2026/11/13/translate-like-a-pro-12370-scripture-app-builder-usfm-usx-parallel-translations-audio-font-release-qa/
- Related guide: Translate Like a Pro 11750 — HarfBuzz: https://edukatesg.com/2026/11/12/translate-like-a-pro-11750-harfbuzz-hb-shape-hb-view-arabic-indic-glyph-shaping-font-features-clusters-qa/
Keyman Developer is most successful when its result becomes invisible in normal use: writers think about what they want to say instead of how to enter each mark. Build for people who must type every day. Keep the underlying Unicode sequences explicit, welcome correction from fluent language users, and test the complete route from keypress to archived text. The purpose of a custom keyboard is not to impose a technology; it is to make a language easier to write, teach, translate and preserve.