翻訳ルール: element、attribute

• Relator: cypher256
• Dono: iga
• Tipo: Feature Requests
• Estado: Fechado
• Componente: (Nenhum)
• Marcos: (Nenhum)
• Prioridade: 6
• Gravidade: 5 - Medium
• Resolução: Nenhum
• Arquivo: Nenhum

Details Responder

element、attribute について、
ルールに追加していただいてますが、不明確のままに
してしまっていました。

現状、ルールの「?」で示していただいたとおり、
既存訳を見ても使い分けが不完全、かつ
文脈から判断不能なものがあります。

「要素」、「属性」に統一したいのですが、
いかがでしょうか？

参考：
IBM 辞書では element は「要素」「エレメント」
「素子」「部」などが混在、attribute は「属性」に
統一されています。

Ticket History (3/11 Histories)

2008-08-18 21:17 Updated by: iga

Comentário Responder

Logged In: YES
user_id=712

「要素」、「属性」に統一に賛成票を 1 票。

2008-08-18 21:18 Updated by: iga

• Dono Update from iga to ymoto

2008-08-21 14:17 Updated by: iga

• Prioridade Update from 5 - Medium to 6

2008-08-21 14:59 Updated by: ymoto

• Dono Update from ymoto to cypher256

Comentário Responder

Logged In: YES
user_id=15698

> 既存訳を見ても使い分けが不完全、かつ
> 文脈から判断不能なものがあります。

既存訳の使い分けが不完全な理由については、もう少し
分析が必要なように思います。具体的には、

a) 基準は明確だが、正しく適用されていない
b) そもそも使い分けの基準が明確でない

というケースが考えられます。

a)の場合は、翻訳対象に「どのような場合に表示される
メッセージか」というような付帯情報を与えたり、
既存訳（翻訳メモリ）の用語を適切にしていくなど、
翻訳プロセスを改善することで、長期的には用語を
統一できる可能性があります。
（逆に、短期的には難しいと思います）

b)の場合は、本質的に使い分けが不可能なので、
基準を明確にする必要があります。その中で用語を
統一することもありだと思います。


elementについては、XMLの場合は「要素」、Eclipseの
構成要素の場合は「エレメント」というように、
部分的には基準が存在すると考えられるので、不完全
ながらa)のケースのようにも思えます。

これまでは、a)のケースでは誤訳などを除き、積極
的に基準の変更は行ってこなかったと思います。
しかし、今後積極的に基準の変更を行えば、Eclipse.org
提供の言語パックとは用語が乖離していくと予想されます。

乖離が必ずしも悪いとは思わないのですが、どこまで
許容するかについて、もう少し整理が必要なように
思います。極端な例でいうと、element=「要素」で
統一するなら、perspective=「観点」もありえると
いうことになります。

ということで、現時点でのelement=「要素」への統一は、
即座には賛成しかねるというスタンスです。


attributeについては b) のケースと思われるので、
「属性」で統一することに問題を感じません。
（むしろ、望ましいと思います）

2008-08-21 22:12 Updated by: cypher256

Comentário Responder

Logged In: YES
user_id=5911

おっしゃるとおりだと思います。
ただ、「どのような場合に表示される
メッセージか」は単なる辞書である
Pleiades 側で実現不可です。

現在、訳の不統一と使用箇所依存は山積ですが、
Pleiades 自体は使用箇所の依存を排除した
統一訳ポリシーの上に成り立っています。

element に関して、統一したほう良いと
思ったのは下記 4 点からです。

1) 基準が明確だった場合でも文脈から
　 判断不能な場合がある
2) 使用箇所特定による判断でも辞書的に
　 根拠が説明不能
3) eclipse の構成要素の場合、
　 なぜカタカナか説明不能
4) 個人的に日本語の、エレメント=要素
　 の違いが分からない

4 の主観は置いといて、

2 に関して、element に限った話ではなく
既に使用箇所に依存した訳が多くあります。
基本的に使用箇所依存訳は出来るだけ
どの使用箇所でも対応できる訳にし、
言語パックジェネレーター側で
「どのような場合に表示されるメッセージか」
で対処すると考えています。
これは訳だけでなく、キーやパッケージ
などの付帯情報が必要だと思います。

【例えば「element」1 単語だった場合など】

これは、今回の element に関係ありませんが、
言語パックを生成する上で、上記のような
同じ 1 単語から、使用箇所により異なる訳を
生成する必要があるのは今までどおりです。

3 は ymoto さんがおっしゃるように
明確にすれば済む話かもしれません。

上記以外に、実は毎回、いがぴょんさんが
element が含まれるエントリーに対して
「レビューに自身なし」とあったので、
各人の認識ずれがあるか、納得していないか、
があると思ったということもあります。
ただ、これに関しても明確化して、
決定すれば問題ありませんね。

逆に、ymoto さんの中には完全に明確な
ものがあって、迷いがないとも言えます。
これから、ヘルプが作成されることを
考慮すると、ルールは「?」付きではなく、
明確にしたいところです。

# 同様の問題に String があります。
# 各人の認識ずれは解決しないといけませんね。

今、出先なので、確認できませんが、あとで
修正を入れる前の eclipse.org から
提供されたままの言語パックを確認してみます。

あと、既に意識されているかもしれませんが、
認識を共有していただきたいのが、
今まで 「eclipse.org の言語パック」という
くくりでの話が多いですが、論理的には
言語パック提供 8 社の別のルールが存在したはずです。
例えば、IBM と Actuate とではまったくと
言っていいほど訳が異なります。
とは言っても Actuate 以外の 6 社は IBM の
訳に近いので、基本は合わせる前提があったと
思われます。


長くなってしまいましたが、
結論は下記の A、B どちらかしかないと思えます。

ルールA
・文脈から XML と判断できる場合は「エレメント」。
・それ以外は「要素」。例えば「element」1 単語。
・補足）使用箇所依存は言語パックジェネレータ対応

ルールB
・element=要素



…「文脈から」からというのが明確ではない
気もしてきました。
java element=java エレメント (小文字だからたぶん XML)
Java element=Java 要素 (キャメルケースだからたぶん XML ではない)

2008-08-22 16:57 Updated by: iga

Comentário Responder

Logged In: YES
user_id=712

私がレビューをしていて、文脈から 要素にすべきか エレメントに
すべきか、判断つかないことが多く、「レビューに自信なし」を多
用しておりました。
文から判断して 要素、エレメントを使い分けるのは とても難しい
ので、私は「要素」一本化に寄った考えを持っています。

、、、また、ご指摘のように、String もレビューの際に いつも悩
まされています。ただし、Element にくらべ String のほうは、過
去訳と引き合わせて判断つきやすい傾向にあるように感じています。

2008-08-25 01:45 Updated by: cypher256

• Dono Update from cypher256 to iga

Comentário Responder

Logged In: YES
user_id=5911

下記「element」の調査結果です。
なお、「Attribute」は「属性」に修正します。

●element の使用状況調査結果

153429 エントリー中、4579 エントリー。
全エントリー数/「エレメント」出現数
BIRT 286/0 --- 要素に統一。
CDT 226/226 --- エレメントに統一。
DTP 31/0 --- 要素に統一。
EMF 68/24 --- XSD エディターのみエレメント、それ以外は要素。
GMF 97/3 --- 要素にほぼ統一。
TPTP3.3 33/33 --- エレメントに統一。
TPTP4.0 66/65 --- エレメントにほぼ統一。
TPTP4.2 71/0 --- 要素に統一。
VE1.1 1/1 --- エレメント 1 個。
VE1.2 1/0 --- 要素 1 個。
WTP0.7 211/189 --- ほぼエレメント。
WTP1.5 844/64 --- ほぼ要素。EJB に関する XML の一部でエレメ
ント。
Eclipse2.1 446/428 --- エレメントにほぼ統一。
Eclipse3.0 368/355 --- エレメントにほぼ統一。
Eclipse3.1 414/397 --- エレメントにほぼ統一。
Eclipse3.2 990/68 --- 要素ほぼ統一。JDT でエレメント。XML
ではない。


●結果から分かること

・プラグインごとにルールが存在
　→ 単に訳出した会社、部署が異なり統一チェックされていない

・WTP、Eclipse 本体は、ある時期に
　「エレメント」->「要素」にルール変更されている

・エレメントは何に使用されている（いた）か？
　→ 初期の TPTP、Eclipse 本体はエレメントに統一されていた
　→ CDT がエレメントに統一。
　→ JDT UI 要素の一部で使用されている。
　→ EMF XSD エディター、WTP の EJB XML の一部が使用。
　→ ただし、WTP でも XML 関連で「要素」が多く使用されている。

・以上から全体のルールとして、エレメントと要素の使い分けは
　存在せず、翻訳者の感覚的なものであったと見るのが妥当。
　全体としてルール的な統一はない → ただの訳ゆれ。


●これからはどうするか？

意味のない訳ゆれは多数訳に合わせる。
修正対象となる「エレメント」使用箇所は
1720 中、460 エントリー。
ただし、既存の書籍、Web、手順書などへの影響あり。
既存箇所を確認した限り変更により訳の意味は
変わらない。



いがぴょんさん、ymoto さん

逆に XML での使用を「エレメント」と明確にした場合でも、
辞書としては、文脈に依存できても、使用箇所に依存できません。
言語パック生成時に使用箇所ごとに上書きしして
いただく形になります。
日本語言語パックとしての影響をご考慮いただき
blanco としての回答をいただければと思います。

関連することとして、1 ワードのように文脈から
判断できないほど短い場合、すべて言語パック作成側で
上書きするほうが良いかもしれません。辞書側が
安定することはありません。論理的に考えると
短い文の場合、辞書式は明らかに破綻しています。
例）to など
Pleiades では辞書式ということで当初から効率と
実行時翻訳の利点を優先したため、わりきっていますが、
言語パックは本来辞書式ではなく、対応可能な仕組みを
持っているがゆえに、対応が必要かもしれません。
また、このような短い文は、辞書式での最適化のため、
言語パックが意図できない訳に変更する可能性も
十分ありえます。


# 最近では少し意味合いが違いますが、1 ワードのもの
# としてはご存知のとおり、Deleted や Launching の
# 変更がありましたね。極端なことを言えば
# kill も 1 ワードでは「削除」もありえます。

2008-08-26 11:17 Updated by: ymoto

Comentário Responder

Logged In: YES
user_id=15698

かしはらさん、詳細な調査ありがとうございます。

> ・WTP、Eclipse 本体は、ある時期に
> 　「エレメント」->「要素」にルール変更されている

実は、Eclipse3.2の日本語版をあまり使用していなかった
こともあり、このルール変更にはまったく気づいていません
でした。このルール変更を踏まえるとelement=「要素」と
するのが、極めて妥当なように思います。

（なお、私が「eclipse.org の言語パック」と言及して
いる場合、IBMの訳を強く意識しています）


> 意味のない訳ゆれは多数訳に合わせる。
> 修正対象となる「エレメント」使用箇所は
> 1720 中、460 エントリー。
> ただし、既存の書籍、Web、手順書などへの影響あり。
> 既存箇所を確認した限り変更により訳の意味は
> 変わらない。

「意味のない訳ゆれは多数訳に合わせる」で基本的には
問題ないと思うのですが、副詞などと異なり、メニュー
などによく現れる名詞は、ご指摘のように既存ドキュメント
への影響が大きい点が、やや気になります。

ただ、この点は、以前かしはらさんがそのように指摘されて
いたからというのが主な理由なので、かしはらさんが「よし」
とするなら、個人的には問題ないと考えます。

逆に、既存ドキュメントへの影響が無視できないのであれば
いわゆる安定版、開発版というような分けが必要なのかも
しれませんが、訳を追加する際には新しいルールに従うと
想定されるため、あまり現実的ではないような気もします。


あと気になるのは、大量コントリビュートにおいて、翻訳を
行った組織の翻訳ルールがPleiadesのルールと著しく異なる
場合の対処です。

今後、複数の異なる組織による翻訳コントリビュートが発生
すると予想されますが、すべての組織の翻訳ルールを揃える
のは、現実的に難しいかと思います。

この場合、翻訳作業においては、異なる翻訳ルールごとに
TMやGlossaryを用意するのが現実的と思われますが、そう
すると、Pleiadesのルールとは必ずしも一致しないこと
になります。

どのように対処すべきか、にわかには思いつきませんが、
このようなケースが想定されるということを、お伝え
しておきます。


> …「文脈から」からというのが明確ではない
> 気もしてきました。
> java element=java エレメント (小文字だからたぶん XML)
> Java element=Java 要素 (キャメルケースだからたぶん XML で
はない)

「文脈から」というのは、以前も指摘した通り、現実的には
明確でないケースが多々あります。IBMが訳を「要素」に変更
したのも、それが理由かもしれません。

ちなみに、私が思ってたルールはXMLなら「要素」、Eclipseの
構成要素なら「エレメント」です（今となっては重要では
ないですが・・・）。

2008-08-26 16:14 Updated by: iga

• Dono Update from iga to cypher256

2008-09-01 00:10 Updated by: cypher256

• Dono Update from cypher256 to iga

Comentário Responder

Logged In: YES
user_id=5911

「要素」に統一しました。

あと懸念されている、大量コントリビュートにおける
翻訳ルール逸脱の問題は現在もある、下記の Pleiades
Validator の検査によりある程度対応可能だと考えています。
このバリデーターは translation.properties を
生成する Generator に組み込まれているため、
検証を通過しなければ、提供物はすべて NG 扱いとなり
一切取り込みは行われません。
これは私たちが翻訳した訳であっても例外ではありません。

1. すでに同一の訳が存在しないか?
2. 存在する場合は内容の違いはどうか?
3. どのプロパティー・ファイルで重複しているか?
4. 未翻訳チェック (訳が空)
5. 末尾同一性チェック (...、..、:)
6. 末尾句読点チェック「.」->「。」
7. 英数字隣接空白チェック
8. 埋め込み引数の出現数チェック
9. 用語チェック
→ validation-term.properties
10. 用語正規表現チェック
→ validation-term-regex.properties
11. 対訳正規表現チェック
→ validation-translation.properties
12. 翻訳禁止チェック
→ validation-prohibition.properties


機械的なチェックは、人手によるチェックを補完する
ものですが、このチェックはまだまだ貧弱で
コントリビュートが増えるほど強化する必要が
あると考えています。

今回、上記の 11. 対訳正規表現チェックに
「element=要素」、「attribute=属性」を
追加しました。このチェックは左辺の英単語が
出現すれば、右辺の日本語単語が出現しなければ
ならないというものです。複数出現した場合などの
完全性はないものの、ないより良いと考えています。
このチェックには「raw=raw」などがあり、これは
英文に raw があれば、日本語にも raw が必要、
つまり、訳出してはいけないことになります。

なお、このチェック追加により既存訳の未訳出や
誤りを 20 箇所修正しました。

2008-09-05 10:54 Updated by: iga

• Ticket Close date is changed to 2008-09-05 10:54
• Estado Update from Aberto to Fechado

Comentário Responder

Logged In: YES
user_id=712

element の統一、ありがとうございます。

また、バリデータの強化について、興味を深く感じまし
た。こちらからコントリビュートする前に、こちらのバ
リデータを適用できないものかどうか検討します。