きりしま屋

ベースになっているのは現在だと
25.10 Nightlyの最新バージョンのはずで、
たとえば、現在のリリースバージョンの
25.04
だと、
Release/25.4.0
Release/25.4.1
Release/25.4.2
などの
ブランチがありますが、これらの言語ファイルを編集して送信したプルリクエストが承認されてマージされたとしても、次の25.04がいつ公開されるかわからないのでなかなか手応えが現れないかと思います。
（翻訳が間違っているとかなら果敢に挑戦してもいいかもと思いますが、その翻訳は以降のメインストリームのバージョンの翻訳の役に立つかどうかという点でも微妙）

ので、
基本的には
Nightly
の最新板を稼働させて画面を確認して翻訳状態を見ながら
masterブランチに対してフォークした環境で翻訳してプルリクエストしていくのがいいと思います。
Nightly なら毎日ビルドされるので、2～3日後には承認されたプルリクエストの反映されたISOイメージを試すことができるようになるはずです。
ただ全面的に片っ端からテキストを翻訳してもアップデートの中でボロボロ新しい文字列が増えていくのと、すでに翻訳した文字列が使われなくなっていったりするのも切ないかなと。

それからこういうのの翻訳で思うのですが
アルファベットのままの方が分かりやすいもの（プール or Pool、データセット or Dataset）
翻訳しようとしても結局カタカナになるだけのもの
日本語に意訳するとかえって意味が分からないもの
変数を挟んだ前後の構成で日本語ではスッキリした表現にできないもの
英単語が複数くっついている場合、カナカナで表記する際に続けるか「・」でつなぐか
日本語にすると余分なスペースをとってUI上バランスが悪くなる
翻訳用ファイルの文字列だけで翻訳しようにも文脈がわからないと適切な訳語にできるかわからない
短い単語だと、英語の文字列単位なので、内部のあちこちで使い回されているので、余計適切な訳語が考えにくい。予想外のところに使われてて意味が通らない、等ということもありそう。
などが気になってきます。
これらの取り扱い方のゆらぎなども出てくるとちょっとキリがない気が。

一応、
Translating TrueNAS UI
https://github.com/truenas/webui/blob/master/docs/contributing_translations.md
で示されているように
一部の文字列はプレースホルダ（Placeholder Tokens）として文中で使えたり、
複数形を処理する書式（Plural Forms）が利用できたりするようですが、
どちらかというと日本語は数によって形が変わらない方の言語かなと。
（日本語おかしいよ項目の代表「ひとつ」「ふたつ」…はどうしても使わなければならないという局面は思いつかない）

ので目立つところなどを少しずつ翻訳してプルリクエストを送るのがいいのではと。

プルリクエストがマージされると、次のNightlyに組み込まれますので、
マージされた後のNightlyで確認することができます。

とはいえ、どのように翻訳が反映されるか手元で確認したいとは思いますので、

Setting Up Development Environment
https://github.com/truenas/webui/blob/master/docs/setup.md

をやってみます。

TrueNAS SCALE の翻訳環境を構築する（yarn + Node.js）

GitHubでプルリクエストを送る方法はまだ試行錯誤中なので他のえらい人の情報を参考に…。

フォークして
ローカル環境にクローンして
編集して
コミットして
プッシュして
プルリクエストを送信

みたいな流れだと思うんだけど、
自分の作業中にUpstream側の更新があったりすると、
コンフリクトを解消するのに気が遠くなるときが…。
（たぶんNightlyからのリターンが反映されるタイミングがあると思うんだけど、そのときに自分が触ってないファイルで大量にコンフリクトがレポートされるとナケル。あと、 ja.json ファイルの単語の並びが「翻訳語（右辺）なしのアルファベット順」→「翻訳語ありのアルファベット順」という形に並べ換えられるようなので、ローカルの翻訳ファイルとマージするのが大変なので、プルリクが反映されたら手元のファイルは処分してクローンし直すのがいいかも）

こまめにプルして同期させておくか、
そんなときは最悪翻訳ファイルだけ退避して、
ローカルのリポジトリをいったん削除してクローンし直した方が早いのでは？
って感じてる。

1行だけ、、とかならオンラインエディタで編集してそのままプルリクエストを送信、みたいな感じっぽい。
（プルリクエストを送信するには自分のフォークは必要みたい）

---

少し翻訳を追加してみて考えたことなどまとめておきます。

日本語化運用上の懸念点・課題

(1) 日本語UIユーザー層の技術理解度の幅広さ

日本語UIを選ぶ層は、英語が苦手＝技術的理解も浅いケースが多い。 意味が曖昧な翻訳や、専門用語がわかりにくいままだと、誤操作・設定ミスのリスクが高まる。

(2) 日本語リソースが整備されていないことによるサポート困難

マニュアルやWeb上の情報は英語ベースが多く、日本語UI利用者がトラブル時に自己解決しにくい。 コミュニティでも「UIの日本語表記」と「英語マニュアルの用語」が食い違うと、質問・回答がかみ合わない。

(3) バージョンアップでの翻訳のズレ

UI変更に伴う未翻訳部分や、古い訳語がそのまま残ることがある（技術的負債）。 翻訳と実装が常に同期していないと、日本語UIの品質が維持できず、混乱の元になる。

(4) 不完全な翻訳による信頼性低下

画面の一部だけが英語のまま、誤訳が含まれる、という状態が続くと「UI全体の信頼性」が損なわれ、逆に日本語をOFFにする人が増える可能性もある。

つまり日本語化言語ファイルは、初心者が最初に日本語化して使うことが想定されるが、ある程度以上の情報は結局日本語環境では提供されないので、習熟に伴い日本語環境は使われなくなっていくことを考えると、いったん日本語環境で慣れてから英語環境に切り換えるより、TrueNAS SCALE の UI は英語のまま、日本語の説明サイトなどを参考にしたほうがいいのでは？
（と前から思ってる）

日本語対応の方向性

1.用語統一のガイドライン策定（例：用語集＋使用例付きスタイルガイド）
2.翻訳者が画面全体を確認できる環境の整備
3.UI表示と翻訳のフィードバックループの確保
4.初心者向け説明の補強（ツールチップや「i」アイコンの翻訳も含め）
5.ユーザー向け・翻訳者向けドキュメントの日本語整備

基本方針

既存の翻訳をこの方針に従って見直したりはしていないですが、翻訳中に気になった点などをChatGPTを使って整理してみました。

項目	方針
技術用語	意味が定着しているものはカタカナ（例：スナップショット） わかりにくいものは補助的に訳語併記も検討（例：Replication＝レプリケーション（複製処理））
操作用語	ユーザーの行動を反映しやすい動詞＋目的語型で統一（例：「プールを作成」）
敬語・文体	常体（です・ます調は使わない） 命令形よりも説明形優先（例：「削除してください」ではなく「削除する」）
UI制約	ラベル・ボタンは簡潔に（4～6文字程度目安）、 ヘルプや説明文は柔軟に

用語対応表（主要項目）

英語表現	日本語表現	備考・翻訳意図
Pool	プール	データの論理的なまとまり。ZFS用語として定着。
Dataset	データセット	技術用語としてそのまま使用。
Snapshot	スナップショット	状態保存機能。IT文脈で定着済み。
Replication	レプリケーション（複製処理）	訳語だけでは伝わりにくいため括弧補足も検討。
Volume	ボリューム	データ格納領域、曖昧な場合は「Zvol」などと区別を意識。
Share	共有	SMB/NFS/iSCSI共有などに広く使用。用途によって補足あり。
Mount Point	マウントポイント	Linux関連用語として定着済。
Middleware	ミドルウェア	一般IT用語として使われているが、説明的に補足する余地あり。
Warning	注意	Alertより緊急度が低い印象。
Alert	警告	緊急度が低いものも含むため、必要に応じて「通知」と区別。
Critical	重大	エラーやシステム障害レベルに対応。
Submit	送信	ボタンラベルでは「適用」や「保存」と訳す場合も。
Rollback	ロールバック	スナップショット復元機能として理解されやすい。
Jail / Container	ジェイル / コンテナ	SCALEではコンテナ用語が優先される。JailはCORE特有。

検討中の用語

出現する場所の文脈により訳語の検討が必要かもしれない。

用語	候補	コメント
Export	エクスポート／取り出し／切り離し	文脈によって意味が異なるため要検討
Enable / Disable	有効化／無効化 or ON/OFF	トグル型スイッチの場合、ON/OFFも視認性あり
Service	サービス／機能	Linux的な「デーモン」と誤認される場合も
Apps	アプリ	一般的な「アプリケーション」と誤認される可能性あり
Train	トレイン	日本語での適切な訳語の候補がないがカタカナにしてもそれ自体の意味が伝わりにくい

翻訳対象外用語リスト（除外語彙集）

翻訳せずに元の英語表記のまま使用したほうがよさそうな語彙集の案です。
アルファベットでの表記の方が定着していてわざわざカタカナにするべきではない用語と、
1単語中に2文字以上の大文字を使用しているものは、頭文字をとった略語か、商品名などと考えられ、カタカナにしない方がよさそうです。

対象パターン	例	翻訳可否	理由・備考
すべて大文字の頭字語（Initialism / Acronym）	ZFS, SMB, LDAP, UPS	❌ 翻訳不可	技術的に定着した略語であり、翻訳すると意味や検索性を損なう
PascalCase / CamelCaseの技術用語・製品名	TrueNAS, TrueNAS CORE, TrueNAS SCALE, TrueCommand, OpenZFS, AuthToken, TimeMachine	❌ 翻訳不可	固有名詞・ブランドに属するため翻訳によって意味が不明確になる
構成ファイルやキーファイル名	ups.conf, id_rsa, authorized_keys	❌ 翻訳不可	OSやサービスの標準ファイルであり、名称変更は誤解を招く
システム標準ポート名／プロトコル名	SSH, NFS, HTTP, HTTPS, iSCSI	❌ 翻訳不可	翻訳すると誤解・接続エラーの原因となる。英語表記が国際的に通用
OS/ソフトウェア内のUI用識別語	Dataset, Zvol, Jail, Container	❌ 翻訳不可またはカタカナで使用	ZFSやLinuxにおける専門用語。翻訳語が混乱を招く
コマンドや設定ディレクティブ	cron, rsync, systemd, fstab	❌ 翻訳不可	そのまま使わないと設定時に誤動作・誤解を招く
既に一般的なカタカナ語として定着	スナップショット, ボリューム, レプリケーション	✅ カタカナ化して使用可	日本語での利用に違和感がなく、翻訳語として認知されている
Appleや他社製品の商標・サービス名	Time Machine, iCloud, Google Drive	❌ 翻訳不可	他社商標であり、訳語は存在しない（契約・法的観点からも不可）

ふと思い立って他の言語の翻訳状況はどのぐらいなのか、ChatGPTに調べてもらいました。
言語ファイルの右辺がある＝翻訳済み、とみなして数えてもらっています。
なお調べた対象は、マージされたプルリクエトがある言語ファイルの更新が新しい方から3ページぐらいまでに出てくるものです。

言語	コード	翻訳済	Total	進捗率 (%)
日本語	ja	954	5243	18.20％
韓国語	ko	5205	5238	99.37％
イタリア語	it	5162	5243	98.46％
アイルランド語	ga	5161	5243	98.44％
スペイン語（アルゼンチン）	es-ar	5091	5243	97.10％
簡体字中国語	zh-hans	4773	5243	91.04％
フランス語	fr	4058	5238	77.47％
ロシア語	ru	4364	5239	83.30％
チェコ語	cs	991	5243	18.90％
ブラジルポルトガル語	pt-br	79	5243	1.51％

日本語は1000弱しか翻訳が完了していませんがぱっと見える部分は大体終わってます。