Difference between revisions of "Getting translation strings right/ja"

From Free Pascal wiki
Jump to navigationJump to search
Line 1: Line 1:
 
{{Getting translation strings right}}
 
{{Getting translation strings right}}
  
このページでは、アプリケーション作者の観点に立ち、'''翻訳文字列をゼロから適切に作成する'''ための基礎的な事項を説明しています。
+
このページでは、文字列の作成者(多くはアプリケーション作者と思います)にとっての、'''翻訳文字列を適切に作成する''' ための基礎的な事項を説明しています。
  
この文章での '''翻訳文字列をゼロから適切に作成する''' とは、翻訳文字列が適切に準備されており、簡単に翻訳に修正を加えられたり、それらを用いることで基礎的な要求に合ったオリジナル版が作成できることを意味します。
+
この '''「翻訳文字列を適切に作成する」''' とは、翻訳文字列が簡単に修正できるように準備されており、原版が翻訳文字列を用いる条件に合っていることを意味します。
  
このページを書くに当たり、できるだけ言語に中立であろうと勤めていますが、英語を主言語とするものとしての偏りがある可能性もあります。 あなたの状況へ当てはまらないものは、自由に修正してください。(また、[[Getting translation strings right|オリジナル(英語)ページ]] へのフィードバックもお願いします。)
+
(英語版がこの文章のオリジナルなので)このページを書くに当たり、できるだけ言語に中立であろうと勤めていますが、英語を主言語とするものとしての偏りがある可能性もあります。 あなたの状況へ当てはまらないものは、自由に修正してください。(また、[[Getting translation strings right|オリジナル(英語)ページ]] へのフィードバックもお願いします。)
  
 
=== 一般的事項 ===
 
=== 一般的事項 ===
  
 
問題を避けるために、'''元の文字列は正しい''' ことをまず確認してください。 この理由は、
 
問題を避けるために、'''元の文字列は正しい''' ことをまず確認してください。 この理由は、
* 文字列を翻訳する際には元の文字列を初期値とすることが一般的であるため、未翻訳箇所では元の文字列が表示されることになる。このときに文字列が間違っている場合、悪い印象を与える可能性がある。
+
* 基礎がおかしいと翻訳作業が不必要に難しくなります。 「Garbage In, Garbage Out: ゴミを入れると、ゴミが出てくる」原則が完全に当てはまります。
* さらに問題になるのは、元の文字列を翻訳する仕事を無駄に難しくする点があります。 ここでは、「Garbage In, Garbage Out: ゴミを入れると、ゴミが出てくる」原理が完全に当てはまります。
+
* 一般的に、元の文字列が翻訳の初期値となるため未翻訳箇所では元の文字列が表示されます。 利用者が未翻訳箇所の元の文字列に間違いを見つけた場合、悪い印象を与えるかも知れません。
  
したがって、'''つづり、語句を正確に''' 、不安であれば辞書を使用してください。
+
したがって、'''つづり、語句を正確に''' してください。 不確かな文字は辞書で確認しましょう。
  
ある状況に対しては、分かりやすくよく知られた、 '''一貫した記述''' を用いてください。 何か共通なことの記述について確信が持てない場合は、同じ状況の元での他のプログラムの反応を参考にしてください。 何かのアプリケーションのヘルプファイルも、正確な特殊用語や説明の仕方についてのよい資料となります。
+
また、動作に対する反応などは、'''一貫した記述''' で分かりやすくよく知られた単語を利用しましょう。 一般的な記述が不確かな場合は、同じようなプログラムが他にあればその動作を参考にすることもよい手段です。 他のアプリケーションのヘルプファイルも、特殊用語や説明の仕方についてのよい資料となります。 (訳注:私はwindows環境ですので、office(日本語版と英語版)を参考に文字列リソースを作成しています。)
(訳注:私はwindows環境ですので、officeを参考に文字列リソースを記述しています。)
 
  
句の選定についても一貫したやり方をしてください。 例えば、
+
語句の選定についても一貫したやり方をしてください。 例えば、
  
 
  ファイルを削除(Delete)する?
 
  ファイルを削除(Delete)する?
Line 26: Line 25:
 
  ファイルを抹殺(Zap)する?
 
  ファイルを抹殺(Zap)する?
  
意味は似ていますが、特に理由が無いのに表現を変えた場合、ユーザーまたは翻訳者が間違った解釈をすることがあります。
+
意味は似ていますが、特に理由が無いのに表現を変えた場合、読み手は間違った解釈をすることがあります。
翻訳者はこの間違いを犯しやすく、特別なメッセージ(例えば、メッセージの出自についての情報)の正確な文脈を知らなかったり、言葉のちょっとした違いを重要な差異として捉え、適切ではない翻訳を選びがちになります。
+
翻訳者はこの間違いを犯しやすく、あるメッセージの正確な文脈(例えば、メッセージの呼び出し元についての情報)を知らなかったり、語句のちょっとした違いを重要な差異として捉え、適切ではない翻訳を選びがちになります。
  
エラーメッセージを出すときは、'''問題点''' それ自身を適切に記述しましょう。 問題点の記述とは、エラーメッセージが出たプログラムの状態ではありません(ファイルエラー, 不正な入力など)。 この内容は、プログラムのデバッグには役立ちますが、ユーザには意味を持ちません。 肩をすくめて無視されるだけならいいですが、他のアプリケーションを探して、あなたの意味不明なアプリケーションはアンインストールされるかもしれません。 適切な問題解決に結びつくメッセージを表示しましょう。
+
エラーメッセージを出すときは、'''問題点''' 自身を適切に記述しましょう。 問題点の記述とは、エラーメッセージが出たプログラムの状態ではありません(ファイルエラー, 不正な入力など)。 これは、プログラムのデバッグには役立ちますが、ユーザには意味不明です。 肩をすくめて無視されるだけならいいですが、あなたの意味不明なアプリケーションを使うのをやめ、他のアプリケーションを探し始めるかもしれません。 問題解決につながるメッセージを表示しましょう。
  
また、簡単な'''分かりやすい書き方'''をお願いします。 外国語や非常に技術的な用語は、本当の本当に必要なときにのみ使いましょう。
+
また、簡単な'''分かりやすい書き方'''を行いましょう。 外国語や非常に技術的な用語は、本当の本当に必要なときにのみ使いましょう。
  
  

Revision as of 22:13, 22 May 2009

Deutsch (de) English (en) español (es) français (fr) 日本語 (ja) русский (ru)

このページでは、文字列の作成者(多くはアプリケーション作者と思います)にとっての、翻訳文字列を適切に作成する ための基礎的な事項を説明しています。

この 「翻訳文字列を適切に作成する」 とは、翻訳文字列が簡単に修正できるように準備されており、原版が翻訳文字列を用いる条件に合っていることを意味します。

(英語版がこの文章のオリジナルなので)このページを書くに当たり、できるだけ言語に中立であろうと勤めていますが、英語を主言語とするものとしての偏りがある可能性もあります。 あなたの状況へ当てはまらないものは、自由に修正してください。(また、オリジナル(英語)ページ へのフィードバックもお願いします。)

一般的事項

問題を避けるために、元の文字列は正しい ことをまず確認してください。 この理由は、

  • 基礎がおかしいと翻訳作業が不必要に難しくなります。 「Garbage In, Garbage Out: ゴミを入れると、ゴミが出てくる」原則が完全に当てはまります。
  • 一般的に、元の文字列が翻訳の初期値となるため未翻訳箇所では元の文字列が表示されます。 利用者が未翻訳箇所の元の文字列に間違いを見つけた場合、悪い印象を与えるかも知れません。

したがって、つづり、語句を正確に してください。 不確かな文字は辞書で確認しましょう。

また、動作に対する反応などは、一貫した記述 で分かりやすくよく知られた単語を利用しましょう。 一般的な記述が不確かな場合は、同じようなプログラムが他にあればその動作を参考にすることもよい手段です。 他のアプリケーションのヘルプファイルも、特殊用語や説明の仕方についてのよい資料となります。 (訳注:私はwindows環境ですので、office(日本語版と英語版)を参考に文字列リソースを作成しています。)

語句の選定についても一貫したやり方をしてください。 例えば、

ファイルを削除(Delete)する?
ファイルを消去(Erase)する?
ファイルを除外(Remove)する?
ファイルを拭い去る(Wipe)?
ファイルを抹殺(Zap)する?

意味は似ていますが、特に理由が無いのに表現を変えた場合、読み手は間違った解釈をすることがあります。 翻訳者はこの間違いを犯しやすく、あるメッセージの正確な文脈(例えば、メッセージの呼び出し元についての情報)を知らなかったり、語句のちょっとした違いを重要な差異として捉え、適切ではない翻訳を選びがちになります。

エラーメッセージを出すときは、問題点 自身を適切に記述しましょう。 問題点の記述とは、エラーメッセージが出たプログラムの状態ではありません(ファイルエラー, 不正な入力など)。 これは、プログラムのデバッグには役立ちますが、ユーザには意味不明です。 肩をすくめて無視されるだけならいいですが、あなたの意味不明なアプリケーションを使うのをやめ、他のアプリケーションを探し始めるかもしれません。 問題解決につながるメッセージを表示しましょう。

また、簡単な分かりやすい書き方を行いましょう。 外国語や非常に技術的な用語は、本当の本当に必要なときにのみ使いましょう。


多重否定は分かりにくいので、使わないようにしましょう。 例えば、

This component can not be dropped on non-TControls.
このコンポーネントは、非Tcontolにドロップできません。

これは、否定しない文章で書き換えられます。

This component can only be dropped on TControls.
このコンポーネントは、TControlにのみドロップできます。

こちらのほうが分かりやすいですね。

技術的項目

この節では、技術的な項目の概要を説明します。基本的には、既存の発展性の概観となります。 これは、リソース文字列の構築、GNU gettext と format() 関数を含みます。

リソース文字列と GNU gettext

Free Pascalには文字列定数を扱えるようにするいくつかの言語構成体があります。 特に、この目的のために導入された "resourcestring" というユニットがあります。

詳細は、FPC マニュアルの (prog.pdf, pg. 89ff または このリンク) の適切な箇所を参照して下さい。

GNU gettext は、アプリケーションの翻訳を提供するためのユーティリティ群です。 詳細は、FPC マニュアルの (prog.pdf, pg. 91ff または このリンク) を参照して下さい。

注記: GNU gettext には、単一の元の文字列から多くの翻訳文字列へのマッピングができない欠点があります。 ご注意下さい。

IDE内の リソース文字列

  • Lazarus には、文字列定数からリソース文字列を簡単に作るツールがあります。 リソース文字列の作成を参照してください。
  • FPC は、各リソース文字列の部分に対して .rst ファイルを生成します。 しかし、これらのファイルについての編集ツールはありません。 Lazarusは自動的に .rst ファイルの .po ファイルを生成することができます。 .po ファイルについては多くの編集ツールがあります。(例えば、 kbabel)

パッケージ作成に向けての .po ファイルの生成について、下記の作業を行ってください:

 * 'languages' や 'local' といった副ディレクトリを生成してください。
 * パッケージを開き、オプション -> i18N、"国際化を有効に"をチェック、PO出力ディレクトリを設定

次回にパッケージをコンパイルした時に、 副ディレクトリに .po ファイルが作成されます。 (注: .rst ファイルがパッケージ・ユニットに属する必要があります。 そうでない場合、 .rst ファイルはIDEに無視されます。)

これはプロジェクトについても同様です。

 * プロジェクト -> プロジェクトオプション -> i18N、"国際化を有効に"をチェック、PO出力ディレクトリを設定
  • 例:ドイツ語翻訳の作成: まず、 unit1.po ファイルを unit1.de.po ファイルに コピーします。次に、テキストエディターや .po エディターを用いて、文字列をすべて翻訳してください。
  • IDEは、インストールされたパッケージ用の .po ファイルがある場合、自動的に読み込みます。 例えば、 lazarus/components/projecttemplates/languages/ を見てください。
  • ToDo: 新しい resourcestrings の追加時に、翻訳された .po ファイルを更新する機能の実装と文書化。
  • ToDo: 静的にリンクしたパッケージの 全 .po ファイルを集める機能の実装と文書化。

アプリケーションのリソース文字列

リソース文字列の翻訳のために .po ファイルを読み込むことができます。 この機能を .lpr ファイルに実装するには:

<Delphi> ... uses

 ...
 Translations, gettext;

procedure TranslateLCL; var

 PODirectory, Lang, FallbackLang: String;

begin

 PODirectory:='/path/to/lazarus/lcl/languages/';
 Lang:=;
 FallbackLang:=;
 GetLanguageIDs(Lang,FallbackLang); // in unit gettext
 Translations.TranslateUnitResourceStrings('LCLStrConsts',
                     PODirectory+'lclstrconsts.%s.po',Lang,FallbackLang);
 // ... ここに、全ての .po ファイルに対する TranslateUnitResourceStrings 呼び出しを追加する ...

end;

begin

 TranslateLCL;
 Application.Initialize;
 Application.CreateForm(TForm1, Form1);
 Application.Run;

end. </Delphi>

format() 関数

To not only allow completely static strings in translations, you can use the format() method of the sysutils unit. It is able to replace placeholders within a given text by their actual value given as secondary parameter in a set. Example:

翻訳において、静的文字列を単に許可しないために、 sysutilsユニットの format() を利用できます。 それは、セット中の第2のパラメーターとして与えられた値で、与えられたテキスト内のプレースホルダーを取り替えることができます。

例:

format('明日は %0:s 、 %1:s でしょう。', ['日曜日', '晴れ'])

上記関数は、以下を返します。

明日は 日曜日 、 晴れ でしょう。

ここでは、 %0:s が文字列配列の0番目の引数(日曜日)の代入先、 %1:s が1番目の引数(晴れ)の代入先となります。

プレースホルダーおよび書式の詳細は、FPCリファレンスマニュアルにあります。

format() 関数利用のガイドライン

  • Try to use indexed placeholders in the original strings, even if they are optional. When used, they allow the translator to move the arguments easily within the sentence allowing him more natural expressions (and actually sometimes moving sentence parts is required to create proper sentences in that language).
  • オプショナルなものでも、元の文字列の中でインデックスを付けられたプレースホルダーを使用してください。使用された時、それらは、より自然な表現を与える文の内に翻訳者が引数を容易に移動させることを可能にします。

(また、実際に、時々 移動文部分は要求されます。その言語で適切な文を作成するために)

  • Never compose a sentence out of more than one string. Always use the format() method from the sysutils unit to construct the correct string using placeholders during runtime. Translators will usually not be able to reconstruct the whole sentence, therefore not able to give a good translation; only consider that there are often hundreds of such strings within a single translation database...
  • 2つ以上の文字列から文を構成しないでください。 常に、format()関数を使用してください。 ランタイムにプレースホールダーを使用して、正確な文字列を得るために。 翻訳者は通常全ての文を翻訳はできないでしょう、適訳を与えるのには有能でない何百ものそのようなストリングが多くの場合単一の翻訳データベース内にあると単に考えてください...
  • Do not format using whitespaces. Simply move your label to the appropriate position in the first place. There may be problems with font changes, and seemingly superfluous spaces will be in danger of being trimmed by the translator.
  • 余白の使用したフォーマットはしない。単に、適切な位置にラベルを移動させてください。フォント変更に問題があるかもしれません。また、外見は余分のスペースは翻訳者によって整えられる危険な状態にあるでしょう。

Note: Since format() does not interpret escaped control characters (e.g. like C's "\n", "\t", etc) and GNU gettext for any reason being the translation system of choice (and the tools based on it not being able to interpret non-escaped control characters), it is required to programmatically insert linebreaks.In the current lazarus version, "\n" and "\t" in translated strings are replaced by newline and tab.

注記: format() は、の翻訳システムであるどんな理由でも(また、それに基づいたツールはエスケープされていない制御文字を解釈できない)、エスケープされた制御文字(例えば、C言語の "\n" , "\t" など)や GNU gettext を解釈しないため、プログラムによるlinebreaksの挿入が必要になります。

現バージョンの lazarus では、翻訳されたストリング中の「\n」および「\t」は、newlineとタブと取り替えられます。

正しい文字セット/コードへ翻訳を変換する

例えば、 ISO-8859-1 から UTF-8 へ変換する場合、

 iconv --from-code=ISO-8859-1 --to-code=UTF-8 oldfile.po > newfile.po

下記の修正も忘れないで下さい。

 "Content-Type: text/plain; charset=ISO-8859-1\n"

上を下のように修正する。

 "Content-Type: text/plain; charset=UTF8\n"

English related

This section contains notes which particularly apply when using English as the base language for translations.

  • Make sure to reserve enough space where the text is output: English is a language in which texts are almost always shorter (in characters) than their respective translations, so plan ahead by reserving enough space. Experience shows that very short strings of a few characters length often almost double in size; this difference decreases as the strings get longer.
  • Avoid abbreviations in English; in addition to the fact that this shortens the already short strings even more, there are severe problems with e.g. languages that use ideographic characters where these abbreviations simply do not exist at all.
  • Since this is often an issue: In English punctuation marks (full stop, comma, ...) are part of the previous words, or form some sort of words themselves if there is no previous word (in case of an enumeration). Especially after a semicolon there should always be a trailing space.
There was an error ! Please check file settings , compiler settings,... to fix this issue.

has horrible punctuation and therefore simply looks bad and is harder to read than usual. Consider that common line break algorithms break the line on whitespaces, possibly resulting in a single stop at the beginning of a line...

There was an error! Please check file settings, compiler settings, ... to fix this issue.

would probably be okay only considering punctuation.