![Mozilla 翻訳 フォーラム一覧](templates/trans/images/logo_trans.png) |
Mozilla 翻訳 Mozilla Japan 翻訳部門では mozilla.org 全体の日本語化を目指して活動していました。 このサイトは 2022 年 1 月に終了しました。 Mozilla Japan コミュニティポータル から関連サイトをご利用ください。
|
前のトピックを表示 :: 次のトピックを表示 |
著者 |
メッセージ |
Orca
登録日: 2004年4月 20日 記事: 511 所在地: 関西
|
件名: ドキュメントのクラス名 投稿時間: 2004年9月18日(土) 16:31 |
|
|
もじら組の文書とか和訳ドキュメントで, いくつかのクラス名が決まってるっぽいけど, そのまとめと追加の要望です。
(もじら組の文書とゆーのは, 今後 Mozilla Japanにアレするために変更するよーなのを対象にしてるです)
こーゆークラス名のほうがよいとか, ここは統合/分割したほうがよいとか, 意見待ってます。
んで, 最終的にはスタイルシートを更新してほしいかも。
もじら組の文書:
- caution ・・・
注意を促すよーな文章に em要素が使われてたので, ここは新たに設けるべきかもってことで。 注意を促す文章, 警告文など。赤や, 黒地に黄色で表したいよーな文章。
(emは, 傍点を付けるよーなものだと思うので)
- section ・・・
section要素の意味として使う方がよいかも。 あまり細かいスタイルを適用しない方が ・・・
参考: XHTML 2.0での文書構造と見出し
sectionタグはまだ利用可能ではないので, 一般的には <div class="section"> 〜 </div> とか使う訳れす
- example ・・・
用例を表すもので, そのために枠をつける。
(table要素が使われてたけど, 本来「表」として使うものなので)
samp要素はインライン要素だし。
んで, こんな感じのを想定してるです。
Code: | .example { border: double gray; }
div.example { width: 85%; } |
和訳ドキュメント: Code: | .lang-en { color: lime; display: none; } |
表示したいときには display: block とか display: inline みたいなのをドキュメントごとに入れたり。
(完全に取り去るのも, ツールで可能になりやすいし)
docinfo ・・・ http://www.mozilla.gr.jp/jt/foot.txt
comment ・・・ http://moz.skillup.jp/jtp/viewtopic.php?t=1575
before/after 付きの commentと, そうでない commentを用意するのはどーでしょー。
他のドキュメントに影響を与えるかもだし, ほかに, 1〜2文字程度の場合は必要無いかもだし。
no-wrap ・・・ http://moz.skillup.jp/jtp/viewtopic.php?t=1476
テーブルの, 一番左の項目 あるいは thを改行しないようにする。
どちらか片方あるいは両方で, こんな感じ。(一部のブラウザーで未対応だけど, 構わないかなってことで)
Code: | table.no-wrap td:first-child, table.no-wrap th { white-space: nowrap; }
|
このほか, delとゆークラスが使われてる文書もあったです。
使い方は del要素と同じみたいだったけど, del要素は使わない方針なのでしょーか?
んで, 上記のクラスはたまたま 7文字だけど, こだわってる訳ではないれす。 ![Twisted Evil](images/smiles/icon_twisted.gif) |
|
![](templates/trans/images/spacer.gif) |
山口
登録日: 2003年5月 23日 記事: 2920
|
|
![](templates/trans/images/spacer.gif) |
Orca
登録日: 2004年4月 20日 記事: 511 所在地: 関西
|
件名: Re: ドキュメントのクラス名 投稿時間: 2004年9月25日(土) 23:36 |
|
|
こんばんは。
山口 wrote: | Orca wrote: | 和訳ドキュメント:
- lang-en ・・・ http://moz.skillup.jp/jtp/viewtopic.php?t=1610
草稿で残しておく英文。lang=enだと, 一部のブラウザーが未対応なので。
Code: | .lang-en { color: lime; display: none; } |
表示したいときには display: block とか display: inline みたいなのをドキュメントごとに入れたり。
(完全に取り去るのも, ツールで可能になりやすいし)
|
これは、スマートですが、翻訳作業の際にタグを追加する作業が増えてしまいます。できるだけ、翻訳者の方の作業を少なくしたいです。僕も含めて、翻訳をする人すべてが HTML のマークアップになれているとは限らないので。 |
参照先を読んでくらはい。
「草稿」から「完成」にするときに, 何も手を加えなくてよい (見た目, 英文が存在しなくなるから)。 だから, 英文の削除に伴うミスを減らしたりもできるカモ。
それに, それらの手間が減ることによって, 原文を組み込む敷居が低くなり, 少しばかり組み込みやすくなるかもってことです。
<span class="lang-en">〜英語〜</span> みたいな感じで組み込めば OK
span要素(とか div要素)にしたくなければソレはソレで構わないしょう。
「完成」にするために, その部分を手作業で削除する必要があるだけ。
山口 wrote: |
before/after 付きのコメントって、どういうものですか? 実はこの点が良くわからないので、コメントできません(涙 |
参照先を読んでくらはい。
"【訳注:" と, "】" を自動で追加するものです。
便利は便利だけど, すでにある文書では重複してしまうし, "(英語)" といったコメントだと逆につけない方がよいかもなので, その両タイプあると便利カナってことです。
山口 wrote: |
これでできてしまうのですか・・・ 素晴らしいです。でも確認ですが、これは HMTL のソースをちょっといじる必要がありますね? このスタイルを適用できるように、td に対して section を与える(?)ような事をしないといけないと思いますが、どうですか? |
すべての table要素について, ソレを適用して構わないのか, てことれす。
対象となる table要素に class属性をセットすることで, 先頭(一番左)の td要素だけ, あるいは th要素だけを改行しないようにする方向でどーだろーか, と。
(このばーい tableタグに class="no-wrap" を追加する必要があるし, 場合によっては, 改行したくない項目を (大抵, 見出し項目だろうから) th要素に変更する手間が必要になるけど)
山口 wrote: | Orca wrote: | このほか, delとゆークラスが使われてる文書もあったです。
使い方は del要素と同じみたいだったけど, del要素は使わない方針なのでしょーか? |
これは和訳文書ですよね? となると和訳での方針ではなくて、
(中略) |
もじら組の文書とか和訳ドキュメントでの, 「先にあげたよーな "まとめと追加の要望"ではないもの」 です。
具体的には, 「和訳プロジェクトのページ」そのもの。 |
|
![](templates/trans/images/spacer.gif) |
山口
登録日: 2003年5月 23日 記事: 2920
|
件名: Re: ドキュメントのクラス名 投稿時間: 2004年9月26日(日) 13:41 |
|
|
こんにちは。
まず、個々のアイデアに共通するコメントの背後には、新たなタグは追加せず、単に英文を和文に置き換えるのみにしたい、という考えがあります。「翻訳」以外での作業は極力なくしたい、ということですね。HTML タグの追加や変更は、理解をしている人にとっては簡単ですが、知らない人にとっては非常に大変な作業になります(含:僕)。
また、後に他の人が訳した文書を更新する場合、既存の文書の構造が大きく変わった場合などのケースについても念頭においておく必要があります。(尤も Orca さんが提案してくださっているクラス名は、オリジナルに変更を加えるというよりは、作業性の向上のために情報を付加する方向性にあるのは、なんとなく僕も理解しています。)
要するに、和訳の作業をするにあたって、できるだけ作業ガイドを短く簡潔にしたいのです。
そうしたことを念頭に、続く僕のコメントを理解してください。
Orca wrote: |
参照先を読んでくらはい。
「草稿」から「完成」にするときに, 何も手を加えなくてよい (見た目, 英文が存在しなくなるから)。 だから, 英文の削除に伴うミスを減らしたりもできるカモ。 |
この意図自体は良く理解できます。その可能性も分かります。これは、やろうと思えばインライン CSS でも可能なことなので、翻訳作業をしている一人一人の好みに合わせても良いのではないかと思います。
Orca wrote: | "【訳注:" と, "】" を自動で追加するものです。
便利は便利だけど, すでにある文書では重複してしまうし, "(英語)" といったコメントだと逆につけない方がよいかもなので, その両タイプあると便利カナってことです。 |
二つ用意をして、その違いを説明して、翻訳をしてくれる人に、どちらを適用するのを判断してもらうのは、説明が面倒&翻訳者の作業が増えるかなぁ・・・ と思います。新しい文書を訳すのであれば、迷うことはないですが、誰か他の人が訳した文書を受け継いで更新する場合、まずどちらのスタイルが適用されているかを判断して、自分はどちらにあわせるかを考えないといけないですよね。それを翻訳者の方にお願いするのは、ちょっと酷かなと思います。
Orca wrote: | すべての table要素について, ソレを適用して構わないのか, てことれす。 |
すべての表に対して一律にこのスタイルを適用すると問題が出ます。・・・と思います。そうなると、翻訳者の方に判断をしてもらうことになりますが、そのための説明を用意して、判断の基準を考えてもらい、実際の作業を行うとなると、厳しいかも・・・と思うのです。
Orca wrote: | このほか, delとゆークラスが使われてる文書もあったです。
使い方は del要素と同じみたいだったけど, del要素は使わない方針なのでしょーか? |
部門(プロジェクト)サイトのほうのことですね。こちらは、他にも書いたように、方針ではなく、単なる模倣をした結果そうなってしまった、ということです ![Crying or Very sad](images/smiles/icon_cry.gif) |
|
![](templates/trans/images/spacer.gif) |
Orca
登録日: 2004年4月 20日 記事: 511 所在地: 関西
|
件名: Re: ドキュメントのクラス名 投稿時間: 2004年9月27日(月) 15:38 |
|
|
翻訳を買って出る人を, 未知なる驚異から保護したい, と感じてるのかもですね。 訳が分からないものは見せない・触れさせない, と。
翻訳者としては, 最初の翻訳と, それを引き継いだばーいとに分かれる訳だけど, でも, そのどちらにも共通する点があるです。
Quote: | 翻訳する部分は、ページ中央部の本文だけです。
ページ左側およびトップにあるリンク集は翻訳しなくても結構です。またこの部分の HTML も変更する必要はありません |
「ページ中央部の本文」ってドコでしょう。
てゆーか, <body> <p> 〜〜 <span> みたいな羅列を見たとき, ソレが何だか分からなければ普通は放棄するでしょーね。 逆に, <身体> <p> 〜〜 <スパン> とか訳されても困る訳です。
翻訳者は少なくとも, どの部分がタグになってるかは知ってて, 「ページ中央部の本文」であるトコを見分ける力は備えてるはず。 HTMLコメントについても, 少なくともある程度は知ってるはずれすね。 その中にタグを含んでても表示されない訳だし。
んで, どんな種類のタグがあるかは知らなくてもよく, つまりはテキストとそうでないトコの区別さえつけばよい。で, 可能なら title属性, tableの summary属性, imgの alt属性 … そーゆー部分は翻訳対象にしてもらうのがよい。
んで, 未知なるものを驚異と感ずるのなら, 知ってしまえばよいよーに思うです。
全体像を把握すれば, 明確にすれば, それで解決することもあるカモ。 この「class」を使うとこうなる, と。
説明が面倒だから機能は増やさない方がよい, ってのも間違ってるよーに思うです。
その機能に無駄があるとか, 別の問題を引き起こしてしまうとか, そーゆーのがあれば別だけど。
てことで 「どのよーに説明すると分かりやすいでしょう」 とか公募してみては? 分かりやすい解説を求めてもよいし, 解説ページの構成を求めてもよいでしょう。
σ(^^) としては, class名とその機能(?)の一覧のページを用意して, (翻訳の方法のページに書かなくても) 「commentも含め, それ以外のクラスの言及」のリンクを用意するだけでよいと思うです。
で, 実際 使うときは, 案外簡単に <span class="del"> とかできるはずです。(解説がなくても)
# ただし, コレこそ (理由がないのであれば) classは追加しない方がよいと思うです。
# 今後XHTML Basic に移行する可能性があって(ケータイでも見ることできるよーにするとか), del要素を控えてるのなら別だけど
いったい どーのよーに使い分けるのか, みたいなトコも気にしてるのかもだけど, ソレもあまり気にする必要はないかも。
例えば, <span class="comment"> は絶対使わなければならないもの, って訳じゃないれす。 使いたいとき, その必要があると感じたとき使うとよいものれす。 その必要を感じなければ使わなくてもよい。
でも, CSSを知ってる人が各自バラバラに使いだすと, 収拾が付かなくなるです。
いくつかの classを共有することで, それなりにメリットがあるです。
- 何を表しているのか意味がはっきりする
- CSSがサーバーで用意されてれば, あとは使うか使わないかだけ。
CSSを知らなければ, 便利な機能も使うことができなくなってしまう
- 一括で管理しているから変更も容易 (急に色を換えたくなったとか)
山口 wrote: |
まず、個々のアイデアに共通するコメントの背後には、新たなタグは追加せず、単に英文を和文に置き換えるのみにしたい、という考えがあります。「翻訳」以外での作業は極力なくしたい、ということですね。HTML タグの追加や変更は、理解をしている人にとっては簡単ですが、知らない人にとっては非常に大変な作業になります(含:僕)。 |
HTMLタグを追加(定義とか?) したり変更したりできる訳じゃないから, たぶん「class」のことを指してるものとして …
山口 wrote: | Orca wrote: |
「草稿」から「完成」にするときに, 何も手を加えなくてよい (見た目, 英文が存在しなくなるから)。 だから, 英文の削除に伴うミスを減らしたりもできるカモ。 |
この意図自体は良く理解できます。その可能性も分かります。これは、やろうと思えばインライン CSS でも可能なことなので、翻訳作業をしている一人一人の好みに合わせても良いのではないかと思います。 |
翻訳者が全員 CSSを理解できるとは限らないかも。
タグは知ってるけど CSSは分からない人もいるでしょう。その逆は いないだろーけど。
<span class="lang-en">〜</span> とか <p class="lang-en">〜</p> で英文を括ると, ローカルにあるものは見えるけど, 「登録」すると見えなくなる。
ローカルであっても, CSSまで downloadしたたばーいは見えなくなるけど, .lang-en { display: block; } の行をスタイルシートとして HTMLに加えると見える (色も付く)。 ま, 後者は, 確かにある程度スタイルシートに関する知識が必要になるかもだけど。
lang属性ではなく, そんな classを用意しよーとゆーのは, 一部のブラウザーではソレをサポートしていないからです。
span[lang=en] { display: none; } の形式では, 隠したつもりが丸見えになったり, あるいは隠すつもりもないトコまで隠れたり。
span:lang(en) { display: none; } の形式だと, Mozillaでさえサポートしていないはず。
だから, (lang属性を使うよーなばーい)ソレに代わるものが必要てことれす。
# "多少の見栄え"の問題ではないため, ほぼすべてのブラウザーで共通にできる必要がある
共通化されていれば, CSS知らなくても使うことができる(可能性大)。 class名が統一されてると, ツールによる削除も可能。inline CSSではそこまでの解釈は無理かもだし。
もちろん, 翻訳者にはコレを使わないって選択肢もあるです。 英文を直接記述する訳れすね。
前にもゆったよーに, デメリットは, 自動的に見えなくしたり, 機械的に削除したりできないこと。 今までと同様, すべて手作業で削除することになるです。
山口 wrote: | Orca wrote: |
"【訳注:" と, "】" を自動で追加するものです。
便利は便利だけど, すでにある文書では重複してしまうし, "(英語)" といったコメントだと逆につけない方がよいかもなので, その両タイプあると便利カナってことです。 |
二つ用意をして、その違いを説明して、翻訳をしてくれる人に、どちらを適用するのを判断してもらうのは、説明が面倒&翻訳者の作業が増えるかなぁ・・・ と思います。新しい文書を訳すのであれば、迷うことはないですが、誰か他の人が訳した文書を受け継いで更新する場合、まずどちらのスタイルが適用されているかを判断して、自分はどちらにあわせるかを考えないといけないですよね。それを翻訳者の方にお願いするのは、ちょっと酷かなと思います。 |
では, 今まで通り "【訳注:" の文字列も記述し, before/afterは無かったことにするか, それとも, スタイルシートを置き換えてしまって, いくつか問題になるドキュメントを変更するか, そのどちらかってことになるかもですね。
その他には ・・・ 思い付かない
山口 wrote: | Orca wrote: |
すべての table要素について, ソレを適用して構わないのか, てことれす。 |
すべての表に対して一律にこのスタイルを適用すると問題が出ます。・・・と思います。そうなると、翻訳者の方に判断をしてもらうことになりますが、そのための説明を用意して、判断の基準を考えてもらい、実際の作業を行うとなると、厳しいかも・・・と思うのです。 |
tableのソレも, 画面が十分に広ければ問題は出ないかも。 つーか, すでに, ある種のブラウザーでは意味がないかもしれないし。
その上で, 使う/使わないは, その人の判断に任せることになるかも。 |
|
![](templates/trans/images/spacer.gif) |
|
|
新規トピックを投稿できます 既存トピックに返信できます 自分の記事を編集できません 自分の記事を削除できません 投票に参加できません
|
Powered by phpBB © 2001, 2006 phpBB Group (customized by dynamis)
|