From 8b385aa4630dcadabb6390dced98202e273ee317 Mon Sep 17 00:00:00 2001 From: Eltrac Date: Fri, 20 Jun 2025 22:46:52 +0800 Subject: docs: move drafts to correct directory and post new article --- ...260\203\345\272\246\347\256\227\346\263\225.md" | 194 ++++++++++++++++++++ ...257\221\350\200\205\347\264\240\345\205\273.md" | 199 +++++++++++++++++++++ 2 files changed, 393 insertions(+) create mode 100644 "content/posts/\344\270\200\344\270\252\347\224\265\346\242\257\350\260\203\345\272\246\347\256\227\346\263\225.md" create mode 100644 "content/posts/\347\234\213\345\212\250\347\224\273\347\211\207\345\246\202\344\275\225\345\270\256\346\210\221\346\217\220\345\215\207\350\257\221\350\200\205\347\264\240\345\205\273.md" (limited to 'content/posts') diff --git "a/content/posts/\344\270\200\344\270\252\347\224\265\346\242\257\350\260\203\345\272\246\347\256\227\346\263\225.md" "b/content/posts/\344\270\200\344\270\252\347\224\265\346\242\257\350\260\203\345\272\246\347\256\227\346\263\225.md" new file mode 100644 index 00000000..8b3d9e04 --- /dev/null +++ "b/content/posts/\344\270\200\344\270\252\347\224\265\346\242\257\350\260\203\345\272\246\347\256\227\346\263\225.md" @@ -0,0 +1,194 @@ +--- +title: 一个电梯调度算法 +subtitle: +tags: + - 计算机 + - 算法 +related_cards: +mentioned_books: +date: 2025-06-13T23:19:00 +categories: +banner: +draft: true +toc: true +--- + +作为一个程序员，我在博客上写的技术文章还是太少了，原因大概有两个：一是自己的技术水平还不足以产出太多原创内容；二是觉得计算机领域的知识很难写成所有人都能读懂的文章——总之就是，不想写枯燥的操作教程，也不想在博客上复制粘贴代码。不过最近倒是有了一些可以成文的想法。 + +[搬家](/posts/逃离群居生活/)之后，我每天都要乘电梯。尽管公寓楼的人流量比较小，基本不会出现与其他使用者争夺电梯资源的情况，但就算是这样，楼栋的电梯调度方式依然让我感到迷惑。这几天我一直尝试搞清楚电梯的运作模式，想着能不能用伪代码的方式表示出来，甚至做一些改进。好巧不巧，最近关注的一个博主就发了一篇有关电梯交互和调度算法的[文章](https://blog.codingnow.com/2025/06/elevator.html)，我了解到**几乎每一个需要乘电梯上班的程序员都思考过这个问题**，还挺奇妙的。 + +## 用户如何与电梯交互 + +回想一般坐电梯的过程：在某一层按下电梯按钮——电梯来到你所在的楼层——进入电梯后按下楼层按键——电梯带你前往你想要前往的楼层——你走出电梯，结束。 + +先把乘坐电梯的人都抽象为用户（`User`），电梯就表示为 `Elevator`，方便之后的描述。在上述交互过程中，用户会向系统输入两个指令： + +1. 在进入电梯前按下按钮，表示自己需要**向上**还是**向上** +2. 在进入电梯后按下按钮，表示自己需要去**哪一层** + +将第一个指令命名为 `Direction`，第二个指令命名为 `Destination` 或 `to`。除了这两个输入，影响电梯行为的其实还有用户所在的楼层，命名为 `Location` 或 `from`，也作为输入的一部分传给电梯的相关模块。 + +表示为伪代码： + +```javascript +user.getDirection() +user.getDestination() +user.getLocation() +``` + +电梯的交互逻辑就是这样。[云风](https://blog.codingnow.com/2025/06/elevator.html)在他的文章中提出可以用「召唤按钮」代替常见的上和下两个按键，这个可以先搁在一边，回头再看看。 + +电梯的调度算法就需要处理这三个输入，然后确定电梯的移动方式，即向上移动还是向下移动，途中在哪个楼层停下并开门。电梯本身的属性也要考虑到，包括电梯目前所在的楼层、是否可以移动（故障、超载或厢门未关闭时不能移动）。 + +```javascript +elevator.getCurrentFloor() +elevator.isMovable() +``` + +如果电梯正在响应一个用户的请求时收到了另一个用户的请求，应该先完成上一个用户的请求，还是想办法同时满足两个用户的请求，也是需要考虑的问题。同样地，这个问题先放一放，先实现基本的逻辑再说。 + +## 单用户单电梯的情况 + +调度电梯就是决定电梯如何移动，在何时调用哪一部电梯的过程。对于单部电梯来说，调度过程分为两步，也就是接和送。 + +### 接 + +假设电梯有一个 `move()` 方法，输入正数向上移动一定楼层，输入负数向下移动一定楼层。要移动到用户所在的楼层，就可以简单地表示为： + +```javascript +elevator.move(user.getLocation() - elevator.getCurrentFloor()) + +// 这显然可以封装为一个单独的函数 +elevator.moveTo = (location) => { + this.move(location - this.getCurrentFloor()) +} +``` + +使用 `moveTo()` 方法的时候就不需要再考虑电梯当前所在的位置了，因为已经被封装好了。这么看来，在单用户的情况下，单个「召唤按钮」的方案的确可以代替上和下两个按钮的方案，当用户按下按钮，只需要执行 `elevator.moveTo(user.getLocation())` 就可以了，在算法层面完全不需要考虑用户在一开始按的是向上还是向下。 + +### 送 + +送的步骤也很简单，用户进入电梯并输入目的地后，只需要执行： + +```javascript +elevator.moveTo(user.getDestination()) +``` + +似乎讲了一堆废话，单用户单电梯的情况就是很简单嘛！ + +## 单用户多电梯调度 + +这更贴近我的情况，我每天都在乘电梯的时候好奇：为什么我按下了左边的电梯，响应请求的却是另一部电梯？明明左边那部电梯离我更近。 + +虽然看起来每部电梯都有各自的物理按键，但两部电梯的控制是相通的。在算法层面，用户与两部电梯是同时交互的，而不是单独地给一部电梯下达了命令。我认为这是合理的，如果有一部电梯更近，而用户按了更远的那一部，或者如果用户按下的那一部电梯正在被使用，而另一部是空闲的，让用户独立操作某一部电梯就不是什么好事。 + +总而言之，在不止一部电梯的情况下，我们依然只需要考虑单一的输入。 + +### 接 + +在有多部电梯的情况下，只需要调度一部电梯接送用户。为了最小化用户的等待时间，提高效率，选择距离用户最近的电梯就是最佳方案。由于我们正在考虑单用户的情况，所以不存在电梯繁忙、正在运送其他用户的情况。 + +这时就不能直接让 `elevator` 对象响应请求了，可能需要一个额外的电梯调度器（`elevatorScheduler`）决定让那一部电梯前去接送用户。这个调度器应该能够访问系统中所有的电梯，对比他们与用户的距离，然后派遣最近的那部电梯。 + +```javascript +// in 'elevatorScheduler' +const elevators = this.getElevatorArray() +const userLocation = user.getLocation() + +let closestElevator = null + +for (let elevator of elevators) { + const thisDistance = userLocation - elevator.getCurrentFloor() + const closetDistance = userLocation - closestElevator.getCurrentFloor() + + if (!closestElevator || cloestDistance > thisDistance) { + closestElevator = elevator + } +} + +closestElevator.moveTo(userLocation) +``` + +### 送 + +由于接到用户之后，任务就完全交给其中一部电梯了，其他电梯则不需要考虑。所以送的步骤还是和「单用户单电梯的情况」相同，在此不赘述。 + +## 多用户单电梯调度 + +我记得有一次出门，我和家人忙忙慌慌地收拾东西，把电梯一直占着，过了好久我们才下楼，走出电梯门的时候发现楼下有两个人已经不耐烦到坐在地上刷手机了，愧疚感顿时涌上心头。用户不止一个，而资源访问是互斥的，就会出现这种情况（好在电梯应该不会有死锁问题）。 + +电梯显然不能及时响应每一个用户的请求，当一个用户正在占用资源时，就不得不等待另一个用户释放资源。不过，电梯如何才算被占用呢？事实上，只有电梯厢门打开或准备打开时才算被占用，因为电梯在接和送的过程其实都可以停靠。比如，有人从一楼前往五楼，而我打算从三楼前往四楼；当电梯正在从一楼向上移动时，我在三楼按下按钮，电梯理应响应我的请求，在三楼停下打开门；当我进入电梯按下四楼按钮，它也理应在四楼停下开门让我出去，然后再送另一个用户去五楼。 + +在多用户的情况下，单个「召唤按钮」的模式就不那么好用了。还是那个例子，当有人从一楼前往五楼，我依然在三楼，但我打算下行前往一楼。这个时候，电梯不应该给我开门，应该在送完去五楼的用户之后返回时再给我开门。如果没有上行和下行按钮的区分，电梯就无法在接送时确定要不要响应用户请求，以及何时响应用户请求。 + +为什么不能在另一个用户前往五楼的时候开门，让需要下楼的我乘坐电梯呢？毕竟只要等前一个人到达目的地，电梯再响应我的请求就好了。问题在于，电梯停考和开门的过程，为了保证停靠平稳，不会出现安全问题，耗费的时间是很长的，在中途给我开门会增加其他用户的等待时间。 + +尽管电梯的上下按键可能会让人感到困惑，搞不清楚「上」指的是用户想要往上走，还是命令电梯向上运行，但这个操作逻辑在习惯之后是可以变得符合直觉的。相反，如果没有上下按键的区分，用户可能不会明白电梯为什么不响应自己的请求，自己明明想往下，而电梯却往上开。 + +### 接 + +在多用户单电梯的情况下，接和送这两个步骤变得耦合了，似乎很难完全分离开，因为当一个用户正乘电梯前往目的地时，另一个用户可能希望搭上这部电梯，接和送是同时进行的。 + +不过，我们依然先考虑电梯如何响应用户「接」请求。 + +在单用户的情况下，电梯只需要直接前往用户所在的楼层就好了；在多用户的情况下，电梯则需要排序，即先前往哪个楼层，再前往哪个楼层。我们在此假设没有人按下楼层键，「送」的算法还没有开始。 + +#### 单向运行的情况 + +在一些情况下，电梯只需要单向运行。假设电梯在 6 楼，有两个用户分别在 3 楼 和 4 楼按下了电梯的下行按钮，有另一个用户在 1 楼按下了电梯的上行按钮，那么电梯只需要一直往下，分别在对应的楼层停下就好了。当前两个用户到达了 1 楼，最后一个用户正好可以上楼。 + +#### 上下楼层都有用户呼叫的情况 + +如果电梯在 4 楼，而 2 楼、3 楼和 6 楼都有用户希望下行，电梯应该如何响应呢？如果先去离得最近的 3 楼，再去 2 楼，在把这两个用户送到一楼之后再去接 6 楼的用户，显然是不合理的；电梯应该先往上，接到 6 楼的用户后再一路向下。反之亦然，如果电梯上方和下方的楼层都有用户在等待接送，而他们选择的运送方向都是一致的，那么先向反方向运行是最有效率的，可以避免走回头路——如果当前的所有用户都希望往上，那么电梯就应该先考虑向下，然后一路向上完成运送任务。 + +听起来很美好，但真的可行吗？比较极端的例子是，电梯在 17 楼，现在 18 楼和 19 楼有用户希望向上前往更高的楼层，此时 1 楼又有用户希望往上，电梯显然不应该先去一楼。对于特别高的楼层来说，这个方法不一定能保证效率。 + +虽然不能保证效率，但「反方向优先」的方案的确保证了电梯的资源消耗最低，也就是**路线最短**。如果先接送离电梯最近的用户，电梯的总运行路线长度是 41 层楼；如果先接送反方向上的用户，电梯的总运行路线长度是 35 层楼。如果电梯的运行速度是恒定的，不考虑在每个楼层的停靠时间，路线的长度就决定了时间长短。如果要保证时间最短，就应该采用「反方向优先」的方案。 + +![](https://image.guhub.cn/picgo2025/IMG_0369.PNG "上为「最近用户优先」的方案，下为「反方向优先」的方案。") + +刚才我们一直假设所有用户都想去同一个楼层，那如果只有 18 和 19 楼的用户想去 20 楼，而 1 楼的用户只想去 8 楼呢？ + +![](https://image.guhub.cn/picgo2025/IMG_0370.PNG) + +在这种情况下，「最近用户优先」的方案一共移动了 29 层，「反方向优先」的方案还是移动了 35 层。显然，「反方向优先」的方案连总运行时间都不一定能保证最小，而且无论运行时间如何，这种方案都会让高层的用户等待很久。 + +等等，他们只是想去 20 楼而已，为什么不走楼梯？ + +楼梯其实也可以分摊电梯的负担，但别忘了，这两个用户还没有上电梯，他们只是按下了「上行」按钮，电梯并不知道他们要去的是 20 楼还是 40 楼。况且，电梯的制造商应该也不想培养用户走楼梯的习惯吧——这样他们还怎么卖产品？ + +问题又来了，如果 18 和 19 层的用户真的是想要去 40 层呢？ + +![](https://image.guhub.cn/picgo2025/IMG_0371.PNG) + +「最近用户优先」的方案的总路线长度是 62 层楼，「反方向优先」方案的总路线长度是 55 层楼。 + +…… + +扯了这么多，结果还是没得出多用户单电梯情况下应该如何调遣电梯。显然，「最近用户优先」和「反方向优先」的方案都有弊端，各取所长应该是最好的。 + +```javascript +if (condition) { + elevator.moveTowardsClosestUserFirst() +} else { + elevator.moveTowardsOppositeDirectionFirst() +} +``` + +那么，这个 `condition` 应该如何计算呢？ + +### 送 + +## 多用户多电梯调度 + +### 接 + +### 送 + +## 一种新的电梯设想 + +能不能模仿商场里的扶手电梯（Escalator），只设置一个只上行的电梯和一个只下行的电梯呢？ + +--- + +另，感觉电梯的调度其实可以让 AI 实时生成最优调度方案，编写精密的算法实在是太费脑子了。 \ No newline at end of file diff --git "a/content/posts/\347\234\213\345\212\250\347\224\273\347\211\207\345\246\202\344\275\225\345\270\256\346\210\221\346\217\220\345\215\207\350\257\221\350\200\205\347\264\240\345\205\273.md" "b/content/posts/\347\234\213\345\212\250\347\224\273\347\211\207\345\246\202\344\275\225\345\270\256\346\210\221\346\217\220\345\215\207\350\257\221\350\200\205\347\264\240\345\205\273.md" new file mode 100644 index 00000000..07e58371 --- /dev/null +++ "b/content/posts/\347\234\213\345\212\250\347\224\273\347\211\207\345\246\202\344\275\225\345\270\256\346\210\221\346\217\220\345\215\207\350\257\221\350\200\205\347\264\240\345\205\273.md" @@ -0,0 +1,199 @@ +--- +title: 看动画片如何帮我提升译者素养？ +subtitle: 从不存在的标准到马名大赏 +tags: + - 翻译 + - 语言 + - English + - 创作 +date: 2025-06-20T22:46:00 +banner: https://image.guhub.cn/picgo2025/large-2775847205.jpg +draft: false +toc: true +--- + +连续三天被关在机房写代码，急着复习但组员进度太慢急也快不了，还到处改别人提交上来的代码，我终于是要**疯啦**。于是今晚回到家之后就玩起了同事送给我的旋转猫猫立牌，所以决定要写一篇英译中译名鉴赏文章。 + +想必整篇文章的因果逻辑已经很明显了！ + +--- + +呼—— 好了，这其实是一篇*还算*正经的文章，除了缓解焦虑的目的，也的确想要写篇文章聊一聊英文到中文的人名翻译。即使是一般的人名，音译也会有约定俗成的标准，对于一些发生在架空世界中的影视作品，角色名可能会有非常明显的含义，与这个角色本身的形象相关，这种情况就很考验译者两门语言的语言能力了。 + +这篇文章分两部分，最开始先来聊聊纯音译的人名有什么讲究，再来聊聊一些影视和动画作品里的人名——你可能猜到了，我要聊的就是《小马宝莉》。 + +## 现实中的人名翻译 + +一直听说外国人名翻译成中文是有国家标准的，事实果真如此吗？记得我在玩《Don't Starve》的时候发现，Maxwell 这个人物一直被译作「麦斯威尔」，省略了其中 /k/ 的发音；而现实中的的 Maxwell Equations 却叫做「麦克斯韦方程组」，省略了 /l/ 的发音。这显然不是同一个标准。 + +前者是电子游戏的翻译，后者则常出现在正式出版物当中，如果要说谁最有可能遵循了正确的标准，那当然是后者。不过，我其实不喜欢「麦克斯韦」这个译名，原因如下：Maxwell 由 max 和 well 两个音节组成，如果音译，显然最好是每个音节在译名中也对应相同长度的中文音节，省略哪个辅音当然不重要；然而，「麦克斯韦」这个译名中，max 对应的是「麦克斯」，而 well 就只剩下「韦」了。反观《Don't Starve》中的「麦斯威尔」，max 对应「麦斯」，well 对应「威尔」，就对得很整齐。 + +有意思的是，同样是 Maxwell，在搜索引擎中搜索「麦斯威尔」得到的要么是《Don't Starve》游戏相关的信息，要么是「麦斯威尔咖啡」这个品牌的信息；如果搜索「麦克斯韦」，搜到的就是「麦斯韦方程组」和他的提出者 James Clerk Maxwell。 + +前面都是猜测和好恶判断，所以究竟有没有标准，谁又遵循了标准，谁在翻译上做得更出众？这些问题都没有得到解答。这一部分先来谈谈这些问题。 + +### 国家标准 + +在[全国标准信息公共服务平台](https://std.samr.gov.cn/)上能检索到两种国家标准：国家强制性标准（GB）和国家推荐性标准（GB/T）。 + +国家标准的话，其实我只能查找到各种语言的「外语地名汉字译写导则」，其他的没有注明是「地名」的「外语汉字译写导则」都是行业标准，并非国家标准，而且也没有适用于英语这门语言的标准。所以，一番查阅之后，我只能找到「外语地名汉字译写导则」，这和人名翻译关系不大，而且还不是强制性标准，只是推荐标准而已。 + +![image.png](https://image.guhub.cn/picgo2025/20250620145229.png) + +### 事实标准 + +商务印书馆出版的《[英语姓名译名手册](https://book.douban.com/subject/30477199/)》似乎是一个不错的参考，不过我并没有找到最新修订的第五版的电子书。第五版是 2018 年出版的，在 2004 年版的基础上修订。我不想买实体书，所以找了中国出版集团出版的《世界人名翻译大辞典》，于 2007 年出版。尽管出版社不同，但都是由新华通讯社译名室主编的，质量应该不会有太多差异，后者涵盖的范围还更广。尽管有出版年份上的差异，但人名这个东西其实很少出现新的了，大概也不用太在意。 + +查阅之后，我发现，「麦克斯韦」和「麦斯威尔」好像都没遵循标准。这本书里给出的标准译名是「马克斯韦尔」，一个辅音都没漏掉。不过，这本书也承认「麦克斯韦」的译法，还特地把 Maxwell, James Clerk 标注了出来，此外还有「麦士威」这种奇怪的译法；反倒是「麦斯威尔」这个译名从没出现过。 + +![image.png](https://image.guhub.cn/picgo2025/20250620150911.png "《世界人名翻译大辞典》上（2007 年修订版），P1929") + +和所有的辞典一样，这种类型的书的作用兴许跟百科全书一样，只是记录、归纳和总结现有的做法，而不是制定新的标准，要求别人遵循。因为麦克斯韦、麦克斯韦尔、麦士威都是常见的译法，所以都被收录过来了，供后人参考而已。所以，不能说「麦克斯韦」这个译名遵循了什么标准，只是因为先有了这种译法，才被收录到了辞典里。 + +### 译音表 + +如果只是用「原文 - 译名」的格式把尽可能多的人名都列了出来，那这本词典也太无聊了，而且要是遇到了生造词，就无从下手了。好在附录中还给出了 55 种语言的译音表，用辅音和元音对照起来查表，就能找到对应的翻译用字。 + +![image.png](https://image.guhub.cn/picgo2025/20250620151629.png "《世界人名翻译大辞典》附录中的译音表，如果不清晰，可以查阅[维基百科上的译音表](https://zh.wikipedia.org/zh-cn/Wikipedia:外語譯音表/英語)") + +这么看来，Maxwell 译作「马克斯韦尔」是符合译音表的：Maxwell 读作 /makswel/，/ma/ 在表中对应「马（玛）」，/k/ 对应「克」，/s/ 对应「斯」，/we/ 对应「韦」，/l/ 对应「尔」。 + +仔细看的话，这个译音表有一些地方令人疑惑。比如 /we/ 译作「韦」，但 /wi/ 译作「威」，明明两个字在中文里只有音调的差别而已，仿佛是为了制造差异而故意选了不一样的字。然而，要是以「为了制造差异」为由，好像也说不通，因为「韦」这个字在译音表中实际上对应五个发音，分别是 /wei/ /vei/ /we/ /ve/ 和 /vai/。 + +这个译音表也有不少局限性，比如 /tr/ 和 /dr/ 这两个音就没有对应的译字，必须拆开了译。《小马宝莉》里有个角色名字叫做 Trixie，官方译名遵照标准，把 Trixie 拆成了 t-ri-k-si，译作「特丽克西」，而民间汉化组则没有管任何标准，巧妙地译作了「崔克西」，不仅更贴合原文发音，还更简洁，而且音节数量也是相通的。 + +这个译音表是怎么得出来的呢？一般来说，人名翻译要注意几个原则：一是不能让人联想到不好的意思，比如前文的「崔克西」要是译成了「催可惜」就不好了，要保持中性；二是最好不要和中文里的名字太像，保留一些外文的感觉为妙。 + +当然，这是现实生活中人名翻译的原则，如果是影视作品和动画片，打破一些标准和原则可能是更好的——如果 Trixie 真是一个悲催、令人惋惜的角色，译成「催可惜」不也挺好吗？ + +总而言之，==人名翻译没有强制性的、统一的标准，常见的人名可能有约定俗成的译法，但面对新语境下的旧名字和生造的新名字，译者发挥自己的创造力也是值得鼓励的，尤其是在虚构作品中==。接下来我们就以《小马宝莉》这部动画片中的角色名为例，看看虚构作品中的人名要怎么译才好。 + +--- + +## 小马国马名大赏 + +### Photo Finish + +很多动画片里都有那么一两个经常出现而且工具性很强的配角，Photo Finish 就是一个。从名字就能猜出来，她是一个摄影师，几乎在每一个需要拍照的场合都会有她出现。Photo Finish 指的是按下快门，「照片完成」的那个时刻。 + +{{< gallery >}} +![](https://image.guhub.cn/picgo2025/Photo-finish.jpg "画面中央的角色即「Photo Finish」") + +![](https://image.guhub.cn/picgo2025/PixPin_2025-06-18_22-37-46%20Large.jpeg "片头曲最后的合影也有她出场（右下角）"){{}} + +Photo Finish 的官方译名是「美照菲妮莎」，我觉得译得很妙。这个词的前半部分直接取了 Photo 的本意，只不过加上了「美」这个形容词——一方面让名字更顺口了，另一方面又凸显了人物的特质，这个角色的确被塑造成了走在审美前沿的形象。后半部分 Finish 采取音译，「菲妮莎」确实很像一个人名，而且不常见，很独树一帜，和人物形象也惊人地匹配。这个半音译半意译的名字听起来毫不违和，仿佛是原创的中文名字，好的译名就应该这样。 + +一些民间字幕组把 Photo Finish 这个名字译作「终局定格」，听起来很酷，而且和原文一样是四个音节，用相同的、有些装腔作势的语气读出来能达到和原文相似的效果。只不过，这听起来不太像个人名。[^1] + +### Twilight Sparkle 和其他很多的马 + +如果这个名字你觉得陌生，那你肯定知道「紫悦」这个名字，或者至少在家里的小孩子看电视的时候听到过这个名字。作为这部动画片的主角，Twilight Sparkle 有一个相当糟糕的译名。可能是为了商业考虑，起了一个小孩子容易记住、能与角色形象紧密关联起来、阳光积极向上的名字，又或者是官方的汉化组脑袋一抽看这匹紫色的马整天嬉皮笑脸了就起了个颜色加情绪的名字。总而言之，这很不好，和原文一点关系都没有。 + +![](https://image.guhub.cn/picgo2025/Twilight_with_robe_and_scepter_S4E02.webp) + +民间字幕组的译名是「暮光闪闪」，这也是圈内人士接受度最高的一个名字（圈内人士指喜欢看《小马宝莉》的成年人们）。说实话，这个译名也没什么值得称道的，因为他就是直译而已。你可能觉得这不像个人名，但看过前面的 Photo Finish，你大概就知道这部动画片给角色起名的逻辑是什么样的了。 + +「紫悦」这个名字的另一个罪状是，它完全没有做到统一（可能是最初的汉化组根本没想到这部动画片在后续的剧集里居然会出现这么多名字和各种光有关的角色）。 + +另外两个采用了相似命名方式的角色分别是 Sunset Shimmer 和 Starlight Glimmer，她们都是这部动画片中比较重要的角色，而且，每个名字符合「光源 + 发光的描述」这种格式的角色，在设定上都有「魔法天赋」。对于这两个名字，官方汉化组没有造出「黄乐」和「紫怨」这种名字，而是采取了直译，分别叫做「余晖烁烁」和「星光熠熠」。民间字幕组也是这样译的。 + +令人迷惑的是，另一个并没有这种命名格式的角色，Sunburst，他的译名居然也是「光源 + 发光的描述」的格式，被译作「日光耀耀」。官方汉化组在这个时候居然又在乎起译名的统一来了。Sunburst 的民间译名是「隙日」，这是直译，Sunburst 这个词本来描述的就是穿过云层、突然出现的日光；「日光耀耀」不仅在格式上乱搞，意思也没译对。 + +{{< gallery >}} +![](https://image.guhub.cn/picgo2025/Starlight_Glimmer_suddenly_standing_next_to_Sunset_EGS3.webp "Sunset Shimmer（左）和 Starlight Glimmer（右）") + +![](https://image.guhub.cn/picgo2025/sunburst-and-starlight.webp "Starlight Glimmer（左）和 Sunburst（右）") +{{}} + +顺带一提，Twilight Sparkle 还有个哥哥，名字叫 Shining Armor，官方直译为「闪耀盔甲」，而民间则仿造「暮光闪闪」，译作「银甲闪闪」，想要把他们塑造成「闪闪一家」。他俩的父母的确有时会被称作 Mrs. Sparkle 和 Mr. Sparkle，但他们其实并不姓 Sparkle。父母的名字叫做 Twilight Velvet[^2]和 Night Light（夜光），并没有 Sparkle 这个词。我想动画的官方制作组就没有想明白这一家人的命名逻辑，更别说官方和民间的汉化组了。要用设定解释的话，说小马没有姓氏也能解释得通。 + +### The Apple Family + +动画中的 Apple Family，顾名思义，就是种苹果为生的一个大家族。他们在小马国各地都有苹果园，剧中最常出现的是位于小马镇的「甜苹果园」，这里有四匹马，他们的名字都很有意思。 + +![](https://image.guhub.cn/picgo2025/Apple_family_admiring_third_sign_zap_apple_flowers_S2E12.webp "图中从左至右分别是 Apple Bloom、Granny Smith、Applejack 和 Big Macintosh") + +首先是主角六人组中的 Applejack，这个名字直译过来是「苹果杰克」，民间汉化组采用的就是这个译法；不过剧中人物一般称她为 A.J.，译作「阿杰」，这个音译也是很妙了。Applejack 其实是现实中一种酒的名字，也称「苹果白兰地」（Apple Brandy），是一种由苹果制成的烈性饮料，在十八、十九世纪以前流行于北美十三州地区[^3]；不过，Applejack 在剧中的形象与人们熟悉的西部牛仔更相似，而美国西部地区和北美十三州完全没有重叠。 + +官方在翻译 Applejack 这个名字的时候，因为「杰克」太不像个女性的名字，所以取了 Ja- 的发音，译成了「苹果嘉儿」…… 但 Applejack 本身就是一个男性特质更强的女性角色，为什么不能遵照原文要乱改呢？ + +苹果家族另外两个角色的名字取自现实中两个苹果的品种名。 + +Granny Smith 是一种源自澳洲的青苹果（所以剧中 Granny Smith 的肤色是青绿色），现实中译作「澳洲青苹」，不过在剧中就直译作「史密斯婆婆」了。当时我还疑惑了很久，苹果家究竟谁还姓史密斯…… 顺带一提，澳洲青苹的质地比较硬，咀嚼时会有一种特殊的音效，常被配音演员用做辅助道具；澳洲青苹对佩戴义齿的人很不友好，因为太硬了，而剧中的史密斯婆婆的确也戴义齿。[^4] + +Big Macintosh 的名字和苹果电脑 Macintosh（麦金塔）是同一个词，不过 Macintosh 这个词并不是因为苹果这家科技公司才和苹果联系起来的。实际上，Macintosh 是 McIntosh 的另一种拼法，这个词意思很多，其中之一就是一种苹果的名字，中文名叫「旭苹果」。[^5]Macintosh 的名字其实来自于一个名叫 John McIntosh 农民，是他发现了这种苹果。Macintosh 的缩读形式是 Mac，所以 Mac 这个词既可以表示一种苹果，也可以表示苹果电脑，还可以表示剧中的这个角色。在剧中，Big Macintosh 最常见的称呼就是 Big Mac，他的父亲叫做 Bright Mac。 + +我们看到了一个现实中的人名（John Macintosh），是如何变成一种苹果的名字，然后又变成某个虚构作品里一个角色的名字的（Big Macintosh）。类似的词源学轶闻，我在第十七期周刊里也有聊过。 + +> 读小说的时候碰到了一个奇怪的名词——「马尼拉文件夹」。我好奇一个普通的文件夹为什么会有这样的名字，而且，在我熟悉的后室（The Backrooms）作品中，也有一个叫做「马尼拉房间」的地方。我很好奇「马尼拉」到底是什么。 +> +> 马尼拉文件夹（manila folder）是指用「马尼拉麻焦」的树叶为原材料制成的文件夹，而「马尼拉」是菲律宾首都的名字。尽管后来的马尼拉文件夹不再使用马尼拉麻焦的纤维制作，但名字仍然保留了下来。 +> +> 在后室作品中，马尼拉房间是流浪者在 Level 0（后室的第一层）唯一能够碰面的地方，也是这一层里唯一一处线性空间，因其特性，故事中的探险者总署（M.E.G.）在此存放了许多包含关键信息的文件，来帮助初入后室的人类。大概是因为放有许多用马尼拉文件夹存放的文件，所以这个房间被称作「马尼拉房间」。 +> +> 这样简单的词源研究真的很有意思，你能看到一个地名是如何变成一个植物的名字，再变成一种物品的名字，再变成某个怪谈小说里的另一个地名的。 + +{{< right "——[稻草人周刊 Vol.17](/posts/weekly/17/)" >}} + +Big Macintosh 的官方译名是「麦托什」，这是个很烂的翻译。首先，它省略了 Big，此外，他连 Macintosh 的读音都弄错了，中间的 cin（kin）被无视了。根据《世界人名翻译大辞典》，MacIntosh 应当被翻译为「麦金托什」。 + +![image.png](https://image.guhub.cn/picgo2025/20250620142738.png "《世界人名翻译大辞典》上（2007 年修订版），P1838") + +不过你可能会疑惑，苹果电脑 Macintosh 难道不是「麦金塔」吗？那不是也没遵循标准？确实，to- 这个音就应该译作「托」而不是「塔」，而且 -sh 被忽略了。但相比之下，「麦托什」要错得多一些，因为它省略的是一个一整个音节（cin），而「麦金塔」只是省略了一个辅音（sh），还替换了一个相近的元音而已——包含元音的音节显然要比单个辅音更重要。 + +民间汉化组是怎么做的呢？他们把 Big Mac 译作「大麦」，简单直接，音节数也是相同的，和农民形象也很贴切。至于 Big Macintosh 怎么译，不重要，因为这个名字就不常见。我不能理解的是官方汉化组为什么要把 Big Mac 当成 Macintosh 来译。 + +最后还有一位 Apple Bloom，她在剧中是「可爱标记童子军」的一员，这个小社群一共有三个人，他们三人的名字都很有意思，所以放在下一节里一起讲。 + +### Cutie Mark Crusaders + +Cutie Mark Crusaders 的民译为「可爱标记童子军」，这个名字很值得说道。Cutie Mark 是剧中的一个设定，即「可爱标记」，剧中的每匹小马在「发现自己的天赋」之后就会获得可爱标记，长在马屁股上。对于小马国的小孩子们来说，获得可爱标记是一件很重要的事情，也是一件很酷的事情，太晚获得可爱标记可能会被嘲笑。Cutie Mark Crusaders 就是为了「获得可爱标记」而组建的小团体。 + +![](https://image.guhub.cn/picgo2025/600px-CMC_looking_at_book_S2E17.png.webp) + +其中 Crusaders 由 Crusade 这个词演变而来，Crusade 的意思是「圣战」，指中世纪由宗教引发的一系列战争；在现代语境中，Crusade 也指「与政治、社会或宗教改革相关的竞争」。Crusaders 自然就指参与这类竞争的人，不过，在这部*原本是给小孩看的*动画片里，Crusaders 的意思被弱化为了「为某一目标有着执着追求并愿意付出行动的人」，因为依然与「战斗」有关，Crusaders 被民间汉化组译作「童子军」，被官方译作「军团」。Cutie Mark Crusaders 的官方译名是「可爱军团」。 + +我认为民间译名「可爱标记童子军」和官方译名「可爱军团」各有可取之处。前者太长了，但最大程度上地保留了原文的意思；后者更上口，但「可爱」一词可能会引发误解。实际上，在剧中，Cutie Mark Crusaders 常常被缩写为 CMC；如果要译的话，不妨把全称「Cutie Mark Crusaders」译作「可爱标记童子军」，把 CMC 译作「可爱军团」。 + +CMC 的成员之一就是前面提到的 Apple Bloom，苹果家族的一员，除此之外还有 Scootaloo 和 Sweetie Belle。三匹马分别是陆马、飞马和独角兽，凑齐了小马国的三个种族， ~~很政治正确了~~ 。 + +很容易发现，这三匹小马的名字没有任何相似之处，但他们的官方译名分别是： + +- Apple Bloom —— 苹果丽丽 +- Scootaloo —— 醒目露露 +- Sweetie Belle —— 甜心宝宝 + +我快要受不了这种被滥用的 ABCC 结构了…… + +这种格式显然是和主角 Twilight Sparkle（暮光闪闪）的民间译名相同的，但官方明明在一开始就没有采用「暮光闪闪」的译名，而是胡乱地造了一个「紫悦」出来，结果在后来又非要把这种格式硬塞给别的角色。 + +这三匹马的民间译名分别是：小苹花、飞板露和甜贝尔。 + +Apple Bloom 译作「苹果丽丽」显然是在乱搞，Bloom 就是花的意思，这个名字是想表达 Apple Bloom 这个角色是还没长成苹果，仍处于花苞阶段的年轻小马，而不是她很「美丽」。「丽」这个意思在原文中就没出现过。 + +Scootaloo 的名字明显取自 Scooter（滑板车），这个角色经常骑滑板车出场。Scootaloo 不仅很晚才获得可爱标记，作为一匹飞马，他也一直没有学会如何飞行，所以才经常骑滑板车来体验类似飞行的感觉。「醒目露露」这个译名简直是在乱搞，「醒目」这个词到底是怎么来的？ + +{{< gallery >}} +![](https://image.guhub.cn/picgo2025/61Sf9g1CVLL._AC_SL1500_-2114255214.jpg "Scooter（滑板车）") +![](https://image.guhub.cn/picgo2025/maxresdefault-622100547.jpg "骑滑板车的飞板露（Scootaloo riding a scooter）") +{{}} + +Sweetie Belle 的名字没什么好说的，译成「甜心宝宝」其实能理解，毕竟 Sweetie 的确就是「甜心」的意思。结合她姐姐 Rarity 的名流形象，偶尔会说西语和法语，Belle 应该就是法语中的「美丽」的意思（Sweetie Belle 才是应该被译作「丽丽」的那一个啊喂！），也有可能取自迪士尼公主 Belle，也就是《美女与野兽》里的那位。官译的「甜心宝宝」和民译的「甜贝尔」都大差不差，前者把 Belle 译成「宝宝」也还能忍受，后者把 Belle 音译成「贝尔」也保留了法语出现在英语人名中的异域感。 + +## 写在最后 + +关于名字怎么译，其实到现在已经没什么标准了，大部分时候都是见仁见智。严肃的正式出版物需要参照一定的标准来保证不会出岔子，也为了体现自己的专业性，但是在更多的语境下，如娱乐作品中出现的外文名，其实是考验译者语言素养的机会，也有不少发挥的空间。==翻译令人着迷的点在于，译者并不是从头开始造一个新的东西，摸不着一点边界的自由令人害怕，译者能在原语言给定的松散框架下发挥创造力，体会两种语言的差异和两种文化的交织，是一种集感受和创造为一体的、令人愉悦的工作==。只不过翻译的成果被发表出来受人审视时就显得有些可怕了，很多时候实际上是[吃力不讨好](/posts/翻译的吃力不讨好/)。 + +如今我已经不常批评坏的翻译了，更多地，我批评不用心的翻译以及不纯粹的翻译。不用心的翻译看美剧的时候经常能看到，尤其是那些把笑点译错的，自己不懂的俚语也按字面意思硬译，完全是功课没做够，看了让人生气。不纯粹的翻译就是为了商业等与语言无关的因素考虑，比如把 Twilight Sparkle 译成「紫悦」，完全背离原文，对文字毫无尊重。 + +最后的最后，还想简单谈谈「大语言模型会取代译者吗？」。我的答案是：会也不会。不会是因为翻译是一种创造性工作，机器目前的结构还不允许它计算出曾经没有存在过的东西。会是因为，正如 Dan Sinker 在 [The Who Cares Era](https://dansinker.com/posts/2025-05-23-who-cares/) 中写的，对于大多数人来说，AI 生成的内容「足够好了」，他们不需要真实的人类为他们创造新的东西，机翻能满足大多数对阅读体验没有太多追求的人；对于无人在意时代的反叛者来说，无论是传统的机器翻译还是 AI 翻译，都「不够好」。 + +[^1]: 但原文 Photo Finish 就像人名了吗？ + +[^2]: 直译的话是「暮光天鹅绒」，我觉得可以译作「暮绒」，很顺口，不过我并不知道官方译名是什么。 + +[^3]: 参见：[苹果白兰地 - 维基百科，自由的百科全书](https://zh.wikipedia.org/zh-cn/蘋果白蘭地) + +[^4]: 参见：[Granny Smith - Wikipedia](https://en.wikipedia.org/wiki/Granny_Smith) + +[^5]: 参见：[McIntosh (apple) - Wikipedia](https://en.wikipedia.org/wiki/McIntosh_(apple)) 和 [Fetching Title#ta64](https://zh.wikipedia.org/zh-cn/旭苹果) -- cgit v1.2.3