オリジナルの文字列には、どう翻訳すべきか（またはそもそも翻訳すべきか）迷う言葉があったり、コンテクストにより訳語が変化する場合があります。この場を使って他のメンバーと相談することで、独断的な翻訳を避けてこういった問題を解決していければと思っています。ここで決定がなされたら、google spreadsheetなどの別の場所に移していきましょう。

In original strings, there are words which make us think how / whether we should translate. There are also words that change their meaning depending on the context. I suggest we consult with each other to resolve such issues and not to translate arbitrarily. Once the decision has been made, let's move the word to the google spreadsheet or other appropriate places.

###############
#
#　質問に対するレスポンスは、コメントとしてではなく、wiki内に記述してください。
#
#　Please add your responses within the wiki, not as comments.
#
#（本当はcase trackerなんかが向いていると思うのだけど、ここでは使えないのでとりあえずwikiを使ってみています。）
# (It's probably the best to use case tracker, but we don't have access to it here so I'm trying out wiki.)

◆コメントのフォーマット/comment format：
既に相当使いにくいことが判明しているけれど、少しでも使いやすくするために、以下の方法を試してみましょう/ It's already pretty obvious that this is not an appropriate tool for this, but let's try out the following format to improve the usability even just a bit：

[username],[time, time zone][yyyy/mm/dd] [comment]

例：dokumori, 00:26 GMT 2010/02/09 コメント
(タイムゾーンは、UTC+9（日本）以外の人が入力すればよいと思います。/enter time zone only if you are not in Japan (UTC+())

◆質問フォーマットは以下をご利用ください。（by Shin_ 14:23 2010/02/09）
↓ここから

質問者
（質問者の名前）
問題の語
（問題の語）
プロジェクト
（プロジェクト名、バージョン等）
疑問
（疑問の内容）
コメント＆ディスカッション

（コメント、提案、ディスカッションを書かれる方はここの部分へ。コメントのフォーマットも参照してください）
（コメンターごとの区切りを明確にするため、アカウント名の前に「●」を付加してください）

=========
↑ここまで

###############

Shin_ 14:20 2010/02/09
Wiki内へのコメントの書き方および定義リスト化に関するコメント、@dokumoriさんとの議論は、一応の合意を見たので削除しました。

=========

質問者
dokumori
問題の語
[解決済]fetcher
プロジェクト
Drupal 7.0-alpha1
疑問
フェッチャーと片仮名にしてしまうのが楽なのだけど、多くの人はその言葉をあまり聞いたことがないのでは？　読む人が'fetch'＝「取ってくる」という語幹の意味を知っていて、またそれから派生した言葉であることを理解してい無いかぎり、「フェッチャー」と書いてあっても何の意味も持たない。（でも、代わりになる日本語も見当たらない。。。）
どなたか提案ありますか？
コメント＆ディスカッション

●Shin_ Sun, 02/07/2010 - 17:17

1) fetcher
fetch はもっと細かく言うと（dokumoriさんに大変僭越ですが(^^;;）「なにかを（どこか他の場所へ／から）行って取ってくる」という意味ですよね。
Gmail にも Mail Fetcher という機能があって、これは日本語版では「別のアカウントからメールを受信」と（一言ではなく細かい説明に）なっています。
Drupal 7 における fetcher の機能がわからない状態で正しい翻訳をするのは無理なので、「これはどぉ？」ってピンポイントの提案はできないのですが、「受信する」をベースにいい訳ができれば、と思ったりします。

あるいは、意外と、“フェッチャー”で押し通しちゃうのも手かもしれないですけどｗ

●fuji@drupal.org - Sun, 02/07/2010 - 20:23
fetcherってUbuntuでいうアップデートマネージャーみたいなものですか？
それだと、”アップデートマネージャー”、”更新マネージャー”、”更新管理ソフト”など機能関連を表す翻訳はいかがでしょう。個人的に解りやすくコンパクトで癖の無い”更新マネージャー”というような表現スタイルがお気に入りです。

●fuji@drupal.org - Sun, 02/07/2010 - 20:30
考えたところ、今後日本でリリースされるDrupal本とかでは”フェッチャー機能”とはという表現で説明がありそうなので、ひとつのDrupalのブランド的な用語でもあると想定すると一概に的確な翻訳をすることもない時もあるのだなと思いました。難しいですね。

●Shin_ - Mon, 02/08/2010 - 06:35
上で書いたように、よく機能がわかってない状態では迂闊なことは言えませんが（笑）、回りくどい日本語になってしまうようなら、僕も“フェッチャー機能”のままがいいような気がしています。

●dokumori - 00:00GMT 2010/02/16
googleで"フェッチャー -google"と検索したら、フェッチャーというのは大体著者の名前くらいでしか出てこなかったです。ということはGoogleが使っている以外ではほとんどフェッチャーという言葉を利用していないということになります。
でもやっぱり訳しにくいので、フェッチャー機能で良いと思いますが、カッコ内に簡略な説明を付けるのも良いかと思います。

●dokumori - 21:52 2010/04/25
翻訳スプリント in Tokyo #2にて翻訳に反映しました

=========

質問者：
dokumori
問題の語：
[解決済]　aggregate / aggregation / aggregator
プロジェクト：
Drupal 7.0-alpha1
疑問：
この辺は、アグリゲート／アグリゲーション／アグリゲーターで意味が通じるんでしょうか（自信なし）
コメント＆ディスカッション

●Shin_ - Sun, 02/07/2010 - 17:17
2）aggregate / aggregation / aggregator
これはもう、そのまま（アグリゲート／アグリゲーション／アグリゲーター）でいいのでは。最近、IT関連ではかなりよく使う／聞く／読む言葉です。
これも「意味を知らない限りわからない」と言われればそれまでですが、すでにそのままで多方面で通用しはじめている以上、（前に僕が別スレッドで書いた）訳し過ぎるとワケわかんなくなる言葉、の一つだと考えます。
Drupal の中でのみ使う用語なら独自の翻訳をしても構わないと思いますが、これはたぶんそうではないでしょうから。

●fuji@drupal.org - Sun, 02/07/2010 - 20:23
AggregateはAggregatorという言葉（無理やり作ったんですかね？）と統一感を持たせるため全部カタカナ、もしくはalphabetでそのままでしょうがないと思います。
個人的には日本人にとってそのままのalphabetが辞書で調べやすいので訳しづらい言葉はalphabetそのままで良いと思います（わからない言葉を辞書で調べるとしてもカタカナにしてしまうと一度英語に直すことになってしまいますので解らない人は解らない可能性があると思います。（機能を考え日本語にしてしまうとややこしくなってしまいますねこの場合）
aggregate / aggregation / aggregator　- 翻訳すると　xox統合/xox統合する/xox融合機能　ですか？
ちなみに何を融合するのでしょうaggregatorは？

●aiwata55 - Sun, 02/07/2010 - 22:58
>ちなみに何を融合するのでしょうaggregatorは？
aggregator は他サイトの Feed から自サイトのコンテンツを作成します。Feeds（へー，Feed API の開発って終わったんだ．．．）では Feed の一つ一つからノードを作成することも可能ですが，aggregator はたぶん aggregator ページのようなものを作成して，そこに最新のものだけを表示しているようです。
このような機能から，「自サイトと他サイトコンテンツとの融合」という意味でしょうかね。

●dokumori 00:26 GMT 2010/02/08
Shin_, fuji, aiwata55,意見ありがとう。訳しすぎで分かりにくくなるという意見、意訳をするという意見、両方とも正しく感じます。もう少し他の方の意見を待ちたいと思います。
個人的に感じるのは、外来語は無理矢理押し通したのち浸透するまで待つ、というのが特にテクノロジー関連の用語に関して、日本で見られるパターンな気がしています

●Shin_--:-- GMT 2010/02/08
言えてますｗ　またある意味それでいい部分もあるかも。

●Shin_ - Mon, 02/08/2010 - 06:57
自分自身のメモのために、あらためて調べてみたのですが（完全に理解しているとは思えなかったので）。
アグリゲーター（あるいは、アグリゲーションという作業）とは・・・（以下、iPhone 大辞林アプリより引用）
■〖contents aggregator〗コンテンツアグリゲーター 自社で運用するサーバーに音楽や対戦ゲームなどのコンテンツを収集し，ネット上で提供するサービス。単にアグリゲーターとも。
■【RSSリーダー 】〔RSS reader〕 インターネット上のニュース-サイトやブログなどから，見出しや概要の情報を収集して，それを表示するソフトウエアのこと。情報の収集にRSSを用いる。アグリゲーター。フィード-リーダー。
Drupalのそれはほぼ後者の機能ですかね。とにかく「インターネット上（の他サイト）から自サイトに必要な情報を収集し、集積した上で、自サイトに適切な形で一覧表示する機能・作業」のことをいうようです。
以上、ご参考までに。

●dokumori 00:06 GMT 2010/02/16
少しgoogleで検索してみましたが、確かに最近よく使われる言葉のようです。片仮名のままでいいかなー。

●dokumori - 21:52 2010/04/25
翻訳スプリント in Tokyo #2にて翻訳に反映しました。ただし、コンテキストによって意味が異なるので、既存の翻訳でカタカナ表記でなくても適切に翻訳されていると思われた（僕の主観です）ものはそのままにしてあります。

=========

質問者：
ytsuhako
問題の語：
　People
プロジェクト：
Drupal 7.0-alpha1
疑問：
Drupal6と7でユーザ関連の単語に変化があって悩んでいます。。
Users -> People、 User management -> People and Permissions、 User settings -> Account settingsとなっていて、user が people と account に別れています。
Peopleが「人々」、People and Permissionsが「人々と権限」ではおかしいですよね。「利用者」が分かりやすそうなのですがそれではuserと同じになってしまいます。。どなたかアドバイスをお願いします。
みなさん、はじめまして。英語は辞書を引きながらやっと読めるくらいです。よろしくお願いします。dokumoriさん、相談所の使い方はこれで正しいですか？
コメント＆ディスカッション

●Shin_ --:-- GMT 2010/02/08
@ytsuhako　はじめまして。よろしくお願いいたします。
日本語ではやはり「利用者 or ユーザー」のままですかねぇ。あえて合わせなくてもいいような気がしますが。
「People and Permissions」が「ユーザー（利用者）／アクセス権設定」、「Account settings」はそのまま「（ユーザー or 利用者）アカウント設定」でしょうか。

●aiwata55, 17:23 GMT 2010/02/08 (02:14 JST 2010/02/09)
そのまま「人々」「人々と権限」ではないでしょうか。耳慣れないので大きな違和感を感じるのは確かですが．．．
http://www.d7ux.org/information-architecture-strategies/ および http://drupal.org/node/536612 によると，D7 における People は User 以外の「人に関係した存在」までもカバーする概念である，と説明されているような気がします。例として，ある Drupal サイトがイベントのノードを持っていて，そのイベントへの参加者なども含まれる，とあります。おそらくここで挙げられた例では，このイベント参加者たちはこのサイトの登録ユーザーではないのでしょう。似た例として，Ubercart では Anonymous user でも買い物ができる機能があります。物理的な商品である場合には当然個人情報，配送先情報，支払い情報などを入力しなくてはなりません。このとき，購入者はユーザー登録をすることもできますが，登録をせずに一度限りの買い物をすることもできます。User という概念は前者の場合にはカバーしますが，後者の場合はカバーしません。しかし People という概念では前者も後者もカバーされます。

●dokumori, 00:26 GMT 2010/02/09
相談所の使い方はこれで正しいけど、えらい読みにくくてすみません。一語一ストーリー+'consultation'タグなんかが良いのかも。でもとりあえずこれで試してみましょう。
aiwata55さんの提示したリンクはこのページ(http://drupal.org/node/538526 )のduplicateとされいるので、こちらのほうがより詳しいです。UX expertとしてのleisaとDrupal expertとしてのcatchのやり取りは非常に興味深いですが、technical implicationsが大きすぎることもあり(comment #14)、最終的には'UI issue'というところで落ち着いています(comment #33)。僕としては、「人々」というのがどうしても違和感があること、それから#15のkaakuuのまとめコメントに：
# There are problems in translation-ability. Multilingualwise users is acceptable, respectable, concise,clearとあるところから、ユーザーと訳す方に+1です。

●Shin_, 11:07 JST 2010/02/09
aiwata55さん、詳しい説明・参照サイトのご紹介ありがとうございます。ふむ、なるほど。
ただやはり、そうだとすればするほど正確な訳がむずかしくなりそうですね。「人々」と書いて、Drupal 7 で制作されたサイトの制作者も閲覧者・利用者もそのちゃんとした意味を理解できるとは思えません。「利用／閲覧者」みたいなのも固いですしねぇ。
ということで、僕も「ユーザー」のままが（完全には正しくないとしても）妥当なんじゃないかという気もします。

●Shin_, 14:55 JST 2010/02/09
@dokumoriさんの紹介してくださったページをなんとか一通り読んでみました（英語の議論は辛ぇぇｗ）。
で、僕も同じく#15のkaakuuのまとめコメント（http://drupal.org/node/538526#comment-1883666）中のdokumoriさんの引用部分の続きですが、
# Tech problems of linkrot, serious search problem as Drupal searches users only, NOT people

# Huge mass from all prominent CMSes (if or when they migrate) are already accustomed to 'users'
にも激しく同意です。

●ytsuhako, 21:28 JST 2010/02/10
みなさんコメントありがとうございます！私も@dokumoriさんが紹介してくださったページを読もうとしたのですが、、ほとんどわかってないです。。
ただ、drupal7を開発している方々はpeopleという単語に変更することには検討もしたし覚悟？もあるようにも思えますのでサイトに登録されているユーザだけじゃないことを明確にするために「人々」がいいかなと思っています。ちなみに中国語の翻訳ではuserと同じ単語が、ハンガリー語ではuserとは違う単語が使われていました。

=========

Groups audience: 
Japanese team
⋅ Categories: tco-ja

Comments

Shin-gdo_J commented

1) fetcher
fetch はもっと細かく言うと（dokumoriさんに大変僭越ですが(^^;;）「なにかを（どこか他の場所へ／から）行って取ってくる」という意味ですよね。
Gmail にも Mail Fetcher という機能があって、これは日本語版では「別のアカウントからメールを受信」と（一言ではなく細かい説明に）なっています。
Drupal 7 における fetcher の機能がわからない状態で正しい翻訳をするのは無理なので、「これはどぉ？」ってピンポイントの提案はできないのですが、「受信する」をベースにいい訳ができれば、と思ったりします。
あるいは、意外と、“フェッチャー”で押し通しちゃうのも手かもしれないですけどｗ

2）aggregate / aggregation / aggregator
これはもう、そのまま（アグリゲート／アグリゲーション／アグリゲーター）でいいのでは。最近、IT関連ではかなりよく使う／聞く／読む言葉です。
これも「意味を知らない限りわからない」と言われればそれまでですが、すでにそのままで多方面で通用しはじめている以上、（前に僕が別スレッドで書いた）訳し過ぎるとワケわかんなくなる言葉、の一つだと考えます。
Drupal の中でのみ使う用語なら独自の翻訳をしても構わないと思いますが、これはたぶんそうではないでしょうから。

以上、ちょっと思うところを書いてみました。ま、こんなふうに一個一個ボチボチやっていければな、と(^o^)／
ではー。

Shin
// I thought that I should have done what I could do even if those were the mere small things at the beginning, because I have been so much moved with the former comments (made under the other thread) by aiwata55, our manager. Thanks.

xbro commented

fetcherってUbuntuでいうアップデートマネージャーみたいなものですか？

それだと、”アップデートマネージャー”、”更新マネージャー”、”更新管理ソフト”など機能関連を表す翻訳はいかがでしょう。個人的に解りやすくコンパクトで癖の無い”更新マネージャー”というような表現スタイルがお気に入りです。

AggregateはAggregatorという言葉（無理やり作ったんですかね？）と統一感を持たせるため全部カタカナ、もしくはalphabetでそのままでしょうがないと思います。個人的には日本人にとってそのままのalphabetが辞書で調べやすいので訳しづらい言葉はalphabetそのままで良いと思います（わからない言葉を辞書で調べるとしてもカタカナにしてしまうと一度英語に直すことになってしまいますので解らない人は解らない可能性があると思います。（機能を考え日本語にしてしまうとややこしくなってしまいますねこの場合）

aggregate / aggregation / aggregator　- 翻訳すると　xox統合/xox統合する/xox融合機能　ですか？

ちなみに何を融合するのでしょうaggregatorは？

広い意味で簡単な漢字を的確な場所で使うのは一つのpointだと思います（漢字はコンパクトなので）。後、カタカナは無理して使うべきではないと思います（e.g. imageをイメージなどとすると意味が二つになり、画像という翻訳の方が的確です）。

以前別のソフトでlocalizationしたことありますが、何の機能（ボタン、labelなども）に関して翻訳してるのか理解が必要な時は確実にある時はあると思います（でないととんでもない翻訳になってしまう場合や、ボタンテキストに適しないテキストなどが）。解らない場合は何の翻訳をしてるのか話し合うべき時は翻訳する前に皆様に相談して見るのは良いpracticeかもしれません。

edited：ボタンテキストであればやたらとカタカナを使用した方がいいと思います。

xbro commented

考えたところ、今後日本でリリースされるDrupal本とかでは”フェッチャー機能”とはという表現で説明がありそうなので、ひとつのDrupalのブランド的な用語でもあると想定すると一概に的確な翻訳をすることもない時もあるのだなと思いました。難しいですね。

Shin-gdo_J commented

上で書いたように、よく機能がわかってない状態では迂闊なことは言えませんが（笑）、回りくどい日本語になってしまうようなら、僕も“フェッチャー機能”のままがいいような気がしています。

aiwata55 commented

imageをイメージなどとすると意味が二つになり、画像という翻訳の方が的確です

これはとてもいい指摘だと思います。日本語でイメージといった場合，映像という意味と，想像による形・印象という意味の二つの意味があり，ここで使われる image の持つ本来の意味（映像，画像）という意味からちょっと離れてしまい，ユーザーに解釈の自由を与えてしまいます。こういう訳語は極力避けるべきでしょうね。

機能関連を表す翻訳はいかがでしょう。

これもいいですね。Translation guideline handbook の冒頭に，Linux の翻訳ガイドラインからの抜粋が載っていますが，「一語一語を正確に訳す事をこころがけるより，その言葉の持つ意味を訳すようにすべき（意訳）」と書かれています。英語をそのまま訳しても意味が伝わりにくい場合，その機能を説明するというのは一つの選択肢かもしれません。

ちなみに何を融合するのでしょうaggregatorは？

aggregator は他サイトの Feed から自サイトのコンテンツを作成します。Feeds（へー，Feed API の開発って終わったんだ．．．）では Feed の一つ一つからノードを作成することも可能ですが，aggregator はたぶん aggregator ページのようなものを作成して，そこに最新のものだけを表示しているようです。このような機能から，「自サイトと他サイトコンテンツとの融合」という意味でしょうかね。

Shin-gdo_J commented

自分自身のメモのために、あらためて調べてみたのですが（完全に理解しているとは思えなかったので）。

アグリゲーター（あるいは、アグリゲーションという作業）とは・・・（以下、iPhone 大辞林アプリより引用）

●〖contents aggregator〗コンテンツアグリゲーター 自社で運用するサーバーに音楽や対戦ゲームなどのコンテンツを収集し，ネット上で提供するサービス。単にアグリゲーターとも。
●【RSSリーダー 】〔RSS reader〕 インターネット上のニュース-サイトやブログなどから，見出しや概要の情報を収集して，それを表示するソフトウエアのこと。情報の収集にRSSを用いる。アグリゲーター。フィード-リーダー。

Drupalのそれはほぼ後者の機能ですかね。とにかく「インターネット上（の他サイト）から自サイトに必要な情報を収集し、集積した上で、自サイトに適切な形で一覧表示する機能・作業」のことをいうようです。
以上、ご参考までに。

Shin

Shin-gdo_J commented

>個人的には日本人にとってそのままのalphabetが辞書で調べやすいので訳しづらい言葉はalphabetそのままで良いと思います（わからない言葉を辞書で調べるとしてもカタカナにしてしまうと一度英語に直すことになってしまいますので解らない人は解らない可能性があると思います。（機能を考え日本語にしてしまうとややこしくなってしまいますねこの場合）

これはおっしゃるとおりですね。カタカナから英語の綴りがわからない場合があって苦労する場合が結構あります。Googleだと少し間違った綴りなら「もしかして？」で正確なのがわかる場合もあって素晴らしいんですけど。
ただ、Drupalというツールを使う上で、やはり英語のままというのはどうなのかな、という思いもあります。結局それって翻訳を放棄することになるとも言えるワケで(^^;;　英語じゃわかりにくいから翻訳するわけですし。
やはり、“訳さない”としてもカタカナにはすべきなのかなぁ、と。いまとりあえず検索さえできればカタカナから英語がわかるとも思いますしね。

アグリゲーターはそのままがいいなぁ、僕は。「xox融合機能」じゃかえってよくわからん(^^;
＃最初、“亜久里ゲーター”だって。これだからF1ファンは（笑）

Shin
//「機能を考え日本語にしてしまうとややこしくなってしまいますねこの場合」＜“ネコの場合”と一瞬空目ｗ

dokumori commented

wiki内にコメントする際のフォーマットを提案しました。同時に、今までのコメントにもそれを適用しました。こういうのを焼け石に水というのかな。。。

Shin-gdo_J commented

ユーザー、時間帯等のフォーマット、少しでもわかりやすくなるからいいと思います。
焼け石に水、ってことはないと思いますよ。

で、定義リストですが「めんどくさー」って言われてしまいましたがｗ、言い出しっぺとして懲りずに実際にやってみました。
いかがですかね？　上にも書きましたが、これも少しはわかりにくさの解消に寄与しているように思うんですが。

それと、たとえば fetcher のなんかのコメント、Wikiの中に移しておいた方がいいんでしょうかね。
っていうかそうしないと、せっかくのフォーマットに合わないと思うので、よければ僕が暇をみて移しておきます。

Shin

dokumori commented

@Shin_
フォーマット、どんどんお願いします、と先程wikiのほうに書き込んだのだけど、wikiではどこにコメントが追加されたか分かりづらいですね。

dlタグは良いですね（めんどくさいというのは冗談ね）。できればfetcherに関するコメントは、時間のあるときに移動して頂ければ幸いです。

ただ、新規コメントがどこに付いたのか分かり辛いという意味で、やっぱりストーリーに質問を書いて、提案をコメントで投稿、という形の方が良さそうな気もします。revision同士のdiffもできないみたいだし。。。

Shin-gdo_J commented

いまあるのから少しずつ定義リスト化してみます。

@dokumori
たしかにコメント（コメント機能の方）に書かないと新規投稿はわかりづらいですね。Wikiに修正加えるとメール通知が来るのはいいんだけど、いつも先頭の同じ文章が届くのもねぇｗ
めんどくさくなきゃ、コメントに書かれたのを逐次Wikiに移す、というのも手なんですけど。
Wikipediaの機能に慣れちゃってると、diffできなかったりするのもなんともねぇ。ちょっとした修正だと本人以外に違いがまったくわからない(-_-;)

Shin-gdo_J commented

いまあるものをリストの中に入れました。
fetcher、aggregator などについて、ひとつのコメント欄中に複数のことが書かれているものは、適宜分解してそれぞれの用語のところに記載させていただきましたので、発言者の方は悪しからずご了承下さい。

作業していて思ったんですが、それぞれの用語についての意見・提案等はWikiのそれぞれの場所に、それ以外の広範で全般的な内容（そもそも英語をカタカナ化するのか、意訳するのか、とか）については下のコメント機能（コメント欄）を使う、といったふうにするといいかもしれません。

あと、発言時刻のフォーマットに関して、このコピペ分については面倒なのでコメント欄の記載形式（例：Shin_ - Sun, 02/07/2010 - 17:17）をそのまま使わせていただきました。

xbro commented

fetcherなどはたぶんDrupal特有のITvocabだと思うのですが、他にもそうと予想してるAggregatorなどのDrupalVocabに関して結論を述べます。

Drupal特有のITvocabは英語の本目次や調べて確実にidentifyして、それは絶対カタカナの当て字で翻訳しなければなりません。これはintegrity例えば日本語ユーザと海外ユーザのコミニケーションなどの面でとても大事な要素だと考えています。

例えばDrupalのフックをフック以外の言葉で訳してしまって、それが日本で定着してしまった場合、その後日本のユーザは海外のDrupalユーザにフックと言われて何の事か解らないという一応責任問題的な現象が起きてしまいます。

よってDrupal特有のITVocabは確実に表に定義する必要性を感じます!

p.s. wikiで何が起きてるのか解らないので時間がたって意味が薄れた自分コメントは積極的に削除して行きませんか？
内心わけ解らんwikiになりつつあると思います。

xbro commented

ちなみにwikiにコメント出来るって新しく、待ちわびてた機能ですよね！

Shin-gdo_J commented

>p.s. wikiで何が起きてるのか解らないので時間がたって意味が薄れた自分コメントは積極的に削除して行きませんか？
内心わけ解らんwikiになりつつあると思います。

Wiki自体の中のコメントですよね？　中で議論？して決まったこととか。
そうそう、同感なのでいまから消します。＠dokumoriさんのもまとめて消させていただきますよーｗ

あと僭越ですが。

>結論を述べます。

いやいや、それをおひとりで“結論づけて”はいけない(^_^)ゞ
主張に関してはおおむね同意ですが(^_^)v

ryo commented

ちょっと他の言語のを見てみたのですが、
l10n-server-言語の頭文字
以外のタグを付けているところもいくつかありました（どういう意味のタグなのかはわかりませんでしたがw)。

で、提案なのですが、議論の対象となる文字列毎にノードを作成し、
「翻訳相談所」または「tco-ja」というタグ（タクソノミー）を付与するのはどうでしょうか？
どんなタグを作ったところで
ttp://localize.drupal.org/taxonomy/term/番号
という形で自動的にターム番号が付与されるだけみたいです。

こうすれば、皆さんご存知のように「翻訳相談所」に分類されるノードだけを必要に応じて参照できるようになりますし、
議論の対象となる文字列毎（ノード毎）にコメントが付けられてわかりやすいと思います。

ただ、新しく動きのあったものが上に来るという表示になるとは思うので、そのあたりのユーザビリティの問題は残りますが・・・。

Shin-gdo_J commented

>議論の対象となる文字列毎にノードを作成し、

たとえば、fetcher、aggregator などの用語（文字列）ごとに、別々のトピ（ノード）を立ち上げるということでしょうか？
ご自身でおっしゃってる問題は出てくるかと思いますが、今後沢山の文字列について議論する必要があるとすると、その方がいいのかもしれないですね。
現状の3つ程度でもどんどん長くなってるわけですし。ここひとつじゃとても足りないかも。

そもそもそうなっていくと、この形式がいいのかも疑問ですが。

ryo commented

＞たとえば、fetcher、aggregator などの用語（文字列）ごとに、別々のトピ（ノード）を立ち上げるということでしょうか？
その通りです。

追記：ちょっと試しにこのノードに tco-ja のタグを付けてみました。
それから、別段、他の言語を参考にするまでもなく、FAQ とか japanese ubercart とか、ここでも使われていましたね。
失礼しました。

＞そもそもそうなっていくと、この形式がいいのかも疑問ですが。
すみません、このコメントの意味がよくわからないのですが・・・＾＾；

Shin-gdo_J commented

>>そもそもそうなっていくと、この形式がいいのかも疑問ですが。
>すみません、このコメントの意味がよくわからないのですが・・・＾＾；

舌ッ足らずですみません。たぶんdokumoriさんの書き込みだと思うのですが、wikiだと実はこういう議論には向いてなくて、case tracker かなにか（ほかにもいろいろあると思いますが）がいいのではないかなって話に呼応して書きました。
まあ、なにも議論しないよりは、あるツールでやった方がいいのは間違いないのでｗ、やれることをやっていきたいです。

あとは、『l.d.o. の問題点，要望 | localize.drupal.org』の要望が少しでも実現するのを願うばかりですかね(^^;

aiwata55 commented

グループのダッシュボードページに，日常の翻訳作業で頻繁に使うであろうコンテンツと，当グループに新規参加した人に役立つであろうコンテンツを掲載するスペースを作るため，l10n-server-ja タグを削除しました。

当コンテンツがダッシュボードに掲載されるべきと思われる場合は，お手数ですがタグを付け直してください。