在 Solana RPC 这类开发基础设施的日常运维中，开发者实际花在 Dashboard 上的时间往往超出预期。对比 plans、获取 API key、配置 endpoint、监控使用情况、阅读错误信息、撰写支持工单 --- 每一个画面都需要做判断，而如果这些画面只有非母语版本，认知负担就会以"心智翻译"的形式持续消耗注意力。本文从国际化（i18n / localization）的角度，记录 ERPC 平台将官方网站与 Dashboard 整体扩展至 16 种语言的工程实践，以及在开发者体验（DX）上做出的设计选择。
为什么基础设施工具的 i18n 值得认真做
在选择和运营 Solana RPC 时，开发者会重复执行以下操作：对比 plans、选择 region、处理 API key、配置 endpoint、解读使用指标、处理错误信息、提交支持请求。这些操作本身并不复杂，但每个操作都要求阅读 UI 文案并据此做判断。当 UI 只提供单一语言（通常是英语）时，非母语用户需要在阅读---翻译---判断这条链路上额外消耗一段心智资源。对短任务来说几乎不可察觉，但叠加到一整天的运维工作上，差异会显现为"配置变更迭代速度"和"出错时的恢复时间"。
平台响应速度、与 Solana 网络的物理距离、服务器位置、网络路由 --- 这是"基础设施侧的速度"。而能否在母语环境下顺畅完成访问该速度所需的配置 --- 这是"工具侧的易用性"。两者属于同一种工程问题：减少开发者执行任务时不必要的摩擦。本次 i18n 扩展，就是把"工具侧的易用性"按同等优先级处理的一步。
覆盖范围：16 种语言、全平台、单一切换器
本次更新覆盖的语言：英语、日语、简体中文、繁体中文、俄语、韩语、越南语、泰语、印尼语、印地语、土耳其语、荷兰语、德语、法语、西班牙语、葡萄牙语。
覆盖的界面范围：官方网站（erpc.global）的全部产品页面，包括 Solana RPC plans、WebSocket、Geyser gRPC、Shredstream、Direct UDP Stream、VPS、裸金属服务器、SWQoS、兼容 Pyth 的 Price API、Jet Analytics & Indexed RPC；以及 Dashboard（dashboard.erpc.global）内部的 plan 选择、API key 管理、endpoint 获取、使用监控、计费切换（年付 / 月付 / 小时计费）、Auto top-up 配置、支持工单创建与对话线程。
语言选择器统一放置在每个画面顶部，登录前的页面和 Dashboard 内部均可使用。开发者可以在任意时机切换语言而不丢失上下文状态。无需重新登录、无需变更账户设置、无需新签 plan 或修改合约。
工程上需要解决的几类问题
将一个 Dashboard 扩展到 16 种语言，技术上需要面对的不只是"把英文 string 翻译成对应语言"。以下几类问题在实际开发中需要单独处理：
第一类是术语一致性。Dashboard 的语境涉及多个术语层 --- plan 用语（plan、tier、quota）、API 用语（endpoint、API key、rate limit）、运营用语（region、latency、uptime）、计费用语（hourly billing、auto top-up、credit）、支持用语（ticket、thread、status）。同一个英文词在不同语境下可能需要不同的母语翻译，且整个产品内必须保持对应关系稳定。为此各语言都建立了术语对照表，并在 UI 文案、错误信息、支持文档之间做交叉校验。
第二类是行动呼吁（CTA）的对仗。"Create"、"Configure"、"Submit"、"Apply"、"Save"、"Cancel" 这些动词在英语中靠语境区分，但翻译时需要保持每种语言内部的对仗关系，否则 Dashboard 会出现"看似不一致"的违和感。每种语言的 CTA 标签都按动词族整理，避免同一动作在不同画面用不同译法。
第三类是错误状态的可执行性。出错时显示的文案不只是描述"发生了什么"，更要提示"下一步可以做什么"。母语翻译需要保持这种可执行结构 --- 不是简单地把英文错误信息直译，而是按每种语言的自然表达重写，使读者在母语环境下也能立即识别下一步动作。
第四类是 Dashboard 内的通知与 toast。这部分文案出现频率高、字数短，但对于"操作是否成功"的反馈直接依赖它们。每种语言的 toast 文案都按短促、明确、对仗的标准打磨，避免长句和模糊表达。
评估阶段的 i18n：让对比与判断在母语下完成
对首次评估 ERPC 的团队来说，i18n 的价值在评估阶段就开始体现。Solana RPC、WebSocket、Geyser gRPC、Shredstream、Direct UDP Stream、VPS、裸金属服务器的各产品页面，包括方法支持表、可用 region、计费结构、运营特性，都以 16 种语言提供。
在评估阶段以母语接收信息，会直接影响决策的速度与精度。逐个翻译技术术语的心智成本降低后，注意力可以集中在判断标准本身 --- 这个 plan 是否覆盖所需的 method、region 是否与目标用户群匹配、计费结构是否与预期负载吻合。对现有用户来说，新功能页面和定价公告以母语阅读，也更容易判断是否将其引入当前配置。
运营阶段的 i18n：Dashboard 全流程母语化
进入运营阶段后，Dashboard 上的所有交互都已母语化：plan 对比画面上的标签、订购确认时的文案、配置过程中的错误信息、使用画面上的指标说明、创建支持工单时的输入字段、Dashboard 内部的通知与 toast。
对运维团队来说，Dashboard 是日常使用频率最高的工具之一。能够以母语完成"订购 → 配置 → 监控 → 调整 → 支持"这条完整链路，意味着运维流程的迭代成本可以下降。配置变更不再需要先翻译再决策，使用监控指标可以直接阅读，支持工单可以用日常使用的语言描述问题并跟进。
支持工单的母语化
支持工单同样以 16 种语言提供。开发者可以在 Dashboard 内的 Support 画面以母语打开工单，整个对话过程保持同一语言环境。表单字段、工单列表、对话线程、状态指示器、通知都已本地化。
技术问题的描述精度往往与母语熟练度直接相关 --- 复杂的配置问题、错误现象的复现步骤、约束条件的说明，在母语下能够更精确地表达。这一点对于解决问题的效率影响显著。
新闻与公告的同步发布
ERPC 的新闻稿与更新公告，目前以全部 16 种语言并行发布。新功能、定价更新、运营通知与技术新增内容都可以以母语阅读。运营方向、新功能背后的设计意图、定价结构的依据、技术选型的理由 --- 这些上下文以母语接收比仅看英文原稿更容易吸收，让全球开发者基于相同的底层上下文使用平台。
在合适的位置只取所需的资源、只用所需的用量
ERPC 的产品设计前提是：每个 Solana 应用都有不同的理想配置。Solana RPC、WebSocket、Geyser gRPC、Shredstream、Direct UDP Stream、VPS、裸金属服务器、SWQoS、兼容 Pyth 的 Price API、Jet Analytics & Indexed RPC、年付 / 月付 / 小时计费、Auto top-up --- 都是为了在合适的位置只取所需的资源、只用所需的用量。
随着可选项的增加，评估和配置它们的成本也会随之上升。i18n 的作用是防止"丰富的选项"在实际操作中演变为"难以驾驭的复杂度"。能够以母语对比和配置这些选项，是保持配置广度同时维持操作便利性的基础。
与 Solana 网络的零距离通信 + 平台整体的母语体验
ERPC 是为追求与 Solana 网络的零距离（最小延迟）通信、并通过整体平台优化达成极致速度而设计的 Solana 专用基础设施。HTTP RPC、WebSocket、Geyser gRPC、Shredstream、Direct UDP Stream、SWQoS、服务器位置、validator 质量、网络路由、处理节点性能，以及横跨官方网站与 Dashboard 的开发者体验，作为单一一体化系统持续改进。
ELSOUL LABO 自 2022 年起连续五年获得荷兰政府 WBSO 研究开发支持计划批准，持续推进 Solana RPC 基础设施、validator 运营、实时数据分发、历史数据获取、基于 AI agents 的运营与开发支持，以及平台整体多语言用户体验等方向的研究开发。本次 16 种语言扩展，将这些研究成果以"全球开发者都可在母语下操作"的形式交付。
平台速度直接关系到 Solana 应用的执行品质、可捕捉的交易机会、终端用户的体验以及运营的稳定性；与之配套的母语 Dashboard，则降低了访问这种速度所需的配置、迭代和支持成本。两者以同等优先级推进，是这次更新的核心。