翻訳作業についてのガイドラインです。それぞれの項はl.d.oの参加者による議論の上で決定されます。
異議がある場合、このwikiを直接訂正せず該当スレッドにコメントしてください。

翻訳の原則
http://drupal.org/node/13220 で,"Linux for Schools: Localization and Translation" からの引用で以下のような文章が紹介されている。

Your task is ... to convey the content, so do not be afraid to localize the original text with something completely different (something that fits, of course). Read the original text, understand its content, and consider how you would formulate the text in your language (without first having heard of the original text).

つまり,word by word で訳すよりも,意味が伝わるように訳した方がいい,ということだと思う。英語のオリジナルの表現を正確に訳すことよりも、使用者が分かりやすく使いやすいインターフェースを提供することを目指す。

語尾の長音符号を付加する/しない判断基準
原則として最後の長音符号を付加する(例:コンピューター)。
語が拗音で終わる場合、長音符号は省略(例:エンティティ)。ただし、長音符号を付加するほうが一般的と思われる語に関してはその限りではない(例:マネージャー)
(参照:このwikiのコメント欄。後に翻訳スプリント in Tokyo #2の参加者が作業中に議論の後決定)
モジュール名の翻訳
モジュール名は原則訳さず、[モジュール名]+'モジュール' と表記する。(例: 原文: ImageCache 訳文: ImageCache モジュール)ただし、モジュール名のみがメニューのラベルになっていたり、それだけが一文字列となっている場合など、訳した方が良いと思われる場合を除く(参照: http://localize.drupal.org/node/1233
日本で浸透していない語の翻訳
原則翻訳せず、カタカナ表記にする。(参照: http://localize.drupal.org/node/1403 , http://localize.drupal.org/node/1418 )
もとの言葉の意味を検索したい場合に、訳されていると難しいため。
当 l.d.o./ja で採用している、単語ごとの訳
インストールされた Drupal を、複数の貢献モジュールも含めて一つのソフトウェアとして使う際のユーザビリティを高く維持するため、当 l.d.o./ja では一部の文字列(string)に対して公式の訳語を採用している。これらは対訳表で確認することができる。
既存の訳を変更したい場合
“翻訳相談所: ”から始まるタイトル、“tco-ja”タクソノミータームを持つの story ノードを立て、コミュニティで相談する。(参照: http://localize.drupal.org/node/604 , http://localize.drupal.org/node/848 , http://localize.drupal.org/node/878 )なお、新しい提案がコミュニティで承認された場合は、必要に応じて対訳表の更新も行う。
日本語・半角英数字が混在した文章
全角文字(日本語)と半角英数字との間に半角スペースを挟む。(参照: http://localize.drupal.org/node/2994
クォーテーションマーク
http://localize.drupal.org/node/2999 で相談継続中
いくつかの固有表現についてのコミュニティにおける取り決め
× 下さい → ○ ください
× 出来る → ○ できる
× 全て → ○ すべて
(参考: http://localize.drupal.org/node/3004
Groups audience: 

Comments

当該サイトに内閣告示と異なる例として以下のようにあります。

>つまり,JISでは「ユーザ」,内閣告示では「ユーザー」という表記が原則ということになります。一般に,技術系の業界ではJISに準拠し,マスコミ等は内閣告示に準拠しているようです。

該当する語に「ユーザー」、「スーパー」、「ラッパー」、「セッター」などがあり、技術系でもJIS様式に従って3文字にしてしまうと違和感があったり、まったく別の意味に聞こえる単語もあります。いずれにしても、慣用語についてどうするかも決めておく必要があそうですね。

個人的にはJIS系の3文字以上を4文字以上というのが好きですが、CMSを使う人は技術系だけとは限らないと思うので内閣告示のほうが良いのかもしれません(もちろん慣用語優先で)。

2008年7月28日の話ですが
http://www.itmedia.co.jp/news/articles/0807/25/news090.html
http://drupal-jp.sourceforge.jp/main/node/125

「新表記は、国語審議会の報告をもとに告示された内閣告示第二号(1991年)をベースにしたもの」とのことです。
圧倒的多数の人は(私も含め)良かれ悪しかれMSの表記を見慣れていることから考えると、
一つの参考にはなるのではないでしょうか。

@kuwamura / @ryo
情報ありがとうございます。個人的には最後の長音符号がぶった切られているのは、以前からかなり腑に落ちないでいたので、切らなくても良いのは嬉しいです。いっそのこと-er/-orなどで終わる言葉全部に長音符号を付けることにしたほうが、翻訳作業は楽になると思います。例外を作ると、その一貫性を保つ手間が増えるので。利用者としては、意味さえ分かれば長音符号のある/なしは大した問題ではないのかもしれませんが。

これもまた投票になる場合:
1.JISに従う
2.内閣告示の原則(長音符号を付ける)に従う
3.長音符号を付加する/しない語を選定、同時に未定義の語に将来対応するための規則を作る

という三つの候補に対する投票になると思います。

僕は圧倒的に2番を指示するので、2番に5票くらい投票しておきます :)

ちなみに、どの候補であれ決定がなされた後には、既存の翻訳を見直す必要が出てきますね。

「外来語カタカナ表記」で
Google検索すると
一般財団法人テクニカルコミュニケーター協会
http://www.jtca.org/
から発行されている
外来語カタカナ表記ガイドライン第2版 制定:2008年3月
http://www.jtca.org/ai_collaboration/katakana_wg/katakana_guide.pdf
というのがトップで出てきますね。
3.長音符号を付加する/しない語を選定、同時に未定義の語に将来対応するための規則を作る
の規則を我々で一から作るのではなく、こうしたガイドラインに従うというのも一つの案かとも思います。

僕としても長音記号は付けた方が良いと思っていました。
実はこっそり「ユーザ」→「ユーザー」に変えていたり。
なので僕は内閣告示の方を支持しますね。

@ryo
「ただ語尾伸ばせばいいんじゃないの?」とテキトーに考えていたけど、実際にこのガイドラインを読むと色々考慮する必要があることに気づかされました。ありがとうございます。

このガイドラインに従うのは理想なのですが、そうすることで敷居が高くなり、参加を躊躇する人が出たり、翻訳に時間がかかってしまうことを懸念しています。

個人的にはD7の翻訳を終わらせることが現時点での課題だと思っています(もちろんこの視点を他の参加者に押し付けるつもりはありません)。そのため当面は内閣告示の原則に従う形を取り、次以降のフェーズで、クオリティを向上するための取り組みの一環としてこのガイドラインに従うのが良いと考えます。

今まで深く考える事なく,「コンピュータ」とか言って/書いていました。

もとの英語の綴りは,computer とか user とか最後に er などが付いていて,そこに伸びる音があることを示しているように思います。オリジナルの英語の発音に倣って,カタカナ表記でも長音符号を付けるべきだと感じました。

ということで,タイトル通り,長音符号をいつも付けるに +1 です。

P.S.
とは言っても,所詮英語にある音は日本語にないものもあって,完全に英語の発音をカタカナで表現するのは不可能でしょうし,それを試みると今までの外来語(カタカナ語)と違ってきて実用に向かなくなる可能性が高いでしょう。そのあたりは柔軟な判断が必要かもしれません。

相当これは昨日悩みました。

知らずに最初帰国したころは長音符をいつも付けてたのですがウェブ開発を日本語でするにつれ、
”ユーザーマネージャー” とか長音符が重なるテキストとか、特にボタンテキストを見て技術系として耐えられずJIS派になってた事になります。長音符があるストリングが三つ以上あるボタンなど想像するだけで長音符を削除したくなります。

しかしこのスレッドを読んで考えた結果、Drupalはサイトをつくる道具であり、ようするにサイトに来る主に一般者に対してサービスを可能にするのが最終目的であり、一般者が一番見慣れてる物を管理者当が提供できるようlocalization活動は努力すべきだと現在考えています。

それは活動を器用に一般者が見るところと管理者(技術系)が見る部分によって翻訳の仕方を分けたりも出来ますが、ミス(JISを使用しないのが的確なところでJIS)が出る事を避けるには、人数が増えれば傾向も倍増するでしょうし統一しなくてはなりません。

そしてその統一は一番優先されるべきサイトの閲覧者になるので、ということで長音符をいつも付けるのに賛成です。

しかし、気持ちとしては見苦しい長いボタンテキストが出てきたらみんなで考えませんか?と言いたいところです。

p.s. ちょっとOTですが ”リポート” と ”レポート” も調べたらどちらもありなのですね。

今日,関西地区で翻訳スプリントが開催され,そこでは品質向上・品質保証を主眼として作業が行われる予定です。

品質について語る時,「高品質であるとはどういうことか」の定義,つまりここで話し合いがなされていた翻訳ガイドラインがないと作業にとりかかれないと思います。

そこで,Sun 日本語翻訳クイックリファレンスを当翻訳プロジェクトの暫定的なガイドラインとして採用してはどうでしょうか。

P.S.
借り物ではありますし,当コミュニティとしてきちんと検討・協議ができていない点は問題だとは思いますが,指標となるものが何もないよりは何かあった方がましだと思うので,提案してみました。本来ならば,関西スプリントの前に案を提案して皆さんと協議したかったのですが,時間がなくこんなに直前になってしまったことをお詫びいたします。

janvier さん:

このグループがオフ会仲間によるクローズドな組織かどうか、というのはあくまで主観的な議論です。私とあなたとがお互いに理解しあう努力をしない限りその議論から結論は導き出せません。だとすると、お互いに同意できる事実は「l.d.o. の参加者によって話し合いで決められる」という一点だけです。その参加者というものに誰でも入れるのか、それとも一部なのかは別にして。ですから、事実だけを記載するバージョンに戻しました。

これ以上、この点についての wiki の無駄な編集はおやめください。