# Lyrics Translator

> Turn Japanese song lyrics into polished Chinese lyrics under the faithfulness-expressiveness-elegance (信达雅) principles: read the whole song, pick a Chinese style matching its emotion and theme, draft a line-by-line translation, have a subagent review the draft, then revise before delivery. Use this skill whenever the user wants a Japanese song's lyrics rendered in Chinese, however they phrase it — 翻译歌词 / 歌词翻译 / 翻成中文 / 给我一个中文版 / 弄成中文版 / 想知道这首歌唱的是什么, or quality asks like 求信达雅 / 不要机翻腔 / 翻得有味道一点. Trigger it even when the request is terse or implicit: the user pastes Japanese lyrics into the chat, names a Japanese song or artist, or just gives a lyric file path (.txt/.lrc, the filename often a Japanese or romaji song title like 夜に駆ける.txt / hana_no_uta.lrc / jpn_lemon.txt) — a lyrics file plus a wish for Chinese is enough, the user need not say "日语" or "翻译" explicitly. Covers every genre with Japanese lyrics: J-pop, anime, vocaloid/UTAU, idol, enka, rock, folk. Do NOT use for lyrics in other languages, subtitle/new

- Skill: `sallyn0225/lyrics-translator` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add sallyn0225/lyrics-translator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sallyn0225/lyrics-translator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Sallyn0225 (https://skillmd.com/u/sallyn0225)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sallyn0225/lyrics-translator

---


# lyrics-translator

把日语歌词翻译为中文歌词。流程之所以分四步(通读定调 → 初译 → 子代理复核 → 修订交付),是因为歌词和普通文本不同:它是一个整体的艺术品,有统一的情感基调和风格。拿到歌词就逐行翻,每一行单看都对,拼起来却风格涣散、情感曲线断裂。所以先通读全曲、确定风格,再动笔;译完再让一双"没有参与翻译的眼睛"挑毛病,最后修订交付。

## Step 0: 输入与输出约定

**输入**: 歌词文件,常见 `.txt` / `.lrc`。

- 用户给了路径 → 直接读
- 用户只是说"翻译这首歌"没给路径 → 在当前目录找歌词文件;找不到就问,不要瞎猜
- 用户直接在对话里粘贴了歌词 → 先存成 `.txt` 文件(用歌名或合理的名字命名),再走流程,这样最终交付物有处可放

**输出**: 与原文件同目录,纯中文译文:

- `yozora.txt` → `yozora_zh.txt`
- `ハルカ_jpn.txt` → `ハルカ_zh.txt`(已有语言后缀则替换)
- `track01.lrc` → `track01_zh.lrc`(`.lrc` 的时间标签 `[mm:ss.xx]` 原样保留,只翻译标签后的文本)

如果用户要日中对照版,在 `_zh` 文件之外另出 `<主名>_对照.txt`(一行日文、一行中文、段间空行)。默认不出。

## Step 1: 通读与定调

**先把整首歌词读完,再决定任何事。** 这一步的产出是一段"风格定位"判断,它会贯穿初译、复核、修订三步,所以值得认真做。

通读时弄清楚:

1. **情感色彩**: 全曲基调(哀伤/热血/温柔/愤怒/俏皮…),以及情感曲线——很多歌主歌压抑、副歌爆发,或结尾反转,译文要能跟住这条曲线
2. **思想主题**: 这首歌到底在说什么?失恋、告别、自我和解、对世界的宣战……主题决定关键词的分量
3. **叙述视角**: 谁在唱、对谁唱。日语歌词大量省略主语,人称(我/你/他)必须根据全曲叙事统一判断,不能逐句猜
4. **原文语体**: 口语还是文语?有没有古语、方言、外来语轰炸?原文的语体是风格判断最硬的依据
5. **结构**: 主歌/副歌/桥段划分,重复段在哪里(重复段必须用统一译法)

**背景信息**: 如果从文件名或歌词内容能认出具体歌曲(动画/游戏/偶像企划的歌往往和剧情强绑定,剧情会改变歌词的理解),可以快速 WebSearch 确认出处和创作背景。认不出就凭文本翻,不要编造背景。

**选定风格**: 用一两句话写下风格定位和理由,例如:"原文为口语体、主题是少年向世界证明自己,副歌情绪外放——采用直白有力的现代语,短句为主,避免文雅辞藻"。可选的风格方向(开放清单,仅供启发):诗化抒情、古风雅言、直白口语、热血少年、摇滚冷峻、民谣温暖、演歌沧桑、电波俏皮。**风格服务于歌,不是炫技**——判断依据永远是原文的语体和情感,而不是"哪种风格显得译者厉害"。

如果用户明确指定了风格,用户优先,跳过自动判断(但仍要写下风格定位,供复核环节对照)。

## Step 2: 初译 — 信达雅怎么落地

逐行翻译全曲。三个准则在歌词语境下的具体含义:

**信(忠实)** — 忠实的对象是意象、情感和叙事,不是字面语序。

- 原文的意象(月、雨、车站、未送出的信)一个都不丢,也不擅自替换成"更美的"中文意象
- 不要"翻译升级":原文平实就译得平实,不要替作者抒情;同样不要降级,把浓烈的句子译淡
- 暧昧是日语歌词的核心手法。原文故意不说破的(那个人是死了还是走了?这是爱情还是友情?),译文同样保持开放,**不要替听众解读**
- 拿不准的多义句,选择与全曲主题一致的那个读法

**达(通顺)** — 译文要像中文歌词,不是翻译稿。

- 自检方法:遮住原文,单读中文。如果出现"的"字连串、欧化长定语、"虽然…但是"这类显式逻辑词(歌词的逻辑通常是隐含的),就是翻译腔,重写
- 中文比日语紧凑,译文行一般应比原文行短。凝练优先,一行歌词不要塞成一行散文
- **不强行押韵**:顺手能押就押,为了韵脚牺牲信或达就是丢了西瓜捡芝麻

**雅(风格)** — 雅不等于堆辞藻,口语摇滚译成四字成语连发恰恰是不雅。雅 = 措辞精准、贴合 Step 1 选定的风格,并且全曲统一。另外,当原文有规整的音数律(如七五调、文语对句)时,译文宜用相对工整的句式呼应——不是机械对齐字数,而是让读者能感到原文的节奏感;原文本身松散口语的,不要强行工整。

技术性约定:

- **行数对应**: 一行对一行,不合并、不拆分,空行(段落分隔)原样保留——用户可能拿译文去做字幕或对照排版
- **重复段一致**: 副歌每次出现用同一译法;但若原文重复段本身有微妙改动(歌词常用手法:最后一遍副歌换一个词),译文必须体现这个改动
- **拟声词、呼喊**(la la la、oh oh、ah)原样保留
- **原文中夹杂的英语行**通常原样保留(日语歌词的英语句是风格的一部分),除非用户要求全译
- **双关与文字游戏**: 优先保"意",中文实在无法兼顾时,正常翻译并在交付汇报里说明,不在译文里加注释
- **标题也要译**,交付时给出"原题 / 译题"

## Step 3: 子代理复核

初译完成后,**不要直接交付**。让一个没有参与翻译过程的代理来审,因为译者对自己刚写下的句子有惯性盲区——这正是要派 subagent 而不是自己再读一遍的原因。

- **有 `Agent` 工具**: 派一个 subagent(general-purpose 即可),prompt 用下面的模板
- **没有**(本 skill 被外层 subagent 调用、或环境不支持): 主代理自审,但要换一种读法——按模板里同样的三维清单**逐行对照**审一遍,而不是凭印象扫一遍

### 复核 prompt 模板

```
你是一名挑剔的歌词翻译审校,审读一首日语歌词的中文翻译初稿。
你没有参与翻译,这正是你的价值:不带惯性地逐行挑问题。

本曲风格定位(译者的判断,供你对照): <Step 1 的风格定位及理由>

日语原文:
<全文>

中文初译:
<全文>

从三个维度逐行对照审读:
1. 信 — 误译、漏译、意象丢失或被替换、过度发挥(译者自己加戏)、原文的暧昧被说破
2. 达 — 翻译腔、不像中文歌词的句子、行长失衡、节奏拖沓
3. 雅 — 与风格定位不符的措辞、辞藻堆砌或过于寡淡、重复段译法不一致

要求:
- 逐行对照,不要只扫大意
- 宁可苛刻,不要客气;但每条意见必须落到具体某一行,说清为什么是问题、怎么改更好
- 整体做得好的方面也简要说明,帮助译者判断哪些不要动
- 没有问题就明确说"未发现需要修改的问题",不要硬凑意见

返回格式:
## 总评
<两三句,信/达/雅各一句>
## 逐条意见
- [第 N 行] [信|达|雅] 原文「…」译作「…」: <问题> → 建议: <改法>
```

## Step 4: 修订与交付

拿到复核意见后,**逐条评估,不盲从**。复核者的优势是没有惯性盲区,劣势是对全曲风格统一性的沉浸不如主译——有的局部建议单看更好,放进全曲反而破坏统一。所以:

- 指出硬伤(误译、漏译、人称错误)的意见 → 基本都该采纳
- 风格和措辞类意见 → 用 Step 1 的风格定位做仲裁:贴合定位就采纳,偏离就驳回
- 驳回的重要意见,在交付汇报里说一句理由,让用户知道这里曾有过权衡

修订完成后,用 Write 写出最终译文文件(按 Step 0 的命名规则),然后在对话里向用户汇报。汇报的价值在于给用户**译文文件里看不到的东西**——主题情感的解读、风格选择的理由、翻译时的权衡;所以**不要在汇报里重贴译文全文**(用户自己会打开文件),需要讨论具体句子时只引用那一两行:

```
## 交付
- 译文文件: <路径>
- 标题: <原题> / <译题>
- 主题与情感: <一两句,这首歌在说什么、情感基调和曲线如何>
- 风格定位: <一两句,选了什么风格、为什么>
- 复核摘要: 复核共提出 N 条意见,采纳 M 条。主要修改: <一两条最有代表性的>;主要驳回: <如有,一句理由>
- 译注: <双关、典故、无法保留的文字游戏、需要向用户说明的取舍;没有就省略本行>
```

## 边界情况

- **`.lrc` 带重复时间标签**(一行多个 `[mm:ss]`): 标签全部保留,文本只译一次
- **多个歌词文件**: 一次只处理一首;用户没指明时问清先处理哪个
- **歌词整段是英语或中文**: 不在本 skill 范围,如实告诉用户;日语为主、夹杂少量外语行的正常处理
- **罗马音歌词**(romaji): 先确认用户是否有日文原文,罗马音歧义太多,直接翻容易错;实在只有罗马音就翻,但在交付汇报里注明风险
- **用户要求"可以唱的"译配版**(对音节数): 这超出默认范围,音节对齐会大幅牺牲信达,需要用户明确要求才做,且在汇报里说明取舍

## 文件结构

```
lyrics-translator/
├── SKILL.md           本文件
└── evals/
    ├── evals.json     测试用例
    └── fixtures/      测试用日语歌词(原创,避免版权问题)
```