Octgram 的内置翻译是如何实现的

Octgram 的翻译功能看似“一键翻译”，实则是多层协同的结果。每一次长按消息弹出的翻译框，背后都有一段网络请求、语言检测与本地缓存的链路在悄悄运转。

技术栈概览

客户端整体采用 Kotlin + Coroutines，网络层基于 Retrofit + OkHttp，JSON 解析使用 Moshi。语言检测则交给 Google ML Kit 的 on‑device 模型，翻译服务默认调用 DeepL 免费 API，用户可在设置中切换至自建翻译服务器。

消息拦截与语言检测

当用户在聊天窗口长按一条文本时，Octgram 会先捕获该 Message 对象的原始文字，然后在 UI 线程之外启动一次协程，调用本地的语言检测模型。

• 提取文字并去除 Telegram 表情占位符。
• 使用 ML Kit 判断文本主语言，返回 ISO‑639‑1 码。
• 若检测结果为用户首选语言，直接弹出“已是目标语言”提示。

调用翻译服务

检测到需要翻译后，Octgram 会组装一个标准的 REST 请求：POST https://api.deepl.com/v2/translate，携带 auth_key、text、target_lang 等参数。为了兼顾响应速度和流量消耗，OkHttp 配置了 5 秒的连接超时与 10 秒的读取超时，并开启了 HTTP/2 多路复用。

interface TranslationApi {
    @FormUrlEncoded
    @POST("v2/translate")
    suspend fun translate(@Field("auth_key") key: String,
        @Field("text") text: String,
        @Field("target_lang") target: String
    ): DeepLResponse
}

缓存与离线支持

返回的译文会写入 Room 数据库，键值为原文 + 目标语言的哈希。下次相同请求命中缓存，直接读取本地记录，省去网络往返。对于网络全失效的场景，Octgram 会退回到 ML Kit 自带的离线翻译模型，虽然词库不如 DeepL 完整，却足以应付日常对话。

“我们最怕的不是翻译不准，而是用户在等待时产生的焦虑。”——Octgram 开发者日志

整体来看，Octgram 把“翻译”这件事拆解成检测、请求、缓存三段式流水线，既保证了响应速度，也让用户的每一次长按都像是一次细致的语言实验。