Skip to content

Home

Jump to bottom Edit New page
Wen_He edited this page May 19, 2026 · 11 revisions

声明：本指南旨在为 TSDM 字幕组组内成员提供统一的 Git 协作标准与操作指引，确保项目在版本管理、溯源及交付流程中保持高效一致。

Github使用介绍（官方）| Github网页中文化插件

第0章：Git术语对照表

中文 英语 说明
仓库 Repository (Repo) 包含所有项目的字幕、字体和文档。
远程仓库 Remote 托管于 GitHub 服务器的中心节点，作为全组数据的唯一事实来源
本地仓库 Local 成员个人工作机上的项目副本。所有的编辑、提交操作优先在本地执行，经推送后同步至远程。
分支 Branch 从主线任务中隔离出来的独立开发线路。通过分支机制，翻译、校对等环节可以在互不干扰的情况下并行工作，确保 main 分支（主分支）始终处于“随时可发布”的稳定状态。
克隆 Clone 首次参与项目时，将远程仓库完整下载至本地的操作。
拉取 Pull 从远程仓库获取最新更新并自动合并至本地分支的操作。旨在确保个人工作环境与团队同步。
提交 Commit 将本地工作区的修改记录到版本库的动作。每一次提交都会生成唯一的哈希值（Hash），构成项目的历史快照。
推送 Push 将本地分支的提交历史上传并同步至远程仓库的操作。
获取 Fetch 仅下载远程仓库的变动数据，但不自动执行合并。用于在确认改动前查看团队进度。
拉取请求（PR） Pull Request Git 协作的核心机制。当成员完成特定任务（如校对）后，向监制发起合并申请。PR 提供了一个在线字幕审查界面，供监制进行逐行审核与讨论。
合并 Merge 经过审核确认无误后，同意将分支中的修改整合进目标分支（通常为main）的过程。
冲突 Conflict 当多名成员对同一文件的同一行进行了互斥修改，且 Git 无法自动决策时产生的逻辑逻辑中断。需由人工介入执行冲突解决（Resolve）。
议题 Issue 项目的任务管理追踪器。用于发布翻译计划、Bug 反馈及技术讨论。
变基 Rebase 重新定义分支的起点。通过 Rebase，可以将你在旧版基础上做的修改，“嫁接”到组员最新提交的代码之后，从而保持提交历史呈单向线性，避免产生混乱的合并轨迹。

第0.1章：协作工具推荐

为了适配 Git 工作流，请根据你的技术背景选择合适的工具组合。

工具名称 推荐人群 核心用途 资源
VS Code 全员推荐 现代化的字幕编辑与 Git 管理核心，支持插件扩展。 官方下载
GitHub Desktop Git 新手 图形化界面，像操作文件夹一样提交和拉取代码。 官方下载 汉化插件
Git CLI 硬核组员 命令行工具，响应速度快，适合处理复杂逻辑。 官方下载

建议配置方案：

  1. 方案 A (极简上手型)：GitHub Desktop (汉化) + Aegisub
    • 优点：无需学习任何命令，用 GitHub Desktop 同步文件，继续用 Aegisub 改字幕。
  2. 方案 B (高效协作型)：VS Code + Git 插件
    • 优点：在一个软件里同时完成编辑、翻译对比、版本提交，适合追求效率的成员。
  3. 方案 C (硬核进阶型)：Git CLI + 任意编辑器
    • 优点：极致的控制力，适合追求自动化或处理文件冲突的成员。

第1章：字幕组工作流程

第1.1章：字幕组交付规范

本章节定义了在 Git 协作环境下的命名标准与版本控制准则。

1. 内部代号 (Project ID)

  1. 命名原则：简洁易记，便于沟通。
  2. 格式要求：
    • 长度：3-6个字符（推荐4字）。
    • 字符：仅使用【中文汉字、英文字母、数字、连字符(-)】。
  3. Git 关联：内部代号即为该项目在仓库中的 分支 (Branch) 名称。
    • 示例：蘑菇魔女PV-A、厄里斯EP01。
  4. 命名者：项目监制会在项目启动时确定，并作为任务领取的唯一标识。

2. 版本管理：从“多文件”到“多提交”

核心原则：唯一文件名，版本历史化。 在 Git 工作流中，通过提交来记录修改，不再通过修改文件名来区分版本。

  1. 严禁标注版本号：仓库内的字幕文件名必须保持固定，禁止出现 _v1、_v2、_final 等后缀。
  2. 唯一命名格式：内部代号.ass（示例：蘑菇魔女PV-A.ass）。
  3. 状态追溯：
    • 存档：翻译、时轴、校对人员每完成阶段性工作，执行一次 提交（Commit）。
    • 溯源：若需查看历史版本（原 v2、v3 阶段），请通过 VS Code 的 Timeline 或 Git 历史记录查阅快照。
    • 撤销：若当前修改出现严重失误，可通过 Git 直接回滚至之前的任意提交点。

3. 资产分类与存储路径

为确保仓库轻量化，本项目采用“脚本与视频分离”的存储策略：

资产类别 存储位置 命名规范 说明
字幕文件 GitHub 仓库 内部代号.ass 协作核心，严禁带版本后缀。
字体文件 CF_R2 储存服务器 字体/ 仅存放本项目使用的特殊字体。
片源 CF_R2 储存服务器 内部代号 集数.格式 储存服务器只放置片源文件。
成品视频 项目群文件 [TSDM]作品原标题[来源][编码参数].格式 最终发布版本，不加内部代号。

提示：

  1. 不要怕犯错：Git 的每一次 Commit 都是一颗有存档。大胆提交，错误随时可以撤销。
  2. 高频存档：建议每完成 10-15 分钟的翻译/校对即进行一次提交，并写明简单的提交说明（如：feat: 完成前10分钟初翻）。
  3. 保持整洁：仓库中只应存在“正在修改”的那一个文件，旧版本已安全地存储在历史记录中，无需手动保留复件。
  4. 新人求助：如果遇到“冲突 (Conflict)”无法解决，请立刻停止操作并在群内@技术人员，严禁暴力覆盖。

第1.2章：工作分配与岗位细则

工作分配方式

如何接任务？

  1. 查看 GitHub 上的议题（Issues）：所有待处理任务均以议题（ Issue ）形式发布在仓库中。
  2. 登记认领：在议题下方留言或由监制指派（Assign）给你。
  3. 更新进度：通过项目看板（Projects）或议题状态进行追踪。遇到问题直接在 Issue 评论区 @ 相关负责人。
    • GitHub 记录是协作的唯一依据，确保所有沟通痕迹可追溯，避免口头承诺后遗忘。

工作流程

0. 任务创建 | 监制

创建任务 Issue，确定作品信息与内部代号；建立对应的 项目看板 条目。 面向新人：监制会直接在 Issue 中 @你，点击通知即可进入工作环境。

1. 准备阶段 | 片源 · 监制 · 校对

片源下载至 CF R2服务器；监制在仓库Wiki完善术语表。

2. 空轴 | 时轴

基于 main 分支创建工作分支 内部代号，提交初始空轴文件。并将议题标签设置为Status: 翻译

3. 翻译| 翻译

在工作分支上直接编辑字幕文件。

  • 存档要求：翻译每完成一个阶段（如前 10 分钟），执行一次 Commit。
  • 提交：完成后发起 拉取请求 (PR)，并将标签设置为 Status: 时轴。

4.1. 轴校 | 时轴

如果2. 空轴没有执行，而是使用官方时轴，则需要添加此步骤。 此步骤中，修正自动轴的错误或偏差。完成后发起PR，并将标签设置为 Status: 校对

4.2. 校对 | 校对

直接在翻译发起的 PR 中进行修改。

  • 优势：利用 GitHub 的 文件差异 界面进行逐行比对。
  • 交流：若有争议，在对应行下方留言讨论，达成共识后直接 提交 修正。完成后发起PR，并将标签设置为 Status: 特效

5. 后期&特效 | 时轴/特效

在 PR 状态流转至后期阶段后，如果校对或监制认为有必要进行帧级对齐及 UI 样式制作。完成后发起PR，并将标签设置为 Status: 监制

6. 二校&终审 | 监制

监制对 PR 进行最后的复查。

  • 审核：以观众视角确认观感。
  • 合规：确认命名格式与字体包完整性。

7. 合并入库 (Merge) | 监制

监制点击 合并拉取请求（Merge Pull Request）。此时，工作分支的代码正式合入 main。并将标签设置为 Status: 压制 一旦合并，即视为终稿。

8. 压制 (Encoding) | 压制

压制组从 main 分支拉取最新的 内部代号.ass，配合上的原片进行输出。 并项目标签设置为Status: 已完成，项目将自动关闭。

【简化流程说明：PV / CM / 短 SP 项目】 采用精简分支策略： 议题创建 → 翻译提交 PR → 校对在 PR 中直接修改 → 监制合并 → 压制

■ 翻译

  • 操作规范：在 内部代号.ass 中直接输入 日文原文 + 中文翻译。
  • 分层处理：将两种语言分为不同层（Layer），确保字幕不重叠。
    • Layer 0 (底色/背景)：日语原文，取较小字号。
    • Layer 1 (主层)：中文译文，取标准字号。译文在原文的上方。
  • 翻译范围：包含对白及屏幕文本（UI、标题、提示等）；歌词通常由监制负责。
  • Git 提交习惯：
    • 若对翻译不确定，可在译文后标注 *，并在提交信息中注明“有不懂的地方需要校对确认”。
    • 严禁通过修改文件名（如 [翻译]xxx.ass）来提交。
  • 求助机制：遇到难点或梗，优先查阅 Wiki 术语表，或在 Issue 评论区留言讨论。

■ 校对

校对是质量的核心，在 Git 流程中，校对应利用PR的审查功能提高效率。

  • 核心职责：审核听写/翻译准确性，核对Wiki 术语表，优化语气与长句拆分。

  • 修改确认：所有修改建议应在 PR 流程中与翻译达成共识。

  • 存档与注释规范：

    重要变革：得益于 Git 的版本对比功能，除非必要，不再要求在 .ass 中手动编写 @@修改理由。

    推荐的校对工作流：

    1. 行内修改：直接修改译文行，Git 会自动标记出你删除了哪几个字、增加了哪几个字。
    2. 代码评论：若修改原因复杂，请在 GitHub PR 界面 对应行下方点击 + 号直接发表评论，而不是写在字幕文件里。
    3. 保留原文（可选）：若需保留原翻译作为参考，可将其设为注释（ Comment ）行。

■ 时间轴

推荐无字幕/日语基础的新手从此岗位入门

  • 空轴制作：基于音频与画面打出粗略时间轴。允许长难句存在误差，校对/二校阶段会进行精调。
  • 交接：完成空轴后直接推送并发起 PR，指派翻译进场。
  • 歌词通常不需要做轴。遇到极高频对话无法处理时，可交给翻译/监制协调。

■ 压制

  • 任务领取：监制在合并 main 分支后，压制拉取最新终稿。
  • 技术要求：使用 FFmpeg 等工具进行编码。配合监制完成字体子集化、参数优化等任务。
  • 资产获取：从 CFR2 服务器 下载原片，完成后上传成品到项目群文件。

硬件参考配置：

级别 家用环境 (推荐/最低) 服务器环境 (推荐/最低)
推荐 i7-10700 / R7-5700 以上 Xeon 6728P / EPYC 9254 以上
最低 i7-4790 / R5-3500 以上 Xeon Silver 4314 / EPYC 7371 以上

■ 监制

监制是项目的“守门员”，负责从源头检查到最终合并的全流程管理。

  • 源检查：确认画质、帧率、色彩空间、音轨完整性，排除缺帧/损坏问题。
  • 项目看板管理：在 GitHub 项目中实时维护项目状态，确认参与人员、内部代号与当前阶段。
  • 成果接收与合并：
    • 合规性核查：确认命名是否符合 内部代号.ass，字体包（fonts/）是否齐全。
    • PR 审查：确认翻译与校对已完成意见交换。
    • 终审入库：监制点击合并，即代表该稿件正式成为“终稿”，并通知压制组。
  • 流程弹性：监制有权根据项目紧急程度（如 PV/CM）精简 Git 分支流转流程。

第2.1章：时间轴规范

本章统一字体样式、层级与安全框、对白与镜头切换、阅读速率与分割等原则，确保输出在1080p下拥有高易读性。

1) 字体规范

在正剧流程中，字体规范由监制决定。 非特殊情况下请使用以下样式作为默认字体；即使不使用，也请在脚本中保留这些样式以便统一与复用。

Style: 声明,Source Han Sans CN,40,&H00FFFFFF,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,2,0,8,10,10,10,1 Style: 对白 日语,Source Han Sans JP,45,&H00FFFFFF,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,2,0,2,10,10,30,1 Style: 对白 中文,Source Han Sans SC Medium,70,&H00FFFFFF,&H000000FF,&H00000000,&H0000FFFF,-1,0,0,0,100,100,1,0,1,2.2,0,2,10,10,65,1

已知部分系统在中文环境中会将字体名自动“本地化”。在这种情况下，工作中可临时使用下列样式，但提交前请用记事本替换回英文字体名。

Style: 声明,思源黑体 CN,40,&H00FFFFFF,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,2,0,8,10,10,10,1 Style: 对白 日语,思源黑体 JP,45,&H00FFFFFF,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,2,0,2,10,10,30,1 Style: 对白 中文,思源黑体 SC Medium,70,&H00FFFFFF,&H000000FF,&H00000000,&H0000FFFF,-1,0,0,0,100,100,1,0,1,2.2,0,2,10,10,65,1

使用方法：复制上述样式 → 打开 字幕 → 样式管理器 → 粘贴/导入。也可从群内下载样式 .ass 文件，在样式管理器中选择“从脚本中导入”。 非常建议将刚导入的样式“复制到样式库”，后续项目只需“复制到当前脚本”即可，无需重复导入。

  • 禁止使用存在版权纠纷风险的字体
  • 中文字幕禁止使用斜体。
  • 字号：1080p ≈ 40px 左右；4K ≈ 80px 左右，可按观感与用途调整。
  • 安全框：保持在画面 7–10% 内。以 1080p 为例：上下 38px、左右 67px 为参考基准，可按观感与用途调整。
  • 双语须分轴（中文轴与日文轴分离，中文在上日语在下），不可用 \N 直接分行；请确保层级不同，默认中文轴在Layer=1。
  • 屏幕文本（UI/牌匾/LOGO/标题等）应尽量模仿原文样式；可尝试衬线家族如 Source Han Serif SC 以贴近质感。（非强制）
  • 若字幕与画面文字 / 人脸 / 重要动作冲突，应调整位置；若无法回避，优先选择易读位置。连续多条请保持位置一致，避免上下抖动。

2) 成员表

开头请放置成员表，使用 声明 样式。PV 时长建议约 5 秒，并根据镜头切换调整结束时间。

本字幕由　{\b1\c&H00FFFF&}TSDM字幕组{\b0\c&HFFFFFF&}　制作　　仅供学习与交流使用　　禁止任何形式的商业用途\N听译：　校对：　时间轴：　压制：　监制：

3) 字幕时长与间隔

  • 开始时间尽可能贴近音频首帧。
  • 最小持续：不短于 20 帧（TV 动画常见 24fps ≈ 0.8s）。
  • 如果出现了上述的闪轴，应在组内讨论是否需要删除或合并。

4) 场景 / 镜头切换

  • 在正剧制作中，仅需根据角色语音决定时间轴的开始与结束时间（字幕与台词的误差不能大于300ms），下述规则均为可选。
  • 对白不得跨场景 / 镜头；仅当对白本身也跨场景 / 镜头时例外（优先保证语义与观感）。
  • 若对白开始位于切换点或切换后 0.5s 内，应将字幕开始设置为该场景 / 镜头的第一帧。
  • 若对白结束位于切换点前 0.5s 内，应将字幕结束提前至切换点前，且至少留 2 帧。
  • 以上为基准，请结合镜头语言与实际观感适度提前或延长。

5) 阅读速率

  • 每秒 ≤ 9 个中文字符；每行 ≤ 16 个中文字符；同屏禁止多行（注释、声明除外）。
  • 结合该原则与上下文，若后续无紧接字幕，可将当前字幕延续 ≥ 0.5s以便阅读（注意镜头切换）。
  • 长文本可考虑合并前后两条以降低瞬时阅读压力。

6) 分割原则

  • 字幕分割为多条连续字幕时，不要在行尾使用省略号或破折号“续行”；保持句法自然。
  • 省略号可表示长停顿（≥2s）或突然中断（被打断等）；若出现在字幕开头，表示“停顿后开始”。
  • 不得跨场景 / 镜头；若对白跨场景，请结合镜头语言与停顿酌情分割。

分割需注意：保持语义连贯；不改变原意；避免突兀；遇到争议请与组内沟通达成一致。

7) 歌词

  • 禁止使用斜体或引号标记歌词。
  • 可尝试放置在上方或右下角以避让 UI/人脸/动作。

8) 多人对话场景

  • 在不影响读取字幕和画面观感的情况下，字幕可根据人物站位放置于屏幕左右两侧
  • 画外音或更多人的情况下可尝试放置在上方或下方。

9) 备注

  • 样式由项目监制决定
  • 可尝试放置在上方或左上方。

第3章：翻译

目录

校对篇 我们非常推荐翻译也查看此校对文档，这是我们翻译的核心守则，下方的翻译规范为校对规范的简略版。 在线预览 下载

第3.1章：翻译规范 核心原则：意义 > 语气 > 字面。在忠于原文的基础上，确保中文自然顺畅，避免过度口语化或过度本地化。

1) 通则

  • 每行 ≤ 16 个中文字符，每秒 ≤ 10 个中文字符；同屏禁止分行。
  • 出现在画面且与剧情相关的文字／介绍性文本应译出；其余文本也应尽可能覆盖。
  • 若对表达或听译拿不准：应当标注「*」或征询其他翻译／校对，以免误译；任何情况下，禁止猜测。
  • 主语、量词、单复数、时间、肯定／否定、情绪倾向等需严格核对，结合上下文判断。
  • 英文等外来词应翻译；仅在很COOOOOL或确有必要时保留（并可备注解释）。
  • 无实际含义的语气词（啊、呢、嘛等），在不影响理解前提下可不译或少译。
  • 粗话／脏话按等效语气忠实翻译，可额外添加注释行提醒校对。
  • 禁止空耳，如 やばい → 牙白
  • 翻译稿的翻译栏仅允许出现纯译文或日语原文；禁止加入无关内容，如>女声1：不过是个盗贼罢了 女声2： 真是个品行败坏 (听出来是个形容女性贬低的词：娼婦 故作引申意)的人呐 男声 这到底发生什么事了 康斯坦丝(附身后)：到底是谁才是小偷呢？ 备注应当写在备注行内或说话人内。
  • 多人对话中因在说话人标签内备注说话人（非强制要求）
  • 翻译前因尽可能的查找该作品的资料，了解官方译名等并建立术语表。
  • 正剧组应该由监制在项目开始前建立术语表，后续有新增角色、地点、概念出现的情况下，任何组员可以公开宣言并修改术语表内容。
  • 主动阅读校对稿，有问题及时询问，避免同样的错误反复出现。

非必要禁止使用过度本地化词汇、地域刻板印象或网络迷因（如：“绝绝子”“YYDS”“盘它”“老六”“鸡你太美”“哈基米” 等）； 译文应耐久可读。

这位翻译，你也不想几年后看到自己写的译文，里面全都是非主流用语吧 神马都是浮云啦~

2) 俚语 / 谚语 / 典故

  • 优先查询是否有公认译法（官方小说／漫画译名、权威站点等）（在正剧组的情况下，请参照术语表）。
  • 可查明原义与功能，再替换为中文等效典故或表达。
  • 不可直译造成误解；优先级：意义 > 语气 > 字面。
  • 双关与暗示应保留其含义（必要时用备注解释）。
  • 避免使用过度地域化的俚语。
  • 方言（例：关西腔／东北腔）不拟方言处理，以普通书面语呈现语气差异。

3) 歌词处理

  • 歌词由监制确认是否需要翻译；优先使用官方翻译。

4) 数字与货币

  • 空间允许时，“一”至“十”可用汉字。
  • 数字应使用半角阿拉伯数字（1, 2, 3…），不要用全角（１, ２, ３…）。
  • 避免使用大写金融数字（壹贰叁…）；采用常用写法（如“五千”“四十亿”）。
  • 货币单位不要换算成人民币；保留原币种。

5) 标点规范

  • 不得使用逗号、句号、顿号、中文引号作为常规分句（用半角空格代替）。
  • 问句用全角？；感叹用全角！。
  • 引出引用语或内心独白、专属等情况用日语引号「」体现。
  • 省略号用全角“……”的一半“…”（在中文输入法内，通过Shift+6打出）。

6) 人名与专名

  • 有官方译名时优先（角色／演员／作品名等；漫画／小说如适用优先）。
  • 无官方译名：使用公认译名（如萌娘百科等）；仍无则音译。
  • 正剧组：人名、地名、概念等专有名词，一律参考术语表。
  • 昵称仅在有特定含义或效果时翻译（否则保留或备注）。
  • 历史／神话人物采用通用译名（例：Santa Claus = 圣诞老人）。
  • 外文人名用全角**·**连接（例：威廉·莎士比亚），日语名按官方原文写法处理（一些情况下，日语会使用连接符号「＝」，应该在原文保留）。
  • 角色口头禅（口癖）与高频用语应记录在术语表。

7) 备注

只能出现在：

  • 独立备注行（Aegisub 勾选“备注”）
  • 说话人栏。

加入我们：QQ群聊TSDM字幕组筹备组

Add a custom sidebar

Clone this wiki locally