语言与从右到左

Gitcito 的界面是翻译过的。语言是 Gitcito 自己的设置，不是操作系统的设置——一个 用着英文 macOS、却更想读日文的开发者可以在这里改，而一个用希伯来语系统、偏偏想让 应用说英文的开发者，也不会被系统替他做主。

设置 → 通用 → 语言。

都包含哪些

选择器里的每一行都用它自己的语言写成。找韩语的人，眼睛在扫的是 한국어，而不是 「Korean」这个词——那可是他正想离开的那门语言写的。

关于那些国旗

国旗指的是国家，区域设置指的是语言。这两者是真的对不上——阿拉伯语在二十多个国家 都是官方语言，葡萄牙语横跨两个大洲。这些图标遵循的是每个操作系统的语言选择器都 在用的那套惯例：取该区域设置的主要地区。它们的存在是为了让人一眼认出来，而不是 在主张某门语言归谁所有。

它们是特意画成矢量图形而不是用 emoji 的。Windows 根本就不带国旗 emoji——🇩🇪 在那里渲染出来是一个方框，里面装着「DE」两个字母。

从右到左

阿拉伯语和希伯来语会把整个界面镜像过来：侧边栏挪到右边，面板和工具栏翻转，有 指向性的图标也改指另一边。

切换是即时的，不需要重启。

哪些是故意不镜像的

无论你读的是哪门语言，有些内容始终是从左到右的。把它们镜像过来是实打实的错误， 所以这些保持原样：

这里面的每一项都做了隔离，所以其中内部出现的一段阿拉伯语——一个分支名、一条 提交消息、一个文件名——都不会把它周围的文本顺序搅乱。

局限

这一节老老实实地说明它到哪儿为止：

• 提交消息、分支名和文件内容，Gitcito 从不给它们改方向。 它们按作者写下的 样子原样呈现。一条希伯来语的提交消息，在一个做了从左到右隔离的列表里就渲染成 希伯来语，但它所在的那一行不会为了迁就它而翻转。
• 第三方界面保留它们自己的方向——终端是 xterm，Markdown 预览按文档原样渲染。
• 方向混排的文件名很难办。 一条路径里，英文目录树中夹着一个阿拉伯语文件夹， 处理方式是隔离而不是重排，这么做是对的，但第一次看到时仍然可能让人一愣。

这本手册也翻译了

不只是按钮。你正在读的每一页，上面那份列表里的每一门语言都有——那些解释、那些说明 每个选项做什么的表格、那些讲清楚某个功能拒绝做什么的小节，都在。切换界面语言，手册 也跟着一起切换，应用里和网站上都一样。

翻译可以是不完整的。如果某一页还没翻译，你拿到的是英文那一份，而不是一个缺失的页面； 侧边栏在每门语言里都保持同样的结构，所以一张截图或一条操作说明仍然对得上你看到的 界面。

网站上每一页都带着语言切换器，它会把你留在你正在读的那一页，因为换语言不等于从头 开始。

哪些是机器翻译的，代价又是什么。 英文和西班牙文是手写的。其余的由模型对着一份 术语表翻译，然后由脚本核对：每一页、每一个链接、每一条图片路径、每一个代码块，都逐 字节和英文比对。这能查出结构上的破损，查不出一个正确但生硬的句子。如果某一页在你的 语言里读着别扭，那就是一个值得报告的缺陷。

添加一门语言

字典位于 src/renderer/src/i18n/ 下，一个区域设置一个文件，而英文那份是所有其他 文件做类型检查时的参照——少一个键就是编译错误，而不是悄悄回退成英文。测试套件还会 检查一个字符串插值用到的每一个 {placeholder} 都在翻译中活了下来，所以一句话不会 在进入另一门语言的路上把它的提交 sha 弄丢。

手册也是同样的做法：docs/help/ 放英文页面，docs/help/<locale>/ 放各语言的翻译， 一页一个文件，文件名相同。npm run lint:docs 会检查每个翻译页面都有对应的英文原文、 它的 front matter 是否完整，以及它的链接和图片能否从深一层目录正确解析。

欢迎贡献——一次一页完全可以，而把一句别扭的翻译改顺，和补上一页缺失的翻译一样有 价值。

另请参阅： 主题与外观 · 配置档