How do you localize a SMuFL 1.4 music-notation font, engraving interface or symbol catalogue without changing which musical glyph is being displayed? Standard Music Font Layout maps thousands of notation symbols to stable glyph names and code points, most in the Unicode Basic Multilingual Plane Private Use Area. The visual symbols themselves are not English words to translate. Human-facing descriptions, search terms, accessibility labels, documentation and interface instructions may be translated, but the symbol identity that music software relies upon must stay untouched.
People searching for SMuFL translation, SMuFL 1.4 localization, music font glyph naming, multilingual engraving software or musical-symbol accessibility need to separate three layers: code points and canonical glyph names, font-specific outlines and geometry, and explanatory language shown to readers. Confusing them can make a clef look like another sign, remove an accidental, mislabel a percussion technique or cause an accessible interface to announce the wrong musical concept even when the engraving still appears correct.
This guide explains how to build a multilingual SMuFL 1.4 experience for notation programs, font vendors, music publishers, education platforms and accessibility tools. It covers official glyph identities, JSON metadata, font substitution, anchors, engraving metrics, localization catalogs, Unicode pitfalls, musical terminology, quality assurance and international release workflows. The emphasis differs from eduKateSG’s MusicXML and MEI articles: here the protected object is a music-symbol vocabulary and its rendering contract rather than an individual encoded score.
How to localize musical symbol language while preserving the glyph contract
1. Understand the job of SMuFL
SMuFL is a standard mapping for musical symbols used by notation fonts and applications. It was created because legacy music fonts often assigned different meanings to the same internal positions, so changing a font could replace a notehead or articulation with an unrelated mark. A common vocabulary makes implementations more portable. It does not, by itself, translate performance directions or convert one composition into another. The multilingual task is to explain and search that vocabulary in different languages while leaving the underlying glyph identity consistent across fonts, document editions and applications.
2. Version 1.4 and its scope
SMuFL 1.4 is a published revision of the Standard Music Font Layout specification developed through the W3C Music Notation Community Group. The version includes additional symbols and expanded font metadata. Projects should record the exact repertoire version, supporting software, font version and any custom extensions. A tool that advertises support for SMuFL does not necessarily implement every symbol or every metadata field. Check the edition of the specification in use rather than assuming all fonts expose identical glyph collections. An application can legitimately fall back for an absent character, but it must not silently relabel a different glyph as equivalent.
3. Private Use Area is not ordinary text
Many SMuFL code points are allocated within Unicode’s Private Use Area. Unlike universally assigned ordinary text characters, a private-use code point obtains its meaning from a shared agreement between the font and application. Rendering the same code point with an unrelated font may produce a blank box or a different symbol. Therefore localizing a menu must never involve changing a PUA value to a visually similar character chosen from a word processor. Preserve the mapping and use the font and specification that define it. If portability matters, document the expected font and fallback behavior explicitly.
4. Canonical glyph names are technical identifiers
Every standardized SMuFL glyph has a canonical name designed for programmatic reference. The name may resemble English, but it is not a sentence or user-facing phrase to translate. An application might load a glyph by this name from a JSON description or use it to match font resources. If a localization workflow rewrites it into Spanish, Arabic or Japanese, the lookup may fail while the human text looks correct. Store localized display labels separately from the canonical identifier. Treat a glyph name like an API key: its exact spelling matters more to interoperability than its readability to end users.
5. Glyph code points must remain stable
A code point is the address at which the notation font provides the glyph. Changing it in translated documentation or source data can make an application render the wrong sign. Keep hexadecimal values, mapping tables and glyph-to-name associations unchanged, unless a genuinely new font implementation is being developed under the specification. A release should compare the complete mapping before and after localization. A single swapped pair might be hard to notice in a long symbol list but devastating in a score. This is why translation QA must include mechanical identity checks alongside ordinary language editing.
6. Fonts draw shapes, not semantics
Two SMuFL fonts can implement the same glyph identity with different artistic outlines. A curved clef, notehead or accent may reflect the font designer’s style, while the canonical semantic mapping remains the same. Translating the font’s descriptive notes must not suggest that a design variant represents a different duration, pitch or articulation without evidence. A multilingual product description can discuss aesthetic choices, but software should still use the standard identity of the underlying glyph. Separate questions about shape quality from questions about musical meaning so that artists and localizers do not overwrite each other’s work.
7. Metadata describes geometry as well as names
SMuFL includes metadata resources used by engraving applications, including information about positioning and font-specific details. A JSON key may be understandable English but still form part of a technical contract. Translate only approved human-language values, not schema keys or numerical measurements. When replacing a metadata file with a localized version, validate that anchors, advance widths and other geometry-related values are identical to the approved source. A document can remain parseable yet render articulations badly if these values drift. Treat technical metadata as executable evidence of the font’s engraving behavior.
8. Engraving defaults affect layout
Notation systems use default metrics for staff lines, spacing and other engraving elements. These influence the placement of symbols in a score and cannot be treated as locale-specific measurements merely because the surrounding interface uses another measurement convention. A target-language setting may present distances with local units or explanatory labels, but the internal calculation must remain based on the application’s expected geometry. When testing translated products, compare engraving outputs with identical source music. If symbols move, investigate fonts, metrics, zoom or rendering changes before blaming translated text.
9. Anchors determine musical placement
A font may provide anchors indicating where a stem attaches to a notehead or how a mark joins another mark. These are not arbitrary coordinates for typography: they influence whether a score reads correctly. Translating an anchor’s technical name or altering its coordinate can produce a disconnected stem, a misaligned accidental or an incorrectly stacked symbol. Maintain a protected inventory of anchor keys and values. Test representative combinations, not just isolated glyphs, because placement errors often emerge only when marks interact. The printed result is the actual evidence of whether the underlying technical contract survived.
10. Glyph classes and groups organize discovery
SMuFL organizes its repertoire into meaningful families. A user might browse clefs, accidentals, noteheads, articulations, rests, time signatures, historical symbols and instrument-specific marks. A multilingual interface may localize these category headings, but the canonical classification and category membership must be preserved. A label such as percussion techniques can vary in length across languages; its meaning still must select the same symbol set. Test filters, search results and counts. A correctly translated label attached to the wrong category can be more frustrating than an untranslated interface because it creates false confidence.
11. Musical terms are not always literal words
A label like accent, staccato or tenuto may have specialized notation meanings in addition to everyday meanings. The right target-language term is often an established conservatoire or publishing convention, not a literal dictionary equivalent. Consult musicians who use the intended notation system. Where a term has regional variants, provide an accepted synonym or explanatory note without redefining the glyph. Distinguish musical performance concepts from shape descriptions. A visually short stroke and the performance instruction it conventionally indicates may need different wording in an accessible application.
12. Accidentals need exact distinctions
A music-symbol catalogue contains more than sharp, flat and natural. Historical, microtonal and alternative tuning notations may use related-looking marks with distinct theoretical functions. A localization must not collapse them under a single generic translated term. The application may need to show a readable long description, a short search label and a technical canonical name separately. Preserve the underlying glyph and any context-dependent interpretation. During review, ask a specialist to identify the symbol by sight and explain its typical musical role; do not infer identity from the shape alone.
13. Clefs can carry contextual qualifiers
Clefs tell performers how staff positions relate to pitch, but similar graphic components can serve different roles depending on historical notation, octave markings and staff usage. A localizer should not simplify every clef into treble or bass to shorten a menu. Translate the supported description of the exact symbol, including its qualifiers, and keep the underlying glyph ID. Test its display beside staff lines and in the application’s symbol selector. If a symbol has a specialized historical use, explain that carefully rather than calling it an error or an obsolete version of a modern clef.
14. Noteheads encode more than note length
Different notehead forms can indicate duration, percussion technique, harmonic sound, shape-note practice or other notational conventions. Their meaning can depend on context. A target-language label should specify the relevant family and avoid promising one universal interpretation if the notation system allows several. Preserve the canonical name and code point; translate the educational description only. A user selecting a diamond notehead must not receive an X notehead after localization. Proof the symbol palette against both the specification and practical score examples, especially where small visual differences matter at performance size.
15. Rests, flags and beams
Rests and rhythmic symbols are dense with familiar-looking details. Changing a symbol’s classification during localization can lead performers or learners to confuse values. Technical glyph naming and font geometry must remain fixed, while user-facing descriptions can state duration and usage in natural language. Be mindful of cultural variation in notation vocabulary and common abbreviations. Test symbolic combinations at small sizes: a dropdown may display a rest clearly when enlarged, but the same icon in a toolbar can become ambiguous. Accessibility labels should identify the function rather than merely describe a squiggle.
16. Articulations are performance language
Staccato dots, accents, tenuto lines and other articulations encode performance information. Their visible form, position and combination can change interpretation. A translated tooltip should use an accepted musical term and, where necessary, explain the notation’s conventional function without claiming that every school plays it identically. For example, an accent can depend on style and musical context. The symbol lookup must remain stable even if explanatory prose is refined. In review, pair the label with a small score excerpt so musicians can judge whether the word and symbol actually belong together.
17. Ornaments and historical practices
Trills, turns, mordents and other ornaments have complex histories and notation traditions. Different regions and periods have used similar names or shapes differently. Translators should avoid silently choosing one modern interpretation as the universal meaning of a historical symbol. Keep identifiers stable, note the relevant historical context, and ask a musicologist to review educational explanations. A font repertoire can provide the glyph, but a font cannot establish every performance convention. The multilingual interface should be honest about which part is a symbol description and which part is interpretive guidance.
18. Dynamics use conventional vocabulary
Dynamic markings such as piano and forte frequently remain in traditional musical language even when an application is localized. Replacing them automatically with everyday words could confuse trained musicians or break established notation conventions. A sensible interface may retain the conventional label and provide a translated explanation for beginners. Do not mistake dynamic text objects in a score for SMuFL glyph identities. The former can be language-bearing content under a score format; the latter is a font-symbol mapping. Clear separation avoids accidental edits to performance data while improving discoverability.
19. Percussion signs require instrument context
Percussion notation may use unusual noteheads, playing-technique marks and instrument-specific symbols. A label that makes sense for snare drum technique may be misleading in a general orchestra symbol palette. Translate with the instrument or technique context visible and preserve the original code point. Avoid inventing an exact playing instruction when a symbol only identifies a family of markings. Review real parts, not just isolated icon images. A musician who works with the notation regularly can detect incorrect associations that an otherwise fluent translator may never recognize.
20. Tablature and guitar techniques
Guitar and other fretted-instrument notation uses bends, slides, fingering signs, harmonics and technique indications that may appear alongside conventional staff symbols. A translation should distinguish an action, a graphic representation and a specific glyph. Localized tutorials may explain how a technique is performed, but cannot redefine the canonical symbol. In a music editor, test tooltips on devices with different screen sizes and in score previews. The most useful labels are short enough for selection yet unambiguous enough to prevent a performer from choosing the wrong sign.
21. Early music symbols need humility
Symbols for mensural notation, neumes and other historical systems can resemble modern marks while carrying different meanings. A translator must not turn every unfamiliar historic sign into the closest modern name. Consult the standard repertoire, scholarly source and notation tradition. For public educational content, a brief explanation may be more valuable than an unsupported one-word equivalent. Preserve source terminology as needed and identify uncertainty. This is especially important when old manuscripts are converted into digital editions, because software availability should not be mistaken for certainty about historical performance.
22. Music braille is a different representation
Accessible music can be represented using braille music notation, which has its own syntax and conventions. A SMuFL glyph catalogue is not automatically a braille translation engine. Translating a glyph’s spoken description does not produce correct braille music, nor does substituting a font make a printed score accessible. Products should identify whether they offer symbol identification, screen-reader labels, structured musical navigation or actual braille output. Those are related but distinct capabilities requiring different tests. Make accessibility claims precise so users can choose a tool that truly meets their needs.
23. Screen-reader labels must describe function
A screen reader needs meaningful text, but the ideal announcement depends on context. An isolated sharp glyph in a symbol palette should be described differently from a sounding F-sharp in an encoded score. A static lookup can translate the symbol’s conventional name; the score-reading application must also provide musical context. Keep accessibility strings separate from code points, use the target language for pronunciation, and test with the assistive technology people actually use. Avoid overly verbose labels that make repetitive score navigation exhausting. Meaningful access is a usability task, not merely a string-translation task.
24. Search requires aliases, not renamed IDs
A notation application may let users find a glyph by typing a name. International users need local-language terms, transliterations, colloquial aliases and perhaps English synonyms. Add those to a separate search index that resolves to the same canonical glyph ID. Never make the translated term become the database key. Search should tolerate accents and reasonable spelling variants without merging musically different symbols. Test broad queries like flat against more specific symbols and ensure results show enough context to choose the correct item. A good multilingual search layer expands access while leaving the technical repertoire untouched.
25. Short names and long descriptions
Toolbar labels, menu names, glossary definitions and spoken announcements have different space and clarity needs. A compact label that works in English may require more characters in German, Polish or another language. Rather than truncating a music term into ambiguity, create approved short and long fields. The short version identifies the action or symbol; the long one provides context and warnings. Preserve a single stable technical ID behind both. A reviewer should see each string in the actual interface, because translation quality cannot be judged from a spreadsheet cell alone.
26. Right-to-left scripts in symbol palettes
Arabic, Hebrew and other right-to-left interfaces can cause numbers, punctuation and Latin glyph names to appear in confusing orders. Music notation often remains oriented according to its own engraving conventions even while menus and explanatory text follow another writing direction. Apply proper interface direction handling rather than mirroring musical glyphs blindly. Test the order of search results, the display of hexadecimal code points and mixed-language labels. A source code point shown next to the wrong symbol is an identity error, not a minor typographic blemish. Verify both logical and visual reading order.
27. Unicode normalization and filenames
Localization files may contain accented characters, combining marks and multiple scripts. Consistent Unicode handling is essential for matching translated labels and searching terms. Yet normalization of text must not be extended indiscriminately to glyph identifiers or code points. Keep file encodings explicit and avoid software that silently rewrites technical keys. Test metadata load on the operating systems supported by the product. A filename that changes under a platform-specific normalization rule can prevent a localized resource from loading even when every string inside it is valid.
28. Font fallback is a real risk
An application that cannot find its configured music font may display fallback symbols, blanks or visually wrong glyphs. Changing the UI language sometimes changes operating-system font preferences or the order of fallback choices. Test each supported locale with the intended notation font installed, then test deliberate missing-font conditions. Report missing glyphs honestly instead of substituting a similar-looking mark without evidence of equivalence. A helpful product can show the symbol name and explain that the font is unavailable, allowing a user to diagnose the issue rather than trusting corrupted notation.
29. Application metadata and custom glyphs
Some projects add private symbols beyond the standardized repertoire. Their identifiers, code points and documentation require governance because different vendors may allocate the same private positions differently. Translate a custom symbol’s human description but preserve its declared custom namespace and technical mapping. Label nonstandard glyphs clearly, especially when sharing fonts or score files internationally. A local extension should not claim to be part of the SMuFL 1.4 core merely because it sits near other glyphs in a palette. Compatibility requires transparent versioning and explicit extension metadata.
30. JSON structure needs machine validation
SMuFL metadata is often represented in JSON, where punctuation, keys, numbers and nesting matter. A localization tool that produces valid translated strings may still damage the surrounding structure by duplicating a key or changing an escaped character. Parse the output and validate it against the expected metadata contract. Compare protected fields to the original, and test loading in the consuming application. Do not assume a valid JSON file is semantically correct: it might point a translated label at the wrong canonical glyph name or attach a geometry value to the wrong entry.
31. Compare mappings deterministically
Create a baseline of canonical names, code points, group memberships and geometry-related metadata before localization. After the new language files are built, compare these protected fields exactly. Differences should be investigated, not waived because the displayed pages look similar. A deterministic comparison can catch a missing comma’s consequence, an accidental row shift or a numeric value copied into the wrong entry. For large glyph repertoires, this is more reliable than manually scanning a spreadsheet. Human reviewers should then focus their effort on the quality of translated concepts and visible user experience.
32. Proof symbol families as a set
Isolated glyph checks miss confusions between related signs. Review accidentals together, clefs together, noteheads together and technique symbols within the same instrument context. Put the canonical name, target-language label, rendered glyph and a practical example side by side. Reviewers can then notice if two distinct glyphs have accidentally received the same label, or if one term conflicts with established music pedagogy. This approach also reveals missing coverage. If a category contains many localized items but a few unexplained source-language entries, the gaps become visible before release.
33. Use more than one notation application
Rendering differences can arise from the font, metadata handling or application logic. Test a representative score and a glyph-browser view in the intended software products, especially if users are expected to move documents between them. A valid SMuFL font may be only partially supported by one notation program. Document those limitations rather than attributing them to translation quality. In multilingual software, confirm that switching the interface language does not alter which symbols appear in an unchanged score. The music output should remain stable even when navigation and help text change.
34. Build a real musical terminology glossary
A production glossary should include canonical technical ID, accepted translated label, approved short form, search aliases, domain context, reviewer, and source of authority. Keep dialectal variants distinguishable without forcing false synonyms. Some terms benefit from retaining Italian, French or German performance vocabulary because that is what performers encounter on the page. Others need a translated explanatory phrase to support beginners. Consistency is valuable, but it must not flatten the difference between an engraving instruction and the sound or gesture that the mark represents.
35. Separate conceptual review from proofreading
A proofreader can detect grammar, agreement and punctuation errors but may not know why a symbol’s name matters. Musical reviewers validate the association between sign and concept; font engineers validate mappings and geometry; accessibility specialists validate announcements and navigation. Divide these responsibilities explicitly. If a proposed wording change affects a technical name, it must be rejected or redirected to the display layer. If a code point fails, translating the label again will not repair it. A structured review route reduces unnecessary arguments and makes defect reports actionable.
36. Handle multilingual documentation safely
A manual may show examples of XML, JSON, code points and font metadata next to explanatory prose. Translate the explanation, but preserve machine-readable snippets unless the lesson explicitly demonstrates a localized display value. Technical examples should be copyable and work in the stated version. Test the commands and sample files presented in translated guides, especially where quote marks or decimal separators might be altered automatically. A learner should leave the article able to identify a glyph or inspect metadata without having to reverse-engineer which parts were changed for language and which are required by software.
37. Never equate appearance with equivalence
Two musical signs may look similar at small sizes while differing in interpretation. Conversely, two fonts may draw a standardized symbol differently while maintaining the same meaning. Localization decisions must be grounded in IDs, authoritative descriptions and notation practice, not a visual guess. This is crucial for microtonal accidentals, historical glyphs and related articulations. Where the precise use depends on music tradition, communicate that limitation openly. A title like ‘special sharp’ may sound simple but can be a serious misdescription if it hides the actual notational distinction.
38. Teach beginners without distorting symbols
Education platforms benefit from clear translations of technical vocabulary. A short explanation can connect an unfamiliar symbol to a familiar musical concept, but it should not promise a rule that fails in other contexts. For a beginner, say that a natural sign generally cancels a previous accidental within the applicable notation conventions, rather than treating it as a command that always means white key. Link the educational description to the exact canonical glyph and, when appropriate, a structured note example. This makes teaching aids portable and helps learners progress beyond simplified initial explanations.
39. Version updates need regression testing
A new font or application version can add glyphs, alter internal documentation or change how optional metadata is interpreted. Do not simply merge a previous language catalog into a new release without inspecting changes. Compare the new official repertoire to the old mapping, identify additions and deprecated assumptions, and translate only new human-facing material. Run the same symbol-family and font-fallback tests against the updated build. The stable canonical names are a strength, but stable IDs do not guarantee that every surrounding interface string or application behavior is unchanged.
40. Describe licensing accurately
The SMuFL specification and individual music fonts can have different licensing conditions. A notation font’s ability to display a glyph does not automatically grant permission to redistribute every packaged asset in every context. Translation teams should read the license of the specific font, metadata files and documentation they ship. Keep copyright notices and attribution requirements intact, translating explanatory surrounding text if appropriate without changing legal identity. Avoid implying that compliance with the SMuFL repertoire proves the font is free to embed or distribute. Those are separate technical and rights questions.
41. A reliable international release
A credible release includes the original mapping baseline, localized text catalog, approved glossary, affected software and font versions, parser checks, rendered symbol samples, accessibility tests and known limitations. Maintain an issue path for users who find wrong labels or missing symbols. When a correction changes only a display term, the technical glyph map should remain byte-for-byte stable. When a technical bug is found, handle it through the font or application engineering process rather than disguising it as translation. International users benefit most when both kinds of changes are transparent.
Worked quality-control situations
A sharp becomes a different symbol
A translation spreadsheet is sorted alphabetically without retaining stable keys. The target-language label for one sharp variant ends up beside a different microtonal sign. The interface still opens, and both glyphs render correctly in isolation. The error appears only when a musician searches for a particular accidental. Prevent it by joining translations through canonical glyph identifiers, not row positions. Compare every mapping after import. Have an expert test related accidentals as a group and verify that the displayed wording refers to the exact symbol that the palette will insert.
A stem disconnects from its notehead
A metadata editor changes an anchor field while translating nearby explanatory text. The JSON remains parseable but a stem attaches at the wrong location in engraved scores. The problem cannot be fixed by choosing a shorter translation. Restore the protected anchor value from the approved font baseline, run the font metadata comparison and re-render combinations of noteheads and stems. The case illustrates why technical metadata and language metadata need separate editing permissions. Good prose has no value if the engraving geometry becomes unreliable.
A right-to-left toolbar misleads readers
An Arabic localization mirrors every icon in a palette automatically. Some interface arrows should reverse, but a musical symbol should not automatically be reflected. A clef or articulation can become a false glyph. Distinguish layout direction from symbol orientation. Keep SMuFL glyph IDs and shapes mapped correctly, and inspect the final UI with a knowledgeable musician who reads the target script. Accessibility and search labels can be translated and ordered naturally without inventing a mirrored musical vocabulary.
Font substitution hides missing support
A music educator switches languages and the application chooses a general-purpose font with no matching private-use symbols. The screen shows boxes where articulations should appear. A translator may mistakenly try to replace every glyph with a Unicode word. The actual fix is to restore the intended music font or provide documented fallback support. The UI should identify the missing glyph by its approved name and make clear that notation rendering is unavailable. This preserves the encoded music while making the problem understandable to the user.
An outdated glossary confuses percussion
A program adds a set of instrument-specific glyphs in a new release, but the localization team reuses older terms intended for a different technique. Both sets are translated fluently, yet players cannot distinguish the instructions. Compare the supported glyph repertoire and contexts against the updated specification, rebuild the glossary entries and test them in real instrument parts. A good localized label must reflect the intended notation practice, not merely fit within the screen width.
A historical ornament is overexplained
A learning app labels a historical ornament with a modern performance rule presented as certain. Students then apply the rule universally to scores from other periods. The glyph itself is correctly mapped, but the educational description is wrong in scope. Replace the absolute claim with a qualified, contextual explanation and provide an expert reference. Keep the glyph’s stable technical identity untouched. Multilingual educational content must preserve the uncertainty of interpretation just as carefully as it preserves the code point.
A screen reader announces coordinates
An accessibility layer exposes a private-use code point number instead of a usable musical name. A student navigating a score hears an opaque numerical string for every articulation. The solution is not to translate the numeric code point; it is to supply appropriate localized descriptions tied to canonical glyph identities, enriched by score context where possible. Test repetitive navigation with native-language screen-reader users. The announcement needs to be concise, accurate and distinguishable from neighboring symbols.
A renamed key breaks search
A developer translates the canonical glyph name inside a JSON mapping to make it look natural in French. The search interface displays the name correctly but the engraving engine cannot find the symbol it references. Restore the canonical key, move the French wording into a separate display catalog and add French synonyms to the search index. Automated tests should assert that all standard glyph IDs resolve before any localized UI test begins. The incident demonstrates that code-level identity and human-language presentation must never be conflated.
SMuFL localization questions
Should SMuFL canonical glyph names be translated?
No. Treat them as stable technical identifiers. Translate human-facing labels, explanations and search aliases in separate resources.
Can a SMuFL glyph be copied into an ordinary text font?
Not reliably. Most standardized glyphs occupy the Unicode Private Use Area and require a font that implements the agreed mapping.
Does SMuFL define how every symbol must be performed?
No. It standardizes glyph mappings and related engraving resources. Musical interpretation still depends on score context and notation practice.
Why does JSON matter in a localization project?
Font metadata and application resources may use JSON keys, mappings and numbers. Translating keys or changing geometry can break lookup and rendering.
What is the best way to review translated symbol labels?
Show the glyph, canonical ID, translated short name, long explanation and a practical notation example together; then have a domain specialist review them.
Are microtonal signs safe to group as sharp and flat?
No. Similar-looking signs may encode different systems or intervals. Distinguish each glyph according to its actual identity and context.
Does a translated symbol name make a score accessible?
It is useful, but not sufficient. Navigation, score semantics, assistive-technology behavior and sometimes braille transcription need separate work.
What should remain unchanged across locales?
Canonical names, code points, group membership, non-language metadata, font geometry, source notation and any machine-readable relationship.