German Braille

Engineering German Braille into Braille Hub: From a Language Feature to a Full Multi-Layer Braille Runtime

Introduction

German Braille support is now fully integrated into Braille Hub, marking one of the most substantial engineering milestones in the evolution of the project.

Braille Hub began as the modern reconstruction of an older Persian-to-Braille implementation. The original historical project was heavily tied to office macros, isolated translation tables, and a specific language context. The v2 architecture was designed to move far beyond that model.

The goal of Braille Hub is not simply to convert characters into Braille cells. It is to provide a specification-driven accessibility platform with clear architectural boundaries, reusable runtime components, public APIs, host integrations, deterministic validation, and support for multiple Braille domains.

The German Braille phase became an important proof of that architecture.

At the beginning, German Braille looked like one item in a much larger roadmap: add another language, connect it to the Core, expose it through the SDK, and make it available in Microsoft 365.

In practice, it became a project inside the project.

German Braille required a much deeper implementation because it introduces several dimensions that do not exist in a simple one-character-to-one-cell model:

multiple text levels,
context-dependent contractions,
pronunciation-sensitive behavior,
morphology-sensitive behavior,
regional differences,
position-sensitive rules,
stateful translation,
abbreviation behavior,
structural punctuation handling,
phrase-level exceptions,
sentence and paragraph composition,
and different behavior between ordinary text and source-backed special cases.

This article documents how German Braille was engineered into Braille Hub, how the implementation evolved, which architectural decisions were made, how the Microsoft 365 integration works, how runtime ambiguity is handled, and how the final production closure was validated.

1. The broader Braille Hub architecture

Before discussing German Braille specifically, it is important to understand the architecture into which it was integrated.

Braille Hub follows a strict separation of responsibilities.

The central rule is:

Specification owns the rules. Core executes them. SDK exposes them. Applications and integrations consume the SDK.

In simplified form, the architecture looks like this:

Specifications / Source-backed contracts
                 |
                 v
        @persian-braille/core
                 |
        +--------+--------+
        |                 |
        v                 v
@persian-braille/music  @persian-braille/sdk
                              |
                +-------------+-------------+
                |             |             |
                v             v             v
               CLI           Web      Microsoft 365
                                         |
                              +----------+----------+
                              |          |          |
                              v          v          v
                             Word       Excel   PowerPoint

The important point is that Microsoft Word, Excel, and PowerPoint do not contain their own German Braille implementations.

They consume the same public SDK.

The SDK does not duplicate translation semantics either.

The actual language behavior lives below the SDK boundary in the Core.

This means that once German Braille is implemented correctly in the Core and exposed through the SDK, the same semantic layer can be reused by:

Microsoft Word,
Microsoft Excel,
Microsoft PowerPoint,
command-line tools,
browser applications,
future integrations,
and third-party software.

This architecture was one of the key reasons why the German Braille phase was worth doing carefully rather than implementing a fast Office-specific converter.

2. Why German Braille became a project of its own

The original roadmap described Phase 15 as a broader multi-language or general Braille framework.

German Braille was expected to be one major implementation inside that phase.

As the work progressed, it became clear that German Braille was large enough to require its own internal roadmap.

The effective decomposition became:

Phase 15.1 — Basisschrift
Phase 15.2 — Vollschrift
Phase 15.3 — Kurzschrift
Phase 15.4 — Swiss / Regional
Phase 15.5 — German Core
Phase 15.6 — German SDK
Phase 15.7 — Microsoft 365 German Tab
Phase 15.8 — Conformance / Regression
Phase 15.9 — Phase 15 Closure

Each of these areas introduced its own contracts, source analysis, runtime requirements, test surfaces, and closure criteria.

This changed the nature of the work.

It was no longer:

“Add German to the translator.”

It became:

“Build a German Braille subsystem that can coexist with Persian, preserve the existing architecture, expose a stable public API, support multiple Braille levels and regions, work in three Office hosts, and remain deterministic under CI.”

3. The three German Braille levels

The German implementation supports three text modes:

Basisschrift
Vollschrift
Kurzschrift

These are not treated as cosmetic output settings.

They represent distinct translation behavior.

3.1 Basisschrift

Basisschrift is the most direct layer.

It provides the basic German Braille mapping and structural behavior.

Although it is conceptually the simplest of the three levels, it still requires more than a plain alphabet dictionary.

The runtime includes:

direct structural mappings,
indicator and state policy,
contextual behavior,
punctuation behavior,
spacing semantics,
and compatibility with the broader German translation pipeline.

At clean build time, the Basisschrift generated runtime is reconstructed from a source-backed lowering dataset containing:

123 runtime records

These records are not manually copied into the generated TypeScript file.

They are produced deterministically from tracked source artifacts.

That distinction became important later when repository hygiene and clean-checkout reproducibility were finalized.

4. Vollschrift: where lexical context becomes important

Vollschrift is where the implementation becomes significantly more complex.

German Vollschrift includes contractions such as:

sch
au
ch
ei
eu
ie
st
äu

But identifying a character sequence is not enough.

A substring may or may not be contractible depending on its context.

The runtime therefore has to consider factors such as:

lexical boundaries,
pronunciation eligibility,
morphological structure,
special st behavior,
abbreviation policy,
and explicit source-backed exceptions.

This means that the algorithm cannot simply do:

find "ch"
replace with contraction

That would produce incorrect Braille in many contexts.

Instead, the resolver must first determine whether the candidate is eligible for contraction.

5. The first Vollschrift architecture: safe but too closed

An early version of the automatic Vollschrift runtime took a very conservative approach.

Known words and known candidate contexts were represented in a closed source-backed registry.

This had a major advantage:

the runtime never guessed.

If a context had been explicitly analyzed and fixed by the source material, the runtime could safely make a decision.

If not, it returned a structured unresolved result.

Architecturally, this was much safer than inventing linguistic behavior.

However, it created an obvious production limitation.

Real users do not type only words that already exist in a registry.

A translator has to process arbitrary ordinary German text.

A free-text paragraph quickly exposed the issue.

Words containing sequences such as:

sch,
ch,
au,
ei,
ie,
or st

could cause an automatic Vollschrift failure when the complete lexical context was not already registered.

The runtime was technically conservative, but not yet practically general.

6. Moving from a closed lexical registry to a general resolver

The solution was not to add hundreds or thousands of words to the registry.

Doing that would have created a dictionary-driven implementation and would eventually fail again on the next unknown word.

Instead, Braille Hub introduced a General Vollschrift Resolver.

The key design was to preserve the priority of known normative/source-backed decisions while introducing a general fallback.

The final priority is effectively:

1. Exact full-input source plan
2. Closed source-backed word/candidate decision
3. General rule-driven lexical resolution

This order matters.

It ensures that if an explicit source-backed exception exists, the generic resolver does not override it.

The general resolver therefore expands coverage without weakening the source hierarchy.

This changed the system from:

“Known word or fail”

to:

“Known source-backed exception first, otherwise resolve through the general lexical rules.”

That was one of the most important architectural changes in the entire German phase.

7. Why the resolver is not a hidden dictionary

A central requirement was that the solution must not become a disguised list of hard-coded test words.

The implementation was deliberately designed so that audited failures were not added one by one.

For example, instead of separately registering:

schnell
schwierig
durch
auf
weil
Liebe
Stadt
Häuser

the runtime resolves their relevant contraction candidates through general rules.

The regression suite contains representative examples, but the runtime behavior is not limited to those examples.

This distinction is fundamental.

Tests demonstrate a rule.

They are not the rule.

8. Multi-word translation and the sentence-composition problem

A second major limitation appeared when translating complete sentences.

The first Vollschrift runtime assumed a global relationship between input code points and Basisschrift cells.

This worked for simple cases where every input code point produced one cell.

It failed when structural segments or source-backed phrase behavior produced output lengths that did not map one-to-one to the original input.

The problem became visible in selections such as:

Baum Liebe

or phrase-level fixtures such as:

St. Pauli

The solution was to stop treating the entire sentence as one flat codepoint-to-cell array.

Instead, the runtime introduced composition by lexical and structural segments.

Conceptually:

input
  ↓
segment into lexical and structural runs
  ↓
translate each segment using the correct layer
  ↓
preserve exact source-backed full-input plans where defined
  ↓
compose Unicode Braille output

This allowed:

words,
spaces,
punctuation,
sentence boundaries,
paragraphs,
and exact multiword fixtures

to coexist correctly.

9. Preserving exact phrase fixtures

A naive solution would have been to split every sentence on whitespace.

That was rejected.

Why?

Because some known source-backed behavior is defined over more than one token.

For example, an exact phrase or abbreviation may need to remain authoritative as one unit.

Therefore the runtime uses a precedence strategy:

attempt the exact full-input plan,
preserve known phrase-level behavior,
only then fall back to lexical composition.

This prevents the sentence-composition engine from accidentally destroying special source-backed cases.

10. Kurzschrift: a different category of complexity

Kurzschrift is substantially more complex than Vollschrift.

It contains many forms of contracted behavior and requires broader contextual interpretation.

The source material contains rules for:

standalone contractions,
word parts,
multi-form contractions,
contextual forms,
semantic targets,
phrase behavior,
and multiple rule families.

The German Kurzschrift closure eventually produced a substantial formal evidence base.

At clean build time, the generated runtime is reconstructed from:

18 formal source artifacts
119 formal rules
645 validation cases

This dataset is one reason why the German phase grew into a large independent engineering effort.

11. A critical Kurzschrift policy: do not invent precedence

During implementation, a difficult class of cases appeared.

Sometimes the source material establishes multiple valid possibilities or defines policy-level information without defining one globally safe automatic precedence rule.

A translator still needs to behave safely in production.

There are two possible bad solutions:

Bad solution A: fail the whole paragraph

This is technically conservative but makes ordinary text unusable.

Bad solution B: invent a contraction rule

This makes the application appear successful but silently creates a normative rule that is not actually supported by the source.

Braille Hub intentionally chose neither.

The final production policy is:

If a source-backed Kurzschrift decision is executable:
    apply it.

If the Kurzschrift-specific precedence is not safely established:
    preserve the valid Vollschrift parent.

This means that Braille Hub remains usable without pretending to know more than the source establishes.

It is one of the most important principles of the German implementation.

12. Why fallback to Vollschrift is better than fabricated Kurzschrift

A Vollschrift fallback is not equivalent to “ignoring Kurzschrift.”

It is an explicit safety mechanism.

The system still applies all Kurzschrift contractions for which it has sufficient source-backed evidence.

Only the ambiguous contraction-specific layer falls back.

This gives three important properties:

No fabricated normative behavior
No catastrophic failure of ordinary text
Preservation of all known source-backed Kurzschrift behavior

This is a much stronger production boundary than simply forcing a result for every possible candidate.

13. Germany / Austria and Switzerland

German Braille also introduces regional behavior.

Braille Hub supports:

Deutschland / Österreich
Schweiz

A major architectural decision was that Switzerland should not become a separate German engine.

Instead, region is modeled as an orthogonal axis.

Conceptually:

Text mode:
    Basisschrift
    Vollschrift
    Kurzschrift

Regional configuration:
    DE/AT
    CH

This creates combinations such as:

DE/AT + Basisschrift
DE/AT + Vollschrift
DE/AT + Kurzschrift

CH + Basisschrift
CH + Vollschrift
CH + Kurzschrift

This architecture is much more scalable than implementing six independent translators.

14. The Swiss `ß` boundary

One regional policy remains deliberately fail-closed.

Explicit ß input under Swiss configuration is not silently rewritten by the translator.

This is intentional.

The Swiss orthographic environment differs from Germany/Austria, but the translator should not automatically invent or normalize an unsupported lexical transformation.

Therefore explicit Swiss ß remains a structured regional rejection.

This is a good example of an important project principle:

A translator should not turn uncertainty into fake certainty.

15. German Core integration

After the German-specific specification and runtime work was established, the next goal was to integrate it into the shared Core.

The German Core layer provides:

text-mode definitions,
regional configuration,
Basisschrift execution,
Vollschrift execution,
automatic candidate resolution,
Kurzschrift execution,
sentence composition,
structured failure behavior,
and immutable runtime result objects.

The German runtime remains platform-independent.

It does not know about:

Word,
Excel,
PowerPoint,
Office.js,
browser UI,
or Microsoft manifests.

That separation is intentional.

16. Public SDK integration

The German translator is exposed through the public SDK.

This is important because Office does not import the German Core directly.

The public boundary remains:

Microsoft 365
     ↓
@persian-braille/sdk
     ↓
@persian-braille/core

The SDK owns the public developer-facing result/error projection.

Consumers do not have to understand internal Core trace objects or internal source-registry details.

This keeps future integrations stable even if internal German runtime implementation details evolve.

17. Microsoft 365 integration

Once the Core and SDK layers were stable, German Braille was integrated into the Microsoft 365 Add-in.

The Add-in now provides a dedicated Deutsch workflow.

The user can select:

Region

Deutschland / Österreich
Schweiz

German Braille level

Basisschrift
Vollschrift
Kurzschrift

The same translation semantics are then used in:

Word,
Excel,
and PowerPoint.

18. Word workflow

In Microsoft Word, the German workflow supports a preview-first model.

The typical path is:

Select text
   ↓
Preview German Braille
   ↓
Inspect result
   ↓
Copy / Replace / Insert after selection

Word mutation operations preserve the existing stale-selection guard.

This means that if the user changes the selected text after generating the preview, Braille Hub will not blindly overwrite a different selection.

The mutation boundary verifies that the current host selection still corresponds to the preview source.

This safety behavior was already part of the broader Microsoft 365 architecture and remains preserved for German Braille.

19. Excel workflow

Excel uses the same public German translator but a host-specific selection adapter.

The German engine itself does not need to know anything about spreadsheet cells.

Excel is responsible for:

reading the selected cell/range content,
passing the text to the SDK,
receiving Unicode Braille,
and performing a host-safe replacement operation.

This is exactly the kind of reuse the original v2 architecture was designed to enable.

20. PowerPoint workflow

PowerPoint follows the same principle.

The host layer manages selected text and mutation behavior.

The public SDK handles the German translation.

The Core owns German semantics.

This avoids the common integration problem where each host ends up with its own slightly different translation logic.

21. Production UI cleanup

The engineering implementation initially contained internal terminology that was useful during development but inappropriate for end users.

Before closure, the German task pane was cleaned up into a production-facing interface.

Internal concepts such as:

phase numbers,
profile/debug identifiers,
runtime metadata,
implementation state

were removed from the primary user interface.

The final interface emphasizes user decisions:

language/feature,
region,
Braille level,
preview,
and document action.

This was an important step in moving from an engineering prototype to a product surface.

22. German is part of the same Braille Hub installation

German Braille does not ship as a separate add-in.

There is no:

Braille Hub German Edition

and there is no separate German installer.

Instead, the standard Braille Hub distribution includes the German workflow.

The public installation documentation was updated accordingly.

The generated installation page explicitly documents:

German Braille,
Deutschland / Österreich,
Schweiz,
Basisschrift,
Vollschrift,
Kurzschrift.

The same hosted manifest and public distribution architecture is used.

23. Marketplace-oriented build

The Microsoft 365 production build was validated with the production base URL:

https://soroushneyestani.github.io/Persian-to-Braille

The build produced the Marketplace-oriented payload and production manifest successfully.

The manual preview distribution was also generated successfully.

This confirms that the German UI and runtime are included in the same distribution flow used by the rest of Braille Hub.

24. Repository hygiene and generated runtime files

One of the last technical issues discovered during Pull Request validation had nothing to do with German translation correctness.

It was a repository hygiene issue.

The German runtime modules:

packages/core/src/generated/de-basisschrift.runtime.ts
packages/core/src/generated/de-vollschrift.runtime.ts
packages/core/src/generated/de-kurzschrift.runtime.ts

were initially tracked by Git.

The repository architecture explicitly forbids generated runtime artifacts from being tracked.

The CI correctly rejected this.

The first fix removed the files from Git.

That made repository hygiene pass—but exposed a second problem.

25. The clean-checkout build problem

On a developer machine, the generated German runtime files already existed.

On GitHub Actions, a fresh checkout did not contain them.

After they were correctly removed from version control, TypeScript compilation failed because the German runtime imports referenced generated modules that had not yet been recreated.

This is a classic clean-checkout reproducibility issue.

The proper fix was not to re-track the generated files.

Instead, Braille Hub added a deterministic German runtime generator.

26. Deterministic German runtime generation

The build pipeline now includes:

tools/architecture/build-german-runtime-bundles.mjs

Before Core TypeScript compilation, the build creates the generated runtime modules from tracked source-backed artifacts.

The build-time flow is now:

clean checkout
      ↓
spec:prepare
      ↓
generate Persian runtime
      +
generate German runtime
      ↓
TypeScript compilation

The generated German modules are ignored by Git.

They remain reproducible build artifacts rather than a second source of truth.

27. Basisschrift generated runtime

The Basisschrift generator consumes the frozen execution-lowering artifacts.

The final generated baseline contains:

123 Basisschrift runtime records

These are assembled from multiple source-backed categories such as direct structural records, indicator/state policy, and contextual behavior.

The generator validates the expected record counts before writing the runtime module.

If the underlying contract changes unexpectedly, the generator fails rather than silently producing a different runtime.

28. Vollschrift generated runtime

The Vollschrift generator reconstructs the runtime from the Phase 15.2 formal source artifacts.

The generated baseline includes:

8 contraction families
48 normative fixtures

It also carries source identities and rule groups for:

formal eligibility,
morphology,
pronunciation,
st policy.

This preserves traceability between the generated runtime and the frozen source-backed evidence.

29. Kurzschrift generated runtime

Kurzschrift is generated from the formal closure manifest and its referenced artifacts.

The generation baseline is:

18 formal artifacts
119 formal rules
645 validation cases

The build asserts those counts.

If the closure manifest no longer matches the expected formal baseline, the build fails.

This is intentional.

Generated code should be deterministic and reproducible, not opportunistic.

30. Why generated runtime files are not committed

There are several reasons.

30.1 Single source of truth

If both source artifacts and generated TypeScript are committed, it becomes possible for them to diverge.

30.2 Determinism

A correct build should prove that generated outputs can be recreated from tracked sources.

30.3 Cleaner code review

Pull Requests should review source changes, not large generated blobs.

30.4 CI confidence

A clean checkout that successfully regenerates all runtime files provides stronger evidence than a repository that happens to contain previously generated output.

31. Clean-checkout simulation

Before finalizing the CI fix, the project was explicitly tested from a clean generated state.

The validation sequence included:

clean workspace
build workspace
typecheck workspace
architecture validation
Core regression
SDK regression
Microsoft 365 regression
final clean

The important result was:

WORKSPACE_BUILD_FROM_CLEAN_GENERATED_STATE=PASS
WORKSPACE_TYPECHECK=PASS
ARCHITECTURE_VALIDATION=PASS
CORE_REGRESSION=PASS
SDK_REGRESSION=PASS
OFFICE_REGRESSION=PASS
FINAL_CLEAN_GENERATED_STATE=PASS

This closed the final clean-checkout gap.

32. Coverage testing strategy

German Braille was not considered complete after a few hand-selected words passed.

A larger deterministic corpus was used.

The audit included:

known source evidence,
original failing paragraph,
a controlled candidate-free paragraph,
known problem words,
ordinary free-text words,
sentences,
and multiple contraction families.

Each case was executed across:

2 regions × 3 German modes

for a six-way matrix.

This helped distinguish two different concepts:

public/free-text translation behavior,
internal source/evidence carriers.

That distinction became important during final closure.

33. Public text versus internal evidence carriers

Some internal specification records contain strings that are not meant to represent normal user-entered text.

Examples can include:

abstract carrier strings,
source notation,
quoted witnesses,
fragments,
policy labels,
or evidence forms.

An early coverage audit treated every one of these records as if it were ordinary Office input.

That produced a large number of “failures.”

The problem was not necessarily the production translator.

The test surface itself was mixing two responsibilities.

The final closure separated them:

Public/free-text surface

Validated through the public SDK translation matrix.

Internal evidence/conformance surface

Validated through Core conformance and regression.

This prevented the project from corrupting runtime semantics simply to make internal evidence strings behave like ordinary user text.

34. Final public free-text closure

The final public free-text matrix covered all six German combinations.

For Germany/Austria:

Basisschrift — PASS
Vollschrift — PASS
Kurzschrift — PASS

For Switzerland:

Basisschrift — PASS
Vollschrift — PASS
Kurzschrift — PASS

with explicit Swiss ß cases retained as expected regional policy rejections.

The key closure condition was:

PUBLIC_UNEXPECTED_FAILURES=0

This is what matters for production translation behavior.

35. Final Core regression

At final closure, the Core regression suite reported:

244 / 244 PASS

This suite includes the German runtime together with the existing Persian Core behavior.

The German implementation therefore did not close by sacrificing the original translation engine.

Cross-language regression preservation was part of the gate.

36. Final SDK regression

The public SDK regression reported:

37 / 37 PASS

This included German public API behavior and existing public translation contracts.

The SDK therefore remained a stable integration boundary after German was added.

37. Final Microsoft 365 regression

The Microsoft 365 suite reported:

102 / 102 PASS

This included German task-pane behavior and the existing host integration safeguards.

The final Microsoft 365 surface therefore passed with German enabled without breaking the previously implemented Persian or Music workflows.

38. Architecture validation

The final Pull Request passed the repository Architecture Validation workflow.

This checks more than compilation.

The architecture workflow validates areas such as:

package boundaries,
repository hygiene,
generated artifact policy,
deterministic runtime preparation,
workspace build,
typecheck,
host contracts,
and clean-checkout reproducibility.

The final German integration passed this gate.

39. Specification validation

The Pull Request also passed the independent Specification Validation workflow.

This separation is deliberate.

Application architecture should not own specification governance.

The two CI concerns remain independent:

Specification Validation
Architecture Validation

Both were green before merge.

40. Pull Request closure

The German Braille feature branch was successfully merged.

The final implementation included several important post-closure fixes:

production German Office integration,
general Vollschrift resolver,
sentence composition,
Kurzschrift safe fallback,
German documentation updates,
generated runtime hygiene correction,
deterministic clean-checkout runtime generation.

After CI passed, the Pull Request was merged and closed.

The remote feature branch was then deleted.

This formally completed the German Braille development phase.

41. Important commits in the final German closure sequence

The final sequence included commits such as:

feat(german): complete German Braille Office integration

fix(ci): exclude generated German runtime artifacts

fix(ci): generate German runtime bundles during build

The last clean-checkout build fix was committed as:

27cb79889fbaa80f6d0479934a5e166b1c9253b8

The branch and remote were verified to be in parity before merge.

42. The role of source provenance

A recurring principle throughout this phase was that German Braille behavior must remain source-backed.

The project does not silently copy behavior from:

legacy code,
a reference implementation,
a comparator,
or an arbitrary online table.

Where source evidence is strong enough, it is encoded into the contract.

Where it is not strong enough, the implementation remains conservative.

That philosophy is particularly visible in:

Vollschrift pronunciation context,
morphology,
Kurzschrift precedence,
Swiss regional behavior.

43. The role of Liblouis

Liblouis was useful as a comparator and implementation reference during the German work.

However, Braille Hub does not use it as a hidden normative production engine.

This distinction matters.

A comparator can reveal:

mismatches,
suspicious cases,
serialization differences,
or areas that need source review.

But comparator output is not automatically treated as normative truth.

The source-backed project specification remains the authority.

44. Why this phase matters beyond German

The most important result of this phase is not merely the addition of a German tab.

German forced the project to prove that its architecture can handle significantly more complex Braille behavior.

Before German, it would have been possible to argue that the architecture worked mainly because the Persian implementation was tailored to one specification family.

German introduced:

three text modes,
regional overlays,
contractions,
lexical context,
pronunciation policy,
morphology,
source-backed exceptions,
sentence composition,
runtime generation,
and larger formal evidence sets.

Successfully integrating all of this through the same Core/SDK architecture is a strong validation of the platform design.

45. Braille Hub after the German phase

At the end of this work, Braille Hub can be summarized as:

Braille Hub
├── Persian Braille
│   ├── Forward translation
│   └── Reverse translation
│
├── German Braille
│   ├── Germany / Austria
│   │   ├── Basisschrift
│   │   ├── Vollschrift
│   │   └── Kurzschrift
│   │
│   └── Switzerland
│       ├── Basisschrift
│       ├── Vollschrift
│       └── Kurzschrift
│
├── English / Latin text support
│
├── Braille Music
│   └── MIDI
│
├── Public SDK
├── CLI
├── Web Playground
└── Microsoft 365
    ├── Word
    ├── Excel
    └── PowerPoint

This is a fundamentally different project from the original Persian Word macro.

46. What was deliberately not claimed

The German phase also maintained several important boundaries.

Braille Hub does not claim that:

every internal source witness is valid user text,
every ambiguous Kurzschrift case has an invented automatic contraction,
Switzerland is a separate German engine,
Liblouis is the normative backend,
generated runtime files are authoritative source documents,
or all future Microsoft platforms are already live-certified.

These limits are documented rather than hidden.

That makes the implementation more trustworthy and easier to extend.

47. What “production functional closure” means here

The phrase production functional closure was used deliberately.

It means that:

the public German translation path is executable,
public free-text behavior is closed,
known host integrations are working,
automated regressions are green,
clean builds are reproducible,
distribution documentation is updated,
and CI accepts the merged implementation.

It does not mean that every possible future linguistic or platform feature has been implemented forever.

Software remains evolvable.

The key point is that the current scope has explicit, passing exit criteria.

48. A note on future language expansion

German is also the first major test of a more general language-expansion model.

A future language should not require:

copy German engine
rename files
change mappings

Instead, future work should reuse the same architectural concepts:

canonical source registry,
language-specific formal contracts,
generated runtime materialization,
Core execution,
SDK projection,
regional configuration where necessary,
conformance,
public consumer integration.

The German phase therefore contributes infrastructure that extends beyond German itself.

49. A note on Microsoft 365 portability

The German translator is already separated from Office.

That matters for future platform work.

The same German Core/SDK is intended to remain unchanged while Microsoft 365 host compatibility expands.

Office-specific future work should focus on:

host behavior,
Office.js capability,
manifests,
browser runtime,
deployment,
and user experience.

It should not require rewriting German Braille semantics.

This is one of the strongest benefits of the current dependency architecture.

50. Final validation summary

The final German Braille closure can be summarized as follows:

German Basisschrift               COMPLETE
German Vollschrift                COMPLETE
General Vollschrift Resolver      COMPLETE
German Kurzschrift                COMPLETE
Swiss Regional Layer              COMPLETE
German Core                       COMPLETE
German Public SDK                 COMPLETE
German Word Integration           COMPLETE
German Excel Integration          COMPLETE
German PowerPoint Integration     COMPLETE
Sentence / Paragraph Composition  COMPLETE
Production UI                     COMPLETE
Public Install Documentation      COMPLETE
Marketplace Metadata              UPDATED
Generated Runtime Pipeline        COMPLETE
Clean Checkout Build              PASS
Architecture Validation           PASS
Specification Validation          PASS
Core Regression                   244 / 244 PASS
SDK Regression                    37 / 37 PASS
Microsoft 365 Regression          102 / 102 PASS
Public German Unexpected Failures 0
Pull Request                      MERGED
German Phase                      CLOSED

51. Closing thoughts

The German Braille phase was one of those engineering tasks that looks straightforward from a distance and becomes much more interesting once the actual rules are implemented.

At the surface, the feature is easy to describe:

“Translate German text to Braille.”

Underneath that sentence are many separate problems:

Which German Braille level is active?
Which region is active?
Is a contraction allowed in this lexical context?
Is pronunciation relevant?
Does morphology change the decision?
Does an abbreviation have special behavior?
Is the input a phrase-level source-backed exception?
Can a sentence be safely segmented?
What happens when the source does not establish a unique Kurzschrift precedence?
How are internal evidence records separated from public user text?
How is the same behavior reused in Word, Excel, and PowerPoint?
How are generated runtimes rebuilt in a clean checkout?
How do we verify that the German feature does not break Persian behavior?
How do we preserve architectural boundaries while adding a substantially more complex language system?

The final solution is not perfect because “perfect forever” is not a meaningful software state.

But it is explicit, tested, source-conscious, reproducible, and extensible.

That is the result that matters.

German Braille is no longer an experimental branch in Braille Hub.

It is now part of the product.

And more importantly, the work has demonstrated that the underlying architecture is capable of evolving from a language-specific accessibility tool into a broader Braille platform.

Technical snapshot

Product:
Braille Hub

German regions:
Deutschland / Österreich
Schweiz

German modes:
Basisschrift
Vollschrift
Kurzschrift

Microsoft 365:
Word
Excel
PowerPoint

Architecture:
Microsoft365 -> Public SDK -> Core

Generated German runtime:
Build-time deterministic
Not tracked in Git

Final test state:
Core          244 / 244 PASS
SDK            37 / 37 PASS
Microsoft365  102 / 102 PASS

CI:
Architecture Validation   PASS
Specification Validation  PASS

Status:
German Braille phase merged and closed

Repository

Braille Hub / Persian-to-Braille:

https://github.com/soroushneyestani/Persian-to-Braille

End of German Braille phase communication pack.