The name Persian-to-Braille reflects where the project began, but the architecture of version 2 has grown beyond a single-language converter.
One of the clearest examples is the Persian / English text workflow.
Persian-to-Braille v2 can process Latin and English text through the same reusable translation architecture that powers its Persian Braille functionality. The result is a unified text surface rather than a collection of unrelated converters.
The current English capability focuses on uncontracted six-dot Braille for Latin text and mixed Persian/Latin content.
This distinction is important: the project does not currently claim full UEB Grade 2 or contracted English Braille compliance. Instead, it exposes the English/Latin behavior that is actually implemented and validated by the current profile.
Why English support belongs in this project
In real documents, Persian rarely exists in isolation.
Technical documents, academic text, emails, spreadsheets, presentations and administrative material frequently mix Persian with:
- English words;
- product names;
- URLs;
- acronyms;
- programming identifiers;
- Latin numbers and punctuation;
- technical terminology.
A Persian Braille engine that fails as soon as a Latin span appears is not sufficient for modern documents.
Persian-to-Braille v2 therefore treats Latin/English spans as part of the translation problem rather than as content that should be ignored, removed, or passed through visually.
One shared translation surface
In the Microsoft 365 integration, the primary text tab is now presented as:
Persian / English
The same surface is used for both Persian text and supported Latin/English spans.
This is more than a label change. It reflects the actual architecture of the translation pipeline.
The Office host does not contain a separate table of English Braille characters. Instead, selected text is passed through the public SDK and the active specification-driven translation behavior.
The architectural boundary is:
Microsoft Word / Excel / PowerPoint
↓
Public SDK
↓
Core + specification
↓
Unicode Braille
This keeps translation semantics out of application-specific code.
Microsoft Word
In Microsoft Word, the user can select text and generate a Braille preview through the shared Persian / English workflow.
The translated result can then be copied, used to replace the selected source text, or inserted according to the supported Word workflow.
Because Word consumes the SDK instead of implementing its own translation table, the same text semantics remain available to other applications.
Microsoft Excel
Excel uses the same SDK boundary for cell-based translation.
The host layer is responsible for Excel-specific concerns such as reading the selected cell, checking the supported runtime, guarding against stale selections, and writing the final value.
It does not redefine the Braille rules.
This separation is important because spreadsheet integration should not become a second translation engine.
Microsoft PowerPoint
PowerPoint follows the same model.
Selected text is read from the presentation, translated through the SDK, and written back only through the host adapter.
Again, the application-specific layer deals with PowerPoint; the Braille semantics remain in the shared engine.
Mixed Persian and Latin content
One of the practical benefits of the unified architecture is support for documents that contain both Persian and Latin text.
Modern Persian documents frequently contain English technical terminology, abbreviations, names, file paths, software identifiers, websites or other Latin content.
The translation pipeline can preserve the distinction between Persian and Latin spans while keeping the output inside one deterministic Braille process.
This is especially useful for technical and educational material, where forcing a user to split every mixed-language paragraph manually would make the workflow unnecessarily difficult.
What “English Braille” means in the current release
Accuracy in terminology matters.
The current capability should be described as:
English/Latin text to uncontracted six-dot Braille
It should not be described as full contracted English Braille or as UEB Grade 2 compliance.
Contracted Braille introduces additional linguistic rules, word-level contractions, context-sensitive behavior and a separate conformance surface.
Persian-to-Braille v2 deliberately avoids claiming support for standards that have not yet been formally implemented and validated.
That is part of the project's wider engineering philosophy: capabilities should be explicit, testable and auditable.
Specification-driven behavior
Persian-to-Braille v2 is built around formal translation specifications rather than ad-hoc mappings embedded inside user interfaces.
The current Persian profile contains character, context, layout, mode, normalization and sequence rules.
Latin spans are handled within that specification-driven execution model.
This means future expansion does not require rewriting each application independently. A change in the translation specification or engine can be validated once and consumed consistently through the SDK.
Public SDK
English/Latin translation is also available through the public TypeScript SDK.
The SDK acts as the stable consumer-facing boundary of the platform.
Applications should depend on the SDK instead of importing internal Core implementation details.
This gives third-party developers a cleaner integration path and allows the internal translation engine to evolve without unnecessarily exposing its architecture.
Part of a broader Braille platform
The English capability is best understood in the context of the larger Persian-to-Braille v2 redesign.
The project now includes:
- formal Persian Braille specification artifacts;
- deterministic normalization;
- a standalone Core engine;
- a public SDK;
- Word, Excel and PowerPoint host integrations;
- reverse-translation foundations;
- a dedicated Braille Music package;
- MIDI-to-Music-Braille processing;
- Unicode and BRF-oriented workflows;
- architecture and conformance validators;
- isolated package-consumer validation.
The result is a project that is gradually moving from “a Persian Braille converter” toward “a reusable Braille software platform”.
Why the distinction matters
For accessibility software, it is tempting to market every supported character set as complete language support.
Persian-to-Braille takes a stricter approach.
If the implementation supports uncontracted six-dot English, that is exactly what the project says. If a future version implements and validates UEB Grade 2, that capability can be announced separately with its own specification and conformance evidence.
This makes the platform easier to trust because the technical scope is visible.
Open-source and extensible
Persian-to-Braille v2 is released under the MIT License.
Its Core, SDK and surrounding architecture are intentionally designed so that additional applications and future language profiles can be built without coupling them to Microsoft Office.
The current English/Latin support is therefore both a useful capability today and an architectural proof that the platform can grow beyond its original Persian-only boundaries.
What began as Persian-to-Braille is becoming a broader Braille infrastructure project — one reusable, testable capability at a time.
