[21] 非公式な仕様書の翻訳を参考にすることは、おすすめできません。 面倒でも原文を読みましょう。
[2] インターネットや Web の技術は日進月歩です。残念ながら、 日本語で得られる正しい情報はそれほど多くありません。 たまに仕様書を日本語に翻訳したものが公開されていることがありますが、 翻訳が正しいかどうかはっきりしないものばかりですし、 原文の更新に追従できていないものが多いです。
[6] 日本語で読みたいなら、仕様書ではなく開発者向けドキュメントを読みましょう。 最新の生の情報が知りたいなら、がんばって英文を読んでください。 日本語訳された仕様書は、どちらの役にも立ちません (むしろ有害です)。
[3] 00年代後半頃から、 Web 技術の仕様書は日に数回の頻度で更新されるのも珍しくなくなりました。
[4] 2010年頃には原文の更新に自動的に追随して翻訳済み部分だけ翻訳版に差し替えるような仕組みが用いられる例も現れました。 しかし、残念ながらその方式が一般的になってはいません。
[5] 従って、仕様書の翻訳版は、基本的に古いものだと了解しておく必要があります。 (が、多くの翻訳版は、そのことを読者に十分に警告していません。)
[7] 中には、元の仕様書が廃止されているのに、何の注記もなく元の翻訳のまま公開され続けていることすらあります (むしろ翻訳が終わったら放置される方が多い気もします)。 原文仕様書についても誤って古い版を参照する人が後を絶たず問題となっています。 翻訳を公開し、放置するのはその問題に加担しています。
[13] 日本の公的な組織が関係する世界組織の文書を翻訳したものでも、 翻訳のレベルが低くて意味がわからないものがあったりします。 公的組織であっても十分な予算と体制を構築せずに機械翻訳より良いといえるかどうか判断がつかないレベルのものを垂れ流している現状はどうしたものでしょうか。
[17] IETF や W3C の仕様書を JIS や JIS TR として日本の工業標準にする制度は、 特にひどい。国の機関が承認した文書という箔付けがある分、たちが悪いです。 翻訳JIS, JIS TR 参照。
[11] 原文の仕様書が緩いライセンスになっていても、 翻訳文がより厳しいライセンスになっていたり、ライセンス不詳だったりすることがよくあります。
[12] ソースコードにコメントとして含めたり、 プログラムの動作仕様の関連文献として配布物に含めたりと、 仕様書の一部または全部を複製して配布することは、業界では珍しくありません。 原文がそのような利用を認めているとしても、翻訳文もまた認めているとは限らないので、 慎重な検討がひ必要です。
[10] 仕様書の翻訳も、ただのドキュメント (やドキュメントの翻訳) も、 どちらも間違いが混入する可能性はあります。しかし、 仕様書はいかにも正しいものであるかのような印象を読者に与えてしまいます。 翻訳の誤りという可能性を忘れて仕様書に書いてあるのだから正しいという前提で誤った議論を進めてしまう危険性があります。
As a native Japanese, this document is very hard to read as a
technical translation.
For example, "multi-column" is usually reffered as "段組", but this
document translates it as "複 column".
By the way, I just completed the translation into Russian, if someone is interested
Oh, someone translated the DOM4 document into Russian
That's kinda sad as the document is way out of date
[14] 英語が読める人なら、違和感があったら原文を読んで確かめれば良いですが、 英語が読めない人は翻訳文にちょっと違和感があっても、それを信じるしかないわけで・・・。
[18] Google検索で原文よりも質の低い翻訳が上位に出てきてうざったい。 (見ている人の言語と違う言語の公式サイトが下位に来てしまうのはGoogle検索の問題でもあるけど...)
[19] Discontinuation of Database of W3C Volunteer Translations in 2017 (Coralie Mercier著, ) https://lists.w3.org/Archives/Public/w3c-translators/2017JanMar/0000.html
[22] 標準化団体側も翻訳してもらったよわーいって紹介してたり、あろうことか仕様書本文から誘導してたりすることもあるんですよね。 でもその中の人達は翻訳を必要としてないんで、翻訳文が低品質だったり、本家への追随を怠ってたりする実情を把握してないんです。 困ったものです。
[23] 翻訳してる人も紹介してる人もみんな善意でやってるから、あまり悪くは言いたくないけど、 でも実際のアウトプットが悪いってのはちゃんと言ってかないといけない。 ぜんぶ善意でやってても、世の中をよくするためになってないんです。
[24] そして翻訳を高品質に出来る人は翻訳を必要としていない、 翻訳を高品質にする前に原文が変わってしまう、 っていうのは構造的な問題で、どうしようもない。 何年たっても改善の兆しもないし妙案を出す人も出てこない。だから諦めるしかないのです。
[25] 文字コードとIPv6の諸問題を解決する次世代UNICODEの紹介 #Unicode - Qiita, @rana_kualu, 最終更新日 2018年11月25日, 投稿日 2018年08月20日, https://qiita.com/rana_kualu/items/2376eaedaaf4d15f70e2
[26] >>25 はに発行された RFC 8369 の和訳。
[27] この翻訳が悪質なのは、なぜか RFC 原文の日付などの部分を削っていること。 訳者による前書き、後書きの部分を含めて全文どこにもこれが4月1日の RFC であることが明記されていない。かろうじて他の人がジョークRFC一覧なる記事を書いてこの記事をリンクしたために逆リンク一覧にそれが出現しているが、 普通の読者が気づくのは難しいだろう。
[28] 実際これを真面目な提案と誤解して参照していると思しき人が観測できる。
[29] 訳者自身も真面目な提案と誤解している可能性もなくはないが、訳者後書きのニュアンス的に、訳者は知っててネタに乗っかっているようにも思われる。 知っててやっているならどうしようもなく悪質だし、 知らずにやっているなら文書が発行された文脈を理解せずに翻訳して提供しているのだから有害。 どちらでも救いがない。
[31] >>25 は原文の著作権表記をなぜか削除しているという点でも悪質だな。 原文権利者へのリスペクトがない翻訳とか問題外っしょ。
[32] Reference も原文にある著者その他の情報を綺麗に消し去っている。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
を
各キーワード『しなければならない( MUST )』『してはならない( MUST NOT )』『要求されている( REQUIRED )』『することになる( SHALL )』『することはない( SHALL NOT )』『する必要がある( SHOULD )』『しないほうがよい( SHOULD NOT )』『推奨される( RECOMMENDED )』してもよい( MAY )』『選択できる( OPTIONAL )』はBCP-14、RFC2119、RFC8174に従います。
と訳している。
[34] 「when, and only when, 」節が訳されていない。日本語だと意味がないから削ってもいいと思ったか? それなら前段も日本語で自然になるようにしなければおかしいだろう。 更に言えば例えば
To address this need, the high-order bit of the 128-bit code point
space SHALL be reserved to indicate multicast.
は
この需要に対応するため、128ビットコードポイントの最上位ビットはマルチキャストを示すために予約されます(SHALL)。
と訳されていて、「されます(SHALL)」でなく「することになる(SHALL)」と訳さなければいけないところだろう。
[35] なお、 「することになる」「することはない」ではまったく要件と理解できず、 日本語としておかしい。誤訳というしかない。 RFC 2119 を読んで理解しているならこんな翻訳にはならないはずだ。
[36]
「BCP 14 [RFC2119] [RFC8174]」
が
「BCP-14、RFC2119、RFC8174」
になっているのもおかしい。勝手に謎の-が挿入されているのもどうかしているが、
BCP 14 が参考文献 [RFC2119] [RFC8174] で参照される RFC 2119 と RFC 8174
で構成されるという構造が理解できていないから、、で結んですべて並列にしてしまったのだろうか。
誤訳でしかない。
[37] Request: Add Japanese and Korean Translations Links to the Wiki · Issue #10603 · whatwg/html · GitHub, https://github.com/whatwg/html/issues/10603
[38] >>37 簡体字中文、日本語、韓国語の翻訳。しかし日本語のものを見るとどうも質の低い機械翻訳らしい。 原文英語表現を知っていればそう訳された理由がわかるが、そうでなく日本語として読んだとき意味が通らない、という部分が多い。 中文、韓国語がどうなのかわからないけど推して知るべしだろう。 これだけの分量の仕様書、しかも原文が頻繁に更新されているものが、 3言語で全文すべて翻訳されているというのはとても人力とは思えない。
[39] こういうのはまあ出てくるだろうとは思っていたけれど、何の臆面もなく堂々と公式にリンクしろと言ってくるとは世も末だ。
[40] さて公式はどうするだろうかね。欧米人中心だから東アジア言語の翻訳の品質を見抜けるとも思えず、 歓迎されるかもな。困ったものだ。
[41] と思って今見たらもう掲載されてるなあ。まあ手続き的に瑕疵がなければ受け入れるんだろうし、 既存の人力だけど質がいいとは限らない翻訳だけが載ってるよりはいろいろなものが載ってる方がまだましという見方もあるかな。
[42] 変に却下でもしちゃうと品質を公式が保証してるような形になっちゃうから、 機械的に受け入れたのはまあ正解かもな。
[45] 知識のない初心者技術者が仕様書を読むのも同じように問題が。 しかも英語すら読めないレベルの初心者が仕様書の翻訳に突撃するのはかなり危険。