でるもんた・いいじまです。 > 元木です。 > 今のガイドライン自体が 2000年前後に議論されたものなので、 > その後、世の中の翻訳ガイドラインもだいぶ変化してきていると思います。 ですね。日本でも国語審議会が答申を出していたと思います。 > > 引き数： 間にひらがなの「き」を含める表記に違和感。 > 個人的にはどちらにも抵抗感はありませんが、 > 世の中の傾向はどちらが多いのでしょうか。 私自身としては「き」ありに強い違和感を覚えます。 もちろん、ただ単にその書き方で通している文献に当たったことがないというだけのことですが。 さすがに昭和ではありませんが平成になったばかりのころ、MS-DOSの時代には「ひきすう」で仮名漢字変換をしても「引数」が出てこなかった（ので辞書登録して使っていた）という曖昧な記憶があります。 > > ユーザ： 語末の長音符号がない点に違和感。 > > 日本語で発音する際には誰しも「ユーザー」と伸ばして発声する。 > 最近は「ユーザー」のように表記する場合が多いですね。 > 電機業界、通信学会などでは長音記号なしが多いことが当初の用語選択に > 影響しているのでしょう。 その手の学会の旧来のガイドラインでは、元の英語が -r で、発音が曖昧音の /r/ になるものは日常語としての日本語の表記法、あるいは実際の日本語話者の発音、に関わらずその部分の音引きを徹底的に省く、という方針を立てていました。 …で、この風潮に国語審議会がNOを突き付けて、たぶんマイクロソフトあたりもそれを受けて日本語向けのガイドラインを見直したのだと思いますが、それでたとえば「マイ コンピュータ」が「マイ コンピューター」になったりした、と。 「ユーザ」に関しては個人的には、どちらがいいのか決めかねています。 > # 旧訳 po ファイル個別箇所 > > 主に訳注、バージョン差異、補足情報の過多に関するものと受け取りました。 > 私自身は、訳注については、原文の誤りといったレベル以外では使わない方針です。 > 説明が足りない場合は、そもそも原文の英語の方の修正を働きかけるべきという > 考えを持っています。 まあ…それはそうなんですが、原文の改善完了まで翻訳作業を中断するわけにもいかないですし、情報を送っても採択される保証はない（極端な話、「Xという英単語を見ればその部分がAじゃなくてBの意味なのは自明でしょ？」ともなりうる）ので、一旦は訳注コミの翻訳を出しておいて、それと同時並行でフィードバックをかけておく、というのが無難だと思います。 ☆ ☆ ☆ > # 旧訳 po ファイル全般 > > > po ファイル内の日本語訳文の行末に "\n" を挿入している箇所が散見 > > される。原文にも存在するのであれば、適切であるが、そうではない > > 箇所が多々あり、不適切、不要と思える挿入。 > > ＝＞ とりあえず新訳は放置。大幅な改修可能性あり(?) > > PO ファイル内の \n ですが、すでに議論されていますが、個人の好みのレベルだと > 思います。最終的な表示に影響がないのであれば、どちらでもいいと思います。 > 私自身は \n を入れない方です。 仮に改行を全て省く方針にしちゃうと、Vi系の愛用者には大不評でしょうね。 Vi系はファイル末に改行がないと警告を出しますし、そういうファイルを開いて末尾に追記してしまったら改行を削った状態で保存する方法がありません。 （最近のVimだと設定でどうにかなるのかもしれませんが。） あるいは、ファイルが短いからといって delmonta ＠ www1234:~/jm/work/$ cat xxx.po とすると、最後の行の文面の直後に改行抜きでプロンプト「delmonta ＠ www1234:~/jm/work/$ 」が出てくるので気持ち悪いです。 ＃DOS/Windowsのtypeコマンドは自動的に最後に改行を入れます。 ＃これが「type nul」で空行が出る仕様の正体です。 まあ .po ファイルの場合は後々分割されて roff ファイルになって、そこから各種の人間可読形式に変換されて、最終的にもしそれをコンソールで読む場合はページャが漏れなくついてくるので、何か自動処理に悪影響がなければ「どうでもいいこと」に同意見です。 ☆ ☆ ☆ ただ、生のテキストファイルを一つにまとめる作業が仮にあるとしたら、改行ありで統一されているほうが圧倒的に便利でしょうね。ごく簡単な例として、 cat *.po > ~/all.txt とか、 #!/bin/csh -f foreach f ( * ) echo "[$f]--------" cat $f end echo "**** END OF ALl FILES ****" exit 0 とか。
Fork