訳語の共通化について

[Layzie]

@enja-oss/contributors

• カタカナの表記ゆれ Backbone#24
• Function Directivesの翻訳 Sass#11

以上で出ていますが、訳語の表記揺れをなくしプロジェクトで統一したものを
訳語としたいと思います。

自分の意見は下記になりますが、このissueは皆さんのご意見を伺いたいので立てました。

自分の提案としては上記issueでも書いてありますが、Rubyのgemsで提供されている
logalingを使ってみてはどうかと考えています。

メリットとしては

• 成果物(訳語辞書など)がgitで管理できる
• CUIで確認・追加などできる
• Vim/Emacsでは専用モードがあったりする。

デメリットは

• CUIの敷居が人によっては、若干高いかもしれない

かなと思っています。

そもそも論として上記のgemsを採用するとしても、訳語自体はどう決めるか…という
問題はあります。

ですので、手順として提案したいのは、

1. 各プロジェクト(またはREADME？)のWikiに対訳語選定のページ作成
2. 気になる単語・文章を各自logalingに登録していく
3. 各自がそのファイルを見て、議論の余地あるものをwikiに登録して選定
4. 3で決定したらlogalingに再登録

という感じかなーと思っています。

自分自身logalingはまだ使っていない為、このプロセスで良いのかはちょっと分かりません…。

また他に良いプロダクトや手順があれば、もちろんそちらを採用する形になると思います。

参考として、実際にlogalingでドキュメントを運用しているプロジェクトのリンクを貼ります。

https://github.com/mroonga/mroonga/tree/master/doc/locale/ja/LC_MESSAGES

[studiomohawk]

共通訳語の必要性、そしてその生成、運用をサポートするツールの導入に関しては利点は多いと思います。
そして、@Layzie さんの指摘通り、新ツールの導入、新フローの導入にはそれなりに障壁もあります。

en.ja OSSが掲げている目標の1つが「参加への敷居の低さ」だと考えており、「翻訳」という障壁は確実に取り払えない以上、可能な限り障壁を避けたい、というのもあります。

最終的に成果物に対してチェックをし、訳語や文体の統一を行うことはツールがあろうとなかろうと
避けられないと思います。これを踏まえて考えてみると、
成果として完成する前に、訳語の統一を計るのが楽になるようにするツールとしての導入はありだと思いますが、
参加者全員がそのツールを使いこなす必要はないと思います。

現時点の役割分担として、翻訳者、管理者、監訳者の3つが存在していますが、
翻訳プロジェクトの開始時にこれに加えて、品質向上委員会を発足させ、成果物に対する品質の向上に対するアクションを率先して行うというのも考え方としてはいいかなと。

その委員会の中で@Layzie さん提案のツールを使っての訳語の統一を図っていくイメージです。
その用語集に関しては別途個別でリポジトリを作るなり、READMEのWikiを使うなり全体的に活用していく、
という形にすればロングタームで考えると品質向上委員会のタスクの工数は減らせるのではないかと。

言わずもがなですが、主宰らしいことを一切していない私の意見はあくまでも一意見としてとらえていただき、
皆さんがどう思うか忌憚のない意見をいただければと思います。

[Layzie]

@studiomohawk

そうですね、こちら全員でツールを使ってくれというのは敷居が高くなると思いますので、希望制の品質向上委員会という案は素晴しいと思います！

訳語の統一のタイミング的に今だとBackbone.jsが一番やりやすいのかなーと思いました。(ある程度翻訳が出揃ってるので)

ちょっと自分のリポジトリで試してみて作業イメージを掴もうと思います。

引き続き、皆さんのご意見をお待ちしてます。

[japboy]

こんにちは。
定訳があると安心して作業を進められるかなと思います。私は翻訳経験が浅いので、共通語彙のデータベースがあれば一般的な訳語を探す作業が省け、作業がはかどりそうです。
logaling にも興味があったので、導入するようでしたら、是非使ってみたいです。