Automatic language translation

[ValwareIRC]

Automatic Language Translation

Provide an IRC-side facility for defining a user-set language and translating incoming messages to that language.

Why on IRC?

Sheer convenience and optimization. What do I mean?

What's better?

When served over IRC we send a single translation to all appropriate users and we don't need to cache, very lightweight and effective.

The alternative

An HTTP endpoint via backend, we'd have to translate and cache each translation and serve it multiple times to whoever requested it, increasing server load, not optimal for large channels using translation features and might inadvertently result in a self-DDoS on busy servers on light hardware.

[louzt]

While #101 is still fundamentally an IRC-side/server-side feature request, I have been prototyping two separate client-side tracks so the concerns do not get conflated.

1. An experimental browser-native path using the Translator API as progressive enhancement only. It is gated behind feature detection, secure context, and explicit user action, and it keeps the original message as the source of truth. Because it is purely client-side, I am not presenting it as a direct implementation of Automatic language translation #101.

2. A separate adapter/fallback track for self-hosted translation backends such as LibreTranslate or Argos-style deployments, so privacy-first local translation and network-backed adapters can be evaluated independently.

The browser-native path is based on the platform API documented here:
https://developer.mozilla.org/en-US/docs/Web/API/Translator

That keeps the client-side experiment aligned with a web standard instead of a vendor-specific integration, while still leaving room for a separate adapter boundary if a self-hosted fallback is preferred.

If that split sounds useful, I can open them as two small PRs:

• one for the client-side progressive enhancement already wired into the message action flow
• one for an adapter-oriented fallback branch/interface

That should make it easier to review each direction on its own merits without mixing the IRC-side goal of #101 with an optional client-side enhancement.

[louzt]

Following up with the split review paths mentioned above, both branches are now open as PRs:

• Client-side progressive enhancement: Feat: Browser-native message translation (distinct from UI localization) #173
• Adapter/self-hosted backend boundary: Add translation adapter interface for self-hosted backends #174

The intent is to let these be reviewed independently:

• PR Feat: Browser-native message translation (distinct from UI localization) #173 is the browser-native path using the Translator API as optional client-side progressive enhancement.
• PR Add translation adapter interface for self-hosted backends #174 is the infrastructure path for a swappable translation driver, starting with a LibreTranslate adapter boundary for self-hosted/fallback use cases.

That way the IRC-side goal of #101 does not get conflated with either a browser-local enhancement or a backend adapter abstraction.

[louzt]

Quick tracking update after the latest round of hardening/splitting, so the implementation paths stay easy to reason about:

• feat/i18n #171 remains the UI localization / dictionary track (Lingui, static app text).
• Feat: Browser-native message translation (distinct from UI localization) #173 is the browser-native client-side message translation path only, using the platform Translator / LanguageDetector APIs as progressive enhancement.
• Add translation adapter interface for self-hosted backends #174 is the adapter boundary for self-hosted/network-backed translation backends.
• fix: harden IRCv3 tag parsing and multiline protocol helpers #175 is a separate IRCv3 protocol/helper hardening PR extracted from the translation branch so lower-level tag/multiline correctness can be reviewed independently.

A few points that may help reduce concern about the browser-native branch:

1. It is still not claiming to implement Automatic language translation #101 end-to-end.
   Automatic language translation #101 is fundamentally an IRC-side / server-side facility request. The browser-native path is intentionally local-only and optional.

2. The browser-native branch now has narrower runtime hardening than when first opened.
   It now guards against stale async translation runs, avoids treating low-confidence / und detector results as valid source languages, and treats very short text as unreliable for detection.

3. There is a clean separation between protocol substrate and feature branch now.
   After the latest split, generic IRCv3 helper fixes (message-tag parsing, ISUPPORT value preservation, multiline byte-splitting, spec-compliant batch ids, etc.) live in fix: harden IRCv3 tag parsing and multiline protocol helpers #175 instead of inflating the feature branch.

4. Valerie's messageProtocol.ts fix on main was exactly the kind of protocol groundwork this needed.
   The batch-id underscore -> hyphen fix aligns with IRCv3 batch expectations, and the whitespace preservation fix avoids breaking draft/multiline-concat behavior.

5. feat/i18n #171 and Feat: Browser-native message translation (distinct from UI localization) #173 are complementary, not competing.
   feat/i18n #171 makes the UI translatable/localizable. Feat: Browser-native message translation (distinct from UI localization) #173 makes message content optionally translatable on demand. If feat/i18n #171 lands first, the new translation-related UI strings introduced in Feat: Browser-native message translation (distinct from UI localization) #173 can be moved through the Lingui path as a follow-up without changing the underlying browser-native architecture.

So at this point the structure is intentionally:

• feat/i18n #171 = UI localization
• Feat: Browser-native message translation (distinct from UI localization) #173 = browser-native local message translation
• Add translation adapter interface for self-hosted backends #174 = backend/self-hosted translation adapter boundary
• fix: harden IRCv3 tag parsing and multiline protocol helpers #175 = generic IRCv3 protocol/helper correctness improvements extracted from Feat: Browser-native message translation (distinct from UI localization) #173

That keeps this issue focused on the original server-side goal while still documenting the client-side experiments and the protocol hardening that spun out around them.

[louzt]

Following up on the split discussed here, I added a small deployment-oriented note for the self-hosted path as well:

• Browser-native progressive enhancement: Feat: Browser-native message translation (distinct from UI localization) #173
• Self-hosted adapter boundary: Add translation adapter interface for self-hosted backends #174
• IRCv3 helper/protocol hardening: fix: harden IRCv3 tag parsing and multiline protocol helpers #175
• Deployment follow-up note (LibreTranslate / reverse proxy / Docker): https://gist.github.com/louzt/d12a4fa925446630290c0e1171ea6131

The intent of that note is to make the review boundary clearer:

• Feat: Browser-native message translation (distinct from UI localization) #173 still does not claim to implement IRC-side translation
• Add translation adapter interface for self-hosted backends #174 / fix: harden IRCv3 tag parsing and multiline protocol helpers #175 make it easier to evaluate a self-hosted backend path without reworking the client interaction model again
• issue Automatic language translation #101 remains the right place for any true IRC-side/server-side design that would translate once for multiple recipients at the network layer

So the browser-native path, the adapter seam, and the protocol hardening are all being kept reviewable as separate pieces, while still leaving a concrete operational path for maintainers who prefer a Docker/self-hosted deployment experiment first.