翻訳結果を同僚に渡す場合、圧縮パッケージにどの追加リストを含める必要がありますか?

・翻訳原稿の更新後は、改ざんと誤判断されないよう、リストを再作成し、新旧ファイルの概要版との整合性を保つ必要があります。

翻訳結果を納品する場合、多くの人はいくつかの翻訳ファイルをパッケージ化して送信するだけです。同僚がそれを入手した後、多くの場合、各ファイルがどのオリジナル文書に対応しているのか、ターゲット言語は何なのか、どのページをレビューする必要があるのかを調べて、チャット ウィンドウで質問を繰り返す必要があります。

この記事は、同僚、クライアント、またはレビュー担当者に翻訳を頻繁に引き渡すチームに適しています。読むと、圧縮パッケージにどのような情報を追加する必要があるか、リストに何を記録する必要があるか、リストだけではどのような内容が推測できないかがわかります。

圧縮パッケージを納品する際にチェックリストを添付する必要がありますか?一文の結論

欲しい。多くの場合、機械可読な短いリストを zip ファイルに入れる方が、チャットで 10 個の追加指示を送信するよりも信頼性が高く、配信前に 1 分間時間を費やしておけば、後で何度もやりとりする手間を省くことができます。

事実をリストに記録し、曖昧な評価は書かないでください

「非常に良い品質」は、自動受け入れ、入出力の概要、ターゲット言語、タスクのバージョン、未解決の問題には使用できません。

• 機械によるチェックと人間によるレビューは、一般的な passed: true がすべてが正しいと言っていると誤解されるのを避けるために、別々に記録する必要があります。
• チェックリストは事実のフィールドを記録するだけで、受信者に結論を引き出すことなく、どこを見るべきかを伝えるだけです。

複合配信リストを作成して確認する

以下のコードは、隔離された環境でサンプル チェックされた合成サンプルを使用して実証されていますが、これはすべての実際のファイルや製品のパフォーマンスを保証するものではありません。重要な書類を処理する前に、原本を保管し、以下の範囲および受領事項に従って確認してください。

import hashlib
import json

def sha(raw):
    return hashlib.sha256(raw).hexdigest()

source = b"synthetic source"
output = b"synthetic translated output"
manifest = {
    "manifest_version": 1,
    "job_id": "demo-job-001",
    "source_sha256": sha(source),
    "output_sha256": sha(output),
    "target_language": "en",
    "policy_version": "demo-v1",
    "checks": {"file_present": True, "human_review": "pending"},
    "open_issues": ["Review terminology on the example cover"]
}
encoded = json.dumps(manifest, ensure_ascii=False, sort_keys=True)
restored = json.loads(encoded)
assert restored["source_sha256"] == sha(source)
assert restored["output_sha256"] == sha(output)
assert restored["checks"]["human_review"] == "pending"
assert restored["output_sha256"] != sha(output + b"changed")
assert not {"token", "password", "api_key"} & restored.keys()

コードの最後のアサーションは、いくつかのトップレベルのキーのみをチェックし、汎用の秘密スキャナーではありません。実際に配信する前に、明確なフィールドのホワイトリストを使用し、ネストされた構造とテキスト コメントを確認する必要があり、完全なリクエスト オブジェクトをそのままリストに含めるべきではありません。

マニフェストが受信者に提供される方法

リストの各フィールドには目的があり、境界があります。次の表は、各フィールドが受信者に対してできることと、そこから推測すべきではないことを説明しています。

📊 コアの比較

マニフェストとファイルは一緒にバージョン管理する必要があります

翻訳が更新された後は、リストも再生成する必要があります。新しいバージョンのファイルを古い概要の隣に置くと、正しいファイルが改ざんされたように見えます。

配信に不変のディレクトリまたはバージョン番号を使用すると、受信者が古いファイルと新しいファイルが混在したセットをダウンロードすることを避けることができます。

翻訳結果を引き継ぎやすくする

OmniDoc (製品ポータル)から翻訳をダウンロードした後、チームは独自の配信レイヤーでこのリストを生成し、ソース ファイル、言語、レビュー ステータスを記録できます。プラットフォームが何らかの内部テクノロジーを採用する必要はなく、コラボレーションに必要なコンテキストをドキュメントの外部に追加するだけで、結果の提供とレビューが容易になります。

参考：Python json。

🎯 どの方法があなたに適していますか?

圧縮パッケージに複数の翻訳が含まれている場合

各翻訳に対応するソースファイルを示すリストを添付してください。

複数人で作業を分担してレビューする必要がある場合

機械によるチェックと人間によるレビューを別々にチェックリストに記録し、対象言語を示します。

翻訳が更新されている場合

マニフェストを再生成し、新しいバージョン ファイルと同じバージョン ディレクトリに配置します。

チームの提供プロセスの責任者である場合

独自の配信レイヤーでマニフェストを生成し、ソース ファイル、言語、レビュー ステータスを記録します。

❓ よくある質問 (FAQ)

1. リストに直接「非常に良い品質」と書いてもいいですか？

お勧めしません。このタイプの評価は自動承認には使用できません。チェックリストには、入力および出力の概要、ターゲット言語、タスクのバージョン、未解決の問題などの事実を記録する必要があります。

2. リストには、チェックに合格したことが示されています。すべてが正しいということですか？

いいえ。機械検査と手動レビューは別々に記録する必要があります。passed: true はすべての内容が正しいことを意味するものではありません。

3. 完全なリクエスト オブジェクトをリストに含めることはできますか?

お勧めしません。明示的なフィールドのホワイトリストを使用し、ネストされた構造とテキスト コメントを確認する必要があります。

4. 翻訳が更新された後も、古いリストは引き続き使用できますか?

直接使用することはできません。新旧の混合を避けるために、マニフェストを再生成し、ドキュメントの新しいバージョンと組み合わせる必要があります。

📝 概要

翻訳結果が提供されたら、同僚がレビュー対象の文書、言語、場所をすぐに照合できるように、追加の事実リストを保管してください。納品前に 1 分かけて作成しておくと、後で指示を入力するよりも手間がかかりません。

OmniDoc Desktop を無料でダウンロード: ドキュメント、スプレッドシート、プレゼンテーション、PDF をすべて 1 か所に