Persian language pack: 240 translations and RTL support for DSH Web

[MiRHaDi]

I am sharing dsh-persian-rtl, an independent community Persian language pack, through the plugin route recommended in CONTRIBUTING.

Repository: https://github.com/MiRHaDi/dsh-persian-rtl

Installable release: https://github.com/MiRHaDi/dsh-persian-rtl/releases/tag/v0.1.0

The motivation is accessibility for Persian speakers and readable mixed Persian/English output. The pack registers fa through the documented ctx.locale.addLanguage and per-locale dictionary APIs, with English fallback. It currently covers 240 strings in six namespaces: common, settings.locale, sidebar, settings, workspace and chat. The rest of the application remains English; this is not a full-app translation.

When Persian is selected, the document becomes RTL. Code, terminal and editor containers remain LTR, and paragraph/textarea text uses unicode-bidi: plaintext. Language changes and unloading release the owned registrations, subscription and stylesheet and restore the prior document direction.

Validation: six automated tests against the published LocaleRuntime from 0.1.6-alpha.2, exact key/placeholder checks against source revision ddefc45fbc7f8e46dd73185e68295696d1297887, actual tarball installation through dsh plugin, and real Web settings switching fa → en → fa using headless installed Chrome 153.0.8010.52 on Windows, with zero page errors. Code/editor CSS was checked with temporary fixtures in that live instance. Full model conversation execution and every viewport were not tested.

The code and translations were prepared with AI assistance; test coverage and remaining limits are documented in the repository. Persian speaker review and feedback on the external language-pack integration are welcome. I would like to maintain this pack and expand its coverage as the APIs settle. Is there a preferred convention for language-pack ownership of document direction, especially when multiple RTL packs are installed?

[unera]

Related proposal, may matter for how this one ships: make the UI locale an ordered preference list (e.g. ru → en → zh) instead of a single choice, so a partly translated UI falls back to a language the user actually reads rather than to untranslated islands and Chinese source keys. It also keeps the shipped-locale set from being a closed enum.

Details and a link list of the other language threads: #11699