Thunderbird Development JLP (1.5.x.x リリース用) へのフィードバック

ゲスト

取り急ぎ "表示および管理します" の件のみ。
対応が全然追いついていませんが、他についてはまた帰ってから。

v v v wrote:

dynamis wrote:

v v v wrote:

+<!ENTITY extensions.tooltip "インストールされた拡張を表示および管理します">
表示および管理をします/行います

「表示および管理します」ってまずいですかね？私の感覚がマズい？

不味いですね。外国人や機械による日本語じゃあるまいし。

Code:

～の表示、管理

Code:

～の表示および管理

であれば構いませんが。
#今低すぎるところで妥協するとまた長きにわたり恥をさらすことになりかねないのでできる限りまっとうなものにしておくべきです。

小沢 wrote:

dynamis wrote:

v v v wrote:

+<!ENTITY extensions.tooltip "インストールされた拡張を表示および管理します">
表示および管理をします/行います

「表示および管理します」ってまずいですかね？私の感覚がマズい？

並列のものは、文法上の区分をなるべく揃えましょう。
名詞と動詞の並列には違和感を覚える習慣をつけましょう。

多分、dynamisさんの頭の中は
「拡張を(表示 + 管理)します」で、両方名詞が並列で、両方とも「します」で受けているという
分解がなされているのではと推測しますが、
確かに、日本語の流れとして違和感を感じてない人にとっては、少ない字数で
直感的に内容がわかるようにといった気分なんでしょうけど、それにこだわるなら、
dynamisさんの大好きな「および」からしていっそナカグロに（嘘

dynamisさんにとって一読してわかりやすくても、日本語として違和感を感じる人に
とっては、読んで「ひっかかってしまう」ので、読むときにかえって余計な時間がかかります。
「どこの誰にでも必ず一読でわかりやすい」文章なんてないですが、「日本語として変」なゆえに
ひっかかる人がいるものは排除しましょう。

＃dynamisさんとは前にもどこかでなんどかそんな話題をした気がしますので、
＃これ以上でじゃぶー（違）しないように、精一杯の言葉で語ってみるテスト

取り敢えず結論ですが、簡潔ですくなくとも私や私が確認した範囲の周囲の人間数名にとっては一読して分かり易く、後述の通り今のところ他の代案については逆に引っかかりを感じるか誤りであるか、訳のスタイル規則に反するものしか思いつかないため、個別の箇所について文脈に応じた新たなよい代案がない限りそのままになります。

日本語としてどうなのかという点についてはかなり気になったので、知り合いを通じて国語学(書き言葉)の教授に確認をして頂きました。
# 念のためもう一人別の先生にも別の知り合い経由で確認してもらっています。
まず、"拡張機能を表示および管理する" において "および" は複数の動作名詞をつないでいます。動詞と名詞をつないでいるわけではありません。
・動作が連続する場合や、逆もしくは類似する意味を表す動作名詞を複数、
・並列もしくは逆接の接続詞によって繋ぐ場合、
・先に来る動作名詞における "する" は接続詞が入ることで省略(吸収)される。
というのが文法というか、日本語のなりたち(構造)ということだそうです。
「日本語として変」ということはなく、特に修正の必要ない自然な表現だということです。

代案についてですが、始めに頂いた提案である "表示および管理をします/行います" については
拡張機能を表示および管理をします/行います
となると、文中に "を" が複数来て、明らかに破綻します。
拡張機能の表示および管理をします/行います
にすると文想像自体は破綻しませんが、"表示をします/管理をします" と "表示する/管理する" であれば後者が自然であり、文全体の中で使ってもやはり違和感が残ると私は感じます。

"～の表示、管理" や "～の表示および管理" についてはいずれも L10N 全体で統一しているスタイル規則に反します。2つしかないものを読点で繋ぐのは日本語としてもあまりよくない(すくなくとも私は違和感を覚える)し、ですます調で終わらせるべき箇所をこれらだけ体言止めするというのは不統一ないし不自然と感じます。
# 何かの題名にあたる部分など、体言止めが許されるところではこれらが良いが、問題の箇所は該当しない

# 余談ですが、三つ以上を並列する場合は "A[接続詞]B、C" よりも "A、B[接続詞]C" の方がよいとのことです。(誰に言ってるのかw)

日本語として問題ないといっても、読んでいて引っかかりを覚えるという人が複数いるのは事実であるようなので、自然で簡潔且つスタイル規則に反しない他の代案があれば修正します。良いものが思いつきましたら改善案の提案をよろしくお願いします。

登録日: 2003年10月 06日 記事: 296

grepはすぐだと思うんですが、対応状況がよくわからないので、念のために、手元の検索結果を出しておきます。

"@@" をファイルから検索中...
ja\locale\ja\communicator\contentAreaCommands.dtd:7: <!ENTITY openLinkCmd.label "@@NewWindow@@で開く">
ja\locale\ja\communicator\contentAreaCommands.dtd:9: <!ENTITY openLinkCmdInTab.label "@@NewTab@@で開く">
ja\locale\ja\communicator\contentAreaCommands.dtd:13: <!ENTITY openFrameCmd.label "フレームを@@NewWindow@@で開く">
ja\locale\ja\communicator\contentAreaCommands.dtd:15: <!ENTITY openFrameCmdInTab.label "フレームを@@NewTab@@で開く">
ja\locale\ja\communicator\contentAreaCommands.dtd:43: <!ENTITY fitImageCmd.label "画像を@@Window@@にあわせる">
ja\locale\ja\communicator\contentAreaCommands.dtd:57: <!ENTITY savePageAsCmd.label "@@SavePageAs@@...">
ja\locale\ja\communicator\contentAreaCommands.dtd:61: <!ENTITY saveFrameAsCmd.label "@@SaveFrameAs@@...">
ja\locale\ja\communicator\contentAreaCommands.dtd:64: <!ENTITY saveLinkAsCmd.label "@@SaveLinkTargetAs@@...">
ja\locale\ja\communicator\contentAreaCommands.dtd:67: <!ENTITY saveImageAsCmd.label "@@SaveImageAs@@...">
ja\locale\ja\communicator\contentAreaCommands.dtd:78: <!ENTITY metadataCmd.label "@@PropertyCMD@@">
ja\locale\ja\communicator\contentAreaCommands.dtd:82: <!ENTITY pasteCmd.label "@@Paste@@">
ja\locale\ja\communicator\contentAreaCommands.dtd:84: <!ENTITY cutCmd.label "@@Cut@@">
ja\locale\ja\communicator\contentAreaCommands.dtd:88: <!ENTITY undoCmd.label "@@Undo@@">
ja\locale\ja\communicator\contentAreaCommands.dtd:90: <!ENTITY redoCmd.label "@@Redo@@">
ja\locale\ja\communicator\utilityOverlay.dtd:15: <!ENTITY undoCmd.label "@@Undo@@">
ja\locale\ja\communicator\utilityOverlay.dtd:18: <!ENTITY redoCmd.label "@@Redo@@">
ja\locale\ja\communicator\utilityOverlay.dtd:21: <!ENTITY cutCmd.label "@@Cut@@">
ja\locale\ja\communicator\utilityOverlay.dtd:27: <!ENTITY pasteCmd.label "@@Paste@@">
ja\locale\ja\editor\EdColorPicker.dtd:50: <!ENTITY default.label "@@Default@@">
ja\locale\ja\editor\EditorColorProperties.dtd:47: <!ENTITY defaultColorsRadio.label "読者の@@DefaultColor@@ (ページに配色を設定しない)">
ja\locale\ja\editor\EditorHLineProperties.dtd:44: <!ENTITY windowTitle.label "水平線の@@Property@@">
ja\locale\ja\editor\EditorHLineProperties.dtd:62: <!ENTITY saveSettings.label "@@Default-@@設定にする">
ja\locale\ja\editor\EditorImageProperties.dtd:26: <!ENTITY windowTitle.label "画像の@@Property@@">
ja\locale\ja\editor\EditorImageProperties.dtd:45: <!ENTITY MoreFewerButton.tooltip "編集する@@Property@@の数を変更する">
ja\locale\ja\editor\EditorLinkProperties.dtd:38: <!ENTITY windowTitle.label "リンクの@@Property@@">
ja\locale\ja\editor\EditorTableProperties.dtd:38: <!ENTITY tableWindow.title "表の@@Property@@">
ja\locale\ja\editor\EdNamedAnchorProperties.dtd:23: <!ENTITY windowTitle.label "名前付きアンカーの@@Property@@">
ja\locale\ja\global\charset.dtd:1: <!ENTITY charsetMenu.label "@@CharacterEncoding@@">
ja\locale\ja\messenger\am-addressing.dtd:7: <!ENTITY useGlobal.label "@@Global@@ LDAP サーバ設定を使用する">
ja\locale\ja\messenger\am-advanced.dtd:16: <!ENTITY smtpListSetDefault.label "@@DefaultValue@@に設定">
ja\locale\ja\messenger\am-main.dtd:7: <!ENTITY identityTitle.label "@@Default-@@差出人情報">
ja\locale\ja\messenger\am-main.dtd:8: <!ENTITY identityDesc.label "このアカウントで使用する@@Default-@@差出人情報を設定してください。これはメッセージの送信者が誰であるかを表すために使用されます。">
ja\locale\ja\messenger\am-main.dtd:20: <!ENTITY choose.label "@@Browse@@...">
ja\locale\ja\messenger\am-main.dtd:34: <!ENTITY smtpDefaultServer.label "@@Default-@@サーバを使用する">
ja\locale\ja\messenger\am-server-advanced.dtd:26: <!ENTITY globalInbox.label "@@GlobalInbox@@ (ローカルフォルダアカウント)">
ja\locale\ja\messenger\am-server-top.dtd:20: <!ENTITY serverPortDefault.label "@@DefaultValue@@:">
ja\locale\ja\messenger\am-server-top.dtd:60: <!ENTITY modelMoveToTrash.label "@@TrashFolder@@に移動する">
ja\locale\ja\messenger\am-server-top.dtd:66: <!ENTITY emptyTrashOnExit.label "終了時に@@TrashFolder@@を空にする">
ja\locale\ja\messenger\am-server-top.dtd:88: <!ENTITY serverDefaultCharset.label "@@Default-@@ @@CharacterEncoding@@:">
ja\locale\ja\messenger\am-server-top.dtd:91: <!ENTITY browseFolder.label "@@Browse@@...">
ja\locale\ja\messenger\am-server-top.dtd:94: <!ENTITY browseNewsrc.label "@@Browse@@...">
ja\locale\ja\messenger\am-serverwithnoidentities.dtd:6: <!ENTITY emptyTrashOnExit.label "終了時に@@TrashFolder@@を空にする">
ja\locale\ja\messenger\am-serverwithnoidentities.dtd:11: <!ENTITY browseFolder.label "@@Browse@@...">
ja\locale\ja\messenger\CustomHeaders.dtd:7: <!ENTITY newMsgHeader.label "@@NewMessage@@のヘッダ:">
ja\locale\ja\messenger\fieldMapImport.dtd:45: <!ENTITY fieldMapImport.text "左右に表示されたアドレス帳のフィールドを @@[@@上へ@@]@@ ボタンと @@[@@下へ@@]@@ ボタンで適切に合わせてください。">
ja\locale\ja\messenger\FilterEditor.dtd:34: <!ENTITY newFolderButton.label "@@NewFolder@@...">
ja\locale\ja\messenger\folderProps.dtd:41: <!ENTITY folderProps.windowtitle.label "@@Property@@">
ja\locale\ja\messenger\folderProps.dtd:44: <!ENTITY folderCharsetTab.label "@@Default-@@@@CharacterEncoding@@:">
ja\locale\ja\messenger\folderProps.dtd:46: <!ENTITY folderCharsetOverride.label "この設定をフォルダ内のすべてのメッセージに適用する (各メッセージの@@CharacterEncoding@@指定や自動判別結果を無視する)">
ja\locale\ja\messenger\folderProps.dtd:79: <!ENTITY UseDefaultofflineNewsgroup.check.label "アカウント設定の@@DefaultValue@@を使用する">
ja\locale\ja\messenger\junkLog.dtd:3: <!ENTITY clearLog.label "ログを@@Clear@@">
ja\locale\ja\messenger\msgAccountCentral.dtd:11: <!ENTITY newAcctLink.label "@@NewAccount@@を作成する">
ja\locale\ja\messenger\msgHdrViewOverlay.dtd:61: <!ENTITY saveAsAttachmentCmd.label "@@SaveAs@@...">
ja\locale\ja\messenger\msgHdrViewOverlay.dtd:63: <!ENTITY printAttachmentCmd.label ".@@Print@@">
ja\locale\ja\messenger\newFolderDialog.dtd:40: <!ENTITY newFolderDialog.title "@@NewFolder@@">
ja\locale\ja\messenger\newFolderDialog.dtd:47: <!ENTITY folderRestriction2.label "@@NewFolder@@に入れるものを選択してください:">
ja\locale\ja\messenger\smtpEditOverlay.dtd:23: <!ENTITY serverPortDefault.label "@@DefaultValue@@:">
ja\locale\ja\messenger\start.dtd:10: <!ENTITY startpage.globalInbox "@@GlobalInbox@@">
ja\locale\ja\messenger\threadpane.dtd:55: <!ENTITY junkStatusColumn.label "@@JunkStatus@@">
ja\locale\ja\messenger\threadpane.dtd:76: <!ENTITY junkStatusColumn.tooltip "クリックすると@@JunkStatus@@で並べ替えて表示します">
ja\locale\ja\messenger\viewLog.dtd:3: <!ENTITY clearLog.label "ログの@@Clear@@">
ja\locale\ja\messenger\virtualFolderProperties.dtd:1: <!ENTITY virtualFolderProperties.title "@@NewSavedSearchFolder@@">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:28: <!ENTITY printPreviewCardViewCmd.label "カードの@@Print@@プレビュー">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:30: <!ENTITY printPreviewAddressBook.label "アドレス帳の@@Print@@プレビュー">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:32: <!ENTITY printCardViewCmd.label "カードを@@Print@@...">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:36: <!ENTITY printAddressBook.label "アドレス帳を@@Print@@...">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:48: <!ENTITY undoCmd.label "@@Undo@@">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:51: <!ENTITY redoCmd.label "@@Redo@@">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:54: <!ENTITY cutCmd.label "@@Cut@@">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:60: <!ENTITY pasteCmd.label "@@Paste@@">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:78: <!ENTITY propertiesCmd.label "@@PropertyCMD@@...">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:139: <!ENTITY newcardButton.label "@@NewCard@@">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:141: <!ENTITY newlistButton.label "@@NewList@@">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:143: <!ENTITY editButton.label "@@PropertyCMD@@">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:151: <!ENTITY throbberItem.title "@@ActivityIndicator@@">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:168: <!ENTITY clearButton.label "@@Clear@@">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:170: <!ENTITY clearButton.tooltip "検索語句を@@Clear@@して、すべての項目を表示する">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:215: <!ENTITY newAddrBookCard.label "@@NewCard@@...">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:217: <!ENTITY newAddrBookMailingList.label "@@NewAddressList@@...">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:219: <!ENTITY addrBookCardProperties.label "@@PropertyCMD@@">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:240: <!ENTITY windowMenu.label "@@Window@@">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:242: <!ENTITY minimizeWindow.label "@@Minimize@@">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:243: <!ENTITY bringAllToFront.label "@@BringAllToFront@@">
ja\locale\ja\messenger\addressbook\abMainWindow.dtd:244: <!ENTITY zoomWindow.label "@@Zoom@@">
ja\locale\ja\messenger\addressbook\abResultsPaneOverlay.dtd:79: <!ENTITY newAddrBookCard.label "@@NewCard@@...">
ja\locale\ja\messenger\addressbook\abResultsPaneOverlay.dtd:81: <!ENTITY newAddrBookMailingList.label "@@NewAddressList@@...">
ja\locale\ja\messenger\addressbook\abResultsPaneOverlay.dtd:83: <!ENTITY addrBookCardProperties.label "カードの@@Property@@">
ja\locale\ja\messenger\addressbook\abSelectAddressesDialog.dtd:58: <!ENTITY clearButton.label "@@Clear@@">
ja\locale\ja\messenger\addressbook\pref-directory-add.dtd:38: <!ENTITY newDirectoryTitle.label "LDAP サーバの@@Property@@">
ja\locale\ja\messenger\messengercompose\askSendFormat.dtd:10: <!ENTITY convertibleNo.label "このメッセージでは@@Colors@@などのプレーンテキストでは表現できない書式を利用していますが、これらをプレーンテキストで表現することはできません。">
ja\locale\ja\messenger\migration\migration.dtd:2: <!ENTITY migrationWizard.title "設定移行@@Wizard@@">
ja\locale\ja\messenger\preferences\defaultClient.dtd:1: <!ENTITY window.title "@@Default-@@クライアント設定">
ja\locale\ja\messenger\preferences\defaultClient.dtd:4: <!ENTITY whenStartingCheckFor.label "&brandShortName; が起動するとき、次の@@DefaultApplication@@として設定されているか確認する">
ja\locale\ja\messenger\preferences\htmlcompose.dtd:1: <!ENTITY dialog.title "@@Default-@@書式">
ja\locale\ja\messenger\preferences\htmlcompose.dtd:2: <!ENTITY defaultMessagesHeader.label "HTML メッセージの@@Default@@の書式">
ja\locale\ja\messenger\preferences\htmlcompose.dtd:13: <!ENTITY restoreDefaults.label "@@RestoreDefaults@@">
ja\locale\ja\messenger\preferences\notifications.dtd:12: <!ENTITY browse.label "@@Browse@@...">
ja\locale\ja\messenger-newsblog\feed-properties.dtd:2: <!ENTITY window.title "RSS フィードの@@Property@@">

登録日: 2003年10月 06日 記事: 250

添付ファイル削除機能欲しさに Thunderbird に乗り換えてしまった…のと、リハビリ代わりにちょっといくつか。

「インストールされた拡張を表示および管理します」

Windows のプログラムの追加と削除のツールチップを思い浮かべました。私には違和感ありません。

dynamis@out wrote:

"～の表示、管理" や "～の表示および管理" についてはいずれも L10N 全体で統一しているスタイル規則に反します。2つしかないものを読点で繋ぐのは日本語としてもあまりよくない(すくなくとも私は違和感を覚える)し、ですます調で終わらせるべき箇所をこれらだけ体言止めするというのは不統一ないし不自然と感じます。
# 何かの題名にあたる部分など、体言止めが許されるところではこれらが良いが、問題の箇所は該当しない

テキストとチップスは「ですます調」と下記で明記してもいいのではと思います。

http://www.mozilla-japan.org/jp/l10n/guide.html

dynamis@out wrote:

# 余談ですが、三つ以上を並列する場合は "A[接続詞]B、C" よりも "A、B[接続詞]C" の方がよいとのことです。(誰に言ってるのかw)

文法の授業で、日本語は "A[接続詞]B、C" で、英語は "A、B[接続詞]C" と習ったので守っていたのですが、最近は日本語も "A、B[接続詞]C" とか "A、B、C" が主流のようですね。

ゲスト

dynamis@out wrote:

そのままになります。
代案についてですが、始めに頂いた提案である "表示および管理をします/行います" については
拡張機能を表示および管理をします/行います
となると、文中に "を" が複数来て、明らかに破綻します。
日本語として問題ないといっても、読んでいて引っかかりを覚えるという人が複数いるのは事実であるようなので、自然で簡潔且つスタイル規則に反しない他の代案があれば修正します。良いものが思いつきましたら改善案の提案をよろしくお願いします。

Code:

拡張機能を表示および管理をします/行います

なんて馬鹿なことしかできないんですか。拡張機能の云々とすべきでしょう。

体言止めにするなら「を」ではなく「の」を使うべき箇所はこれに限らず多々あるわけで、
そこまで低い次元で反論をされるようでは、こちらとしてはどうしようもありませんね。
これでは提案をどうしても受け入れたくないがための言い訳と受け取らざるを得ません。
あまりに馬鹿馬鹿しいので、訳についてのフィードバックも含めてもう言わないことにします。
#英語版で困るわけでもないし。

ゲスト

単純に

Quote:

拡張機能の表示と管理

で済むものを長くした上で悪くして固持するような連中の相手はしてられない、ということですね。
ほなさいなら♪

登録日: 2004年1月 09日 記事: 552

v v v wrote:

体言止めにするなら「を」ではなく「の」を使うべき箇所はこれに限らず多々あるわけで、
そこまで低い次元で反論をされるようでは、こちらとしてはどうしようもありませんね。
これでは提案をどうしても受け入れたくないがための言い訳と受け取らざるを得ません。

これはツールチップ（マウスポインタを合わせると表示される文）なので、ここだけ体言止めにすると不自然です。
直すべきところはたくさんありますが、表示個所によって統一感を守るのも大切ではないでしょうか。

登録日: 2003年10月 06日 記事: 250

ふぉーちゅん wrote:

Windows のプログラムの追加と削除のツールチップを思い浮かべました。私には違和感ありません。

ちょっと舌足らずなので、加筆。

「プログラムの追加と削除」が「プログラムやWindowsコンポーネントをインストールおよび削除します」

などと使われていて、違和感ありません。

登録日: 2003年10月 06日 記事: 296

メール等のcomposeウインドウのメニューの「Spell As You Type」ってそのまま残す予定じゃないですよね？
名案募集中？

オプション内では「Spell As You Type(自動スペルチェック）」にしてるので、名案なければ「自動スペルチェック」で
いいんじゃないかと思ったり。
＃使いこなしてませんが、FAYTほど独特の概念じゃないですよね・・・？

登録日: 2003年10月 06日 記事: 296

連続投稿失礼。。。

\src\mozilla1.8\ja\mail\chrome\messenger\preferences\compose.dtd
<!ENTITY autocompleteText.label "When addressing messages, look for matching entries in:">
<!ENTITY autocompleteText.label "メールアドレスの入力時に、以下に登録されたものと一致するものを探す:">
「アドレスの自動補完」のタイトルが示すとおり、「探す」ことに本質があるわけではないですね。この点について私には英語には日本語ほどの不自然さを感じないのは
気のせいなのか何なのかわかりませんが、

「メールアドレスの入力時に、以下に登録されたものと一致したら自動補完する。」
でどないでしょ？
＃和訳については「もの」という単語の重複が理解度を落としているというのもありますし。

登録日: 2003年10月 11日 記事: 228 所在地: 内地

小沢 wrote:

メール等のcomposeウインドウのメニューの「Spell As You Type」ってそのまま残す予定じゃないですよね？
名案募集中？

オプション内では「Spell As You Type(自動スペルチェック）」にしてるので、名案なければ「自動スペルチェック」で
いいんじゃないかと思ったり。
＃使いこなしてませんが、FAYTほど独特の概念じゃないですよね・・・？

MS Wordの自動スペルチェックと同じで、独特な機能と言う訳ではありません。
MS Wordのオプション設定でも「自動スペルチェック」となっているので、このままでも良いかと。

登録日: 2003年10月 06日 記事: 296

src\mozilla1.8\ja\mail\chrome\messenger\addressbook\abCardOverlay.dtd
src\mozilla1.8\ja\mail\chrome\messenger\addressbook\abNewCardDialog.dtd
<!ENTITY PhoneticField1.label "ふりがな:">
<!ENTITY PhoneticField2.label "ふりがな:">
「振って」ない「ふりがな」って違和感があります。「ふりがな」はruby表示されるものに限定したいんですが、「よみがな」「よみ」等ではいかんですか？
＃データとしては何でも入っちゃうので読みもかなもへったくれもないんですが。

WinXPだとダイアログのラベルとinput boxがずれているように見えるのは、英語でも同じなんですが、うーみ。

<!ENTITY ScreenName.label "スクリーンネーム:">
これって、IMのスクリーンネームで、デフォルトではプロトコルaimで、IM連携でAIMが呼び出される（AIM等aim対応のIMが入ってなければ何も動作しない）ってことですよね。
「スクリーンネーム」のみ、うーみ。。。
AIMを入れて試してみると、、、連携できますね。・・・日本語以外（大汗・・・いや、少なくともAIMのスクリーンネームはいわゆる半角英数だけしか登録できないようでどうでもいいんですが、、、、、プロトコルとしてのaimのことは私は知りません。。。

登録日: 2003年10月 05日 記事: 1744

続けて本件だけ取り急ぎ。他については Firefox へのフィードバックから順に今夜できる限りします。
# もう遅いけど、やっぱトピック分けるべきだったかな…(^^;

dynamis@out wrote:

日本語としてどうなのかという点についてはかなり気になったので、知り合いを通じて国語学(書き言葉)の教授に確認をして頂きました。
# 念のためもう一人別の先生にも別の知り合い経由で確認してもらっています。
まず、"拡張機能を表示および管理する" において "および" は複数の動作名詞をつないでいます。動詞と名詞をつないでいるわけではありません。
・動作が連続する場合や、逆もしくは類似する意味を表す動作名詞を複数、
・並列もしくは逆接の接続詞によって繋ぐ場合、
・先に来る動作名詞における "する" は接続詞が入ることで省略(吸収)される。
というのが文法というか、日本語のなりたち(構造)ということだそうです。
「日本語として変」ということはなく、特に修正の必要ない自然な表現だということです。

もう一人全く別の国文学の教授にも別経由で確認してもらった方も返事が返ってきました。今度答えてくれた方は修正案として一緒に見て頂いた "拡張機能の表示および管理をする" の方が良いということでした。その理由は
・この場合は "表示する" と "管理する" の2つの動詞を並列している
・ "および" や "や" などが並列する対象は名詞であるのが普通
・この場合は名詞ではなく動詞を並列しているというところが不自然
とのことです。動詞と名詞の並列だと認識する事はないが、並列している対象を動作名詞と捉えるか動詞と捉えるかという点(?)はどうも解釈が分かれるといった感じでしょうか。

整理すると "証明書を表示および管理する" と "証明書の表示および管理をする" という表現がスタイル規則に反しない候補であるが
・最良でないかもしれないが、スタイル規則に反してまで修正が必要な誤りではない
・形式的な正しさのみならず一般的なユーザの感覚も踏まえて考慮・判断される
・いずれの表現であってもそれぞれ不自然さなどを感じる人がいてどちらが良いとは言い難い
ということで、
・修正をする場合は統一性を保つために全リソースに渡って修正すべきだが、今それをする余裕はない
・単発表現としては "表示をする" や "管理をする" ではなく "表示する" や "管理する" を使用しており、それとの統一性が得られる
という理由により、現状の表現のままにします。

誤解を恐れず一言で言えば、どちらが良いとも言えなさそうなのでそのまま放置ということです。
# 今後の修正は十分あり得るが、即時修正が必要とは考えないという話です。念のため。

因みに国文の教授に聞いてもらったのは文法等に拘りたいのではなく、単に私には判断しかねたからさっさとギブアップして、ちょうど都合よく聞ける人に頼ってみたという情けない話です。いつも話が理論的で長くなるのは私が、感覚的に理解する能力が欠如しているとかもっとマシな説明をする力がない、理系馬鹿(屁理屈爺)だというだけのことです。
皆さんはあまり堅くならずに今後も気楽にフィードバックくださいませ。自分の感覚で何か気に食わないというだけで十分というか、それが一番大事です。(^^;

用字・用語の選択基準などが不明瞭(dynamis の偏見で選ばれてるぞ)といった問題については、今後よりクリアになるように何か考えておきます。 1.5 リリース後にまた別トピック立てて話題にしてみようかと思いますが、何か提案があればいつでも何処でもどうぞ。

以下、関連する返信について。

ふぉーちゅん wrote:

テキストとチップスは「ですます調」と下記で明記してもいいのではと思います。

http://www.mozilla-japan.org/jp/l10n/guide.html

全体の原則が「ですます調」であり、体言止めなどそれに反するものについてのみ言及している形にしたつもりだったのですが、1.5 リリース後にでも、更にもう少し詳しく書くのと同時に明記しておきます。

ふぉーちゅん wrote:

dynamis@out wrote:

# 余談ですが、三つ以上を並列する場合は "A[接続詞]B、C" よりも "A、B[接続詞]C" の方がよいとのことです。(誰に言ってるのかw)

文法の授業で、日本語は "A[接続詞]B、C" で、英語は "A、B[接続詞]C" と習ったので守っていたのですが、最近は日本語も "A、B[接続詞]C" とか "A、B、C" が主流のようですね。

一緒に書いてしまいましたが、これについては教授に確認してもらったことではなく、私が調べていて見つけた記述でしたので、信頼性は高くないです。取り敢えず法律系の文章では "A、B[接続詞]C" が規則っぽいですが、再度ちょっと見たら広辞苑では "AまたはB-C" と書いてありました。
従って、通常の日本文ではふぉーちゅんさんが習ったとおり "A[接続詞]B、C" が良いのかも。(^^;
どちらが普通なのか、どちらでもよいのか、使い分けがあるならどういう場面で使い分けになるのかなど不明です。m(_ _)m

取り敢えず JLP においては現状既に "A、B[接続詞]C" が主流なので、これに揃えるつもりです。
# 何処かで誰かが書いてくださったように、どちらでも良いような細部に拘ってる場合じゃないので

v v v wrote:

dynamis@out wrote:

そのままになります。
代案についてですが、始めに頂いた提案である "表示および管理をします/行います" については
拡張機能を表示および管理をします/行います
となると、文中に "を" が複数来て、明らかに破綻します。
日本語として問題ないといっても、読んでいて引っかかりを覚えるという人が複数いるのは事実であるようなので、自然で簡潔且つスタイル規則に反しない他の代案があれば修正します。良いものが思いつきましたら改善案の提案をよろしくお願いします。

Code:

拡張機能を表示および管理をします/行います

なんて馬鹿なことしかできないんですか。拡張機能の云々とすべきでしょう。

体言止めにするなら「を」ではなく「の」を使うべき箇所はこれに限らず多々あるわけで、
そこまで低い次元で反論をされるようでは、こちらとしてはどうしようもありませんね。
これでは提案をどうしても受け入れたくないがための言い訳と受け取らざるを得ません。
あまりに馬鹿馬鹿しいので、訳についてのフィードバックも含めてもう言わないことにします。
#英語版で困るわけでもないし。

段落毎に各提案に対する検討を、誰が読んでも分かるよう自明なことも含めて書いたつもりでしたが、前半3行だけに注目して誤解されたようで残念です。 "拡張機能の表示および管理をします/行います" や "拡張機能の表示および管理" にすれば誰もが違和感なくなり統一性も保てるものになるとは感じられなかったため、即時採用しなかっただけです。

どのような形であれ建設的な提案は歓迎であり、多くの指摘を頂いていることには大変感謝していますが、誤解を招くよう省略された引用をした上で非難されても困ります。
# 都合良く今後もフィードバックだけくれといっているつもりはありません。念のため。
# 気がついた人が気の向いたときにするのがフィードバックですから。

登録日: 2003年10月 05日 記事: 1744

Joker wrote:

Tb バージョン 1.5 (20051024)（1.8branch L10N nightly build）ですが、以下の部分で@@キーワード@@と表示されます。

JLP リリースのところに書きましたが、私の CVS 操作ミスでした。
すぐに修正したつもりが、手元の環境が壊れていたようで、修正されたように見えて実際の CVS には反映されていないという哀しい状況になっていました。お騒がせしてごめんなさい。
# 最近はこまめにチェックインしていたつもりだったので哀しさ倍増。

既に checkin はバグ立てて許可を取ってからという次期になっており、繰り返し何度も大量のチェックイン許可を取るのは難しいので、Thunderbird まわりのフィードバック対応した時点で許可をリクエストしてコミットします。
# 今すぐコミットしても RC2 には反映されないようです。
L10N Nightly や L10N RC1,2 に最新 JLP 適用という形でテストして頂けると嬉しいかも知れません…m(_ _)m

Anonymous wrote:

dynamis wrote:

「気にせず HTML のまま送信」については "HTML 形式で送信すること" と "望ましくないことをしているのだということ" が確実に認識される必要のある選択肢です。やっている事が乱暴なので、言い方も乱暴なんですが、以上2点が正しく伝わる、柔らかな表現を継続募集。

「HTML のまま送信（おすすめしません）」とか「HTML のまま送信（推奨しません）」はどうでしょうか。
逆にオススメの選択肢に「（推奨）」をつけるとか。

Cai wrote:

ここは英語版に倣って「HTMLのまま送信」でいいのではないでしょうか。ことさら"望ましくないこと"であることを強調する必要はないと思います。
強調するのならここだけでなくアカウント設定 -> 編集とアドレス入力の「HTML形式でメッセージを編集する」も要改善。
（そもそもデフォルトでHTML形式が選択されている理由を小一時間問いつうわなにをするやめ）

英語版の "Send the message in HTML anyway" に対して "HTML のまま送信" だけだと anyway に込められた、受信者の設定無視して大丈夫かいという配慮(お節介？)が無視されてしまうと感じるのですが、かといって "(推奨しません)" とまで書くと強くなりすぎてしまいます。
さり気なく自然な日本語が書けずに、妖しげな "気にせず～" になってしまったわけですが…
受信者によらず HTML のまま送信する
というのはどうでしょうか？選択項目の長さ的にも他と揃って良いかと思うのですが。
# 取りあえずこれにしてみます。
これもいまいちだよーというのであれば、anyway の訳出は諦めて "HTML のまま送信する" だけにします。

Anonymous wrote:

dynamis wrote:

-> UTF-8 など 8 ビットの文字エンコーディングを使用するメッセージは Quoted-Printable 方式で 7bit に MIME エンコードする(チェックしなければ 8 ビットのまま送信します)。
やや長いですが、既に 2行になっているので開き直ってみました。改善案募集。

「UTF-8 など 8 bit 文字を含む文字エンコーディングを使う場合、Quoted-Printable エンコードする」
あたりでどうでしょう？ "(チェックしなければ 8 ビットのまま送信します)" は自明だと思います。
# 多くの日本人には縁が薄いのであれば、ここはさらっと流してしまってよいと思います。
# 海外とやりとりが多い人にはヘルプ経由で調べて設定してもらうということで。

Cai wrote:

「8 ビットの文字エンコーディングは Quoted-Printable 方式で 7 ビットに MIME エンコードする」
ちょっとはしょりすぎですがこれなら1行におさまります。ゲストさんと同じく"(チェックしなければ 8 ビットのまま送信します)"はなくても良いかと。

揚げ足取りみたいですが、ゲストさんのものだと Quoted-Printable はあくまで方式であり、"Quoted-Printable エンコード" という言い方は普通しないと思うのと
Cai さんのものでは MIME エンコードの対象が文字列ではなく文字エンコーディングなるものというような係り受けに引っかかります。
8 ビットの文字エンコーディングを使うメッセージは Quoted-Printable 方式で MIME エンコードする
というのにしてみようかと思いますが、如何でしょうか。
何を、どうするのかということが明確になる部分だけ残し、UTF-8 などの例や 7 ビットになることと、括弧部を削った形。大抵の環境で1行に収まるはず。
Quoted-Printable というのは Base64 との区別上外せないが、それが 7bit にするためのものであることは知っている人には明らか。普通のユーザは 7 bit にエンコードする理由すら知らないのだから、そこを強調する必要はないか…ということで 7bit については言及しない形。
# 英語でも 7 bit については触れていないし。

結局よく分からない設定項目っぽいですが、一見日本人に関係しそうだけど実はほとんど関係してこない話なので、しつこく書く必要もなさそうですね。
個人的には Thunderbird はところどころでこーいった高度な設定を初心者がすぐに見るところと一緒に織り交ぜてしまっているのが一番問題じゃないか…と責任転嫁してみたり。
# こーいうところのためにオンラインヘルプが欲しいのにねぇ…(^^;

Anonymous wrote:

dynamis wrote:

-> 受信メッセージを保存する前に、ウィルス対策ソフトがメッセージを個別に分析できるようにします。
-> [　] ウィルス対策ソフトが受信メッセージを個別に隔離できるようにする
# 繰り返しの説明になってますが、全体の動作と、実際の目的という別の視点の表現のつもり
level さんの案のままの方が良いとか、もっと良いのがあるとか、改善案募集。

一連の返信を読んで、どういうことをいいたいのか分かりました。こんなのはいかがでしょう？

説明文：
「ウイルス対策ソフトがウイルスを検出したとき、感染したメッセージだけが処理されるようにします。」
「メッセージをローカルフォルダに保存する前にウイルス対策ソフトがウイルスを検出できるようにします。」
「受信したメッセージを保存する前にウイルス対策ソフトがウイルスを検出できるようにします。」
Checkbox：
「受信したメッセージは 1 件ずつ一時ファイルに保存した後にローカルフォルダへ移動する」

Norton Antivirus にならい "analyze" は "検出" としました。
"受信メッセージ" は違和感がありますので、"受信したメッセージ" としました。
案の「ウィルス対策ソフトが受信メッセージを個別に隔離できるようにする」では具体的にどんな処置がなされるのかまったく分からないので、不安感が拭えません。

Cai wrote:

ウイルス対策ソフトがウイルスを検出したとき、問題のあるメッセージだけが処理されるようにします。
[ ]受信したメッセージをローカルに保存する前に一旦テンポラリファイルに保存する

チェックボックスは具体的な振る舞いが書いてある方が良さそうですね。というか、それが本来あるべき当然のことか…
実際のところはウィルス対策ソフト側の挙動によるもので、あくまでもこの設定は "可能にする" というレベルに過ぎないので(そんなところ拘らるより分かり易くしろという声が聞こえてきそうですが…)
# 更にしつこくいえば "簡単に可能にする" なんだけど、それはまぁもぅ…(^^;
また、テンポラリファイルも("Local Folders" ではないが)ローカルではあるのが矛盾に聞こえてしまうとか細々した事を配慮して、
ウィルス対策ソフトがウィルスを検出したとき、感染したメッセージだけを処理できるようにします。
[ ] 受信したメッセージは一旦個別の一時ファイルとして保存してからメールボックスに移動させる
はどうでしょうか。少し言い回しが良くないかな？
他の設定項目同様に、最初に全体の目的でチェックボックスには実際の挙動という感じです。
# 本当はウィルスを検出するのが先(検出したとき～)じゃなくて個別に保存するのが先なんだけど、そこは気にせず読みやすさ優先で。(^^;

Anonymous wrote:

ちなみにこれがデフォルトでONでないのは何故なんでしょうね？？

この設定に関わるような動作をするウィルスソフトをインストールしていないユーザにとっては処理を遅くするだけの無意味な動作だからではないでしょうか。
ファイルを保存した瞬間の検出に対応していないか、POP などの通信時点で検出するか、MailDir 形式を解析して普通に単一メッセージだけを隔離する処理をしてくれるとか…
まぁ、安全性優先なら性能無視してデフォルト ON というのもありな気もしますが…

登録日: 2005年5月 27日 記事: 176 所在地: 東京

dynamis wrote:

英語版の "Send the message in HTML anyway" に対して "HTML のまま送信" だけだと anyway に込められた、受信者の設定無視して大丈夫かいという配慮(お節介？)が無視されてしまうと感じるのですが、かといって "(推奨しません)" とまで書くと強くなりすぎてしまいます。
さり気なく自然な日本語が書けずに、妖しげな "気にせず～" になってしまったわけですが…
受信者によらず HTML のまま送信する
というのはどうでしょうか？選択項目の長さ的にも他と揃って良いかと思うのですが。
# 取りあえずこれにしてみます。
これもいまいちだよーというのであれば、anyway の訳出は諦めて "HTML のまま送信する" だけにします。

dynamis wrote:

揚げ足取りみたいですが、ゲストさんのものだと Quoted-Printable はあくまで方式であり、"Quoted-Printable エンコード" という言い方は普通しないと思うのと
Cai さんのものでは MIME エンコードの対象が文字列ではなく文字エンコーディングなるものというような係り受けに引っかかります。
8 ビットの文字エンコーディングを使うメッセージは Quoted-Printable 方式で MIME エンコードする
というのにしてみようかと思いますが、如何でしょうか。
何を、どうするのかということが明確になる部分だけ残し、UTF-8 などの例や 7 ビットになることと、括弧部を削った形。大抵の環境で1行に収まるはず。
Quoted-Printable というのは Base64 との区別上外せないが、それが 7bit にするためのものであることは知っている人には明らか。普通のユーザは 7 bit にエンコードする理由すら知らないのだから、そこを強調する必要はないか…ということで 7bit については言及しない形。
# 英語でも 7 bit については触れていないし。

結局よく分からない設定項目っぽいですが、一見日本人に関係しそうだけど実はほとんど関係してこない話なので、しつこく書く必要もなさそうですね。
個人的には Thunderbird はところどころでこーいった高度な設定を初心者がすぐに見るところと一緒に織り交ぜてしまっているのが一番問題じゃないか…と責任転嫁してみたり。
# こーいうところのためにオンラインヘルプが欲しいのにねぇ…(^^;

dynamis wrote:

チェックボックスは具体的な振る舞いが書いてある方が良さそうですね。というか、それが本来あるべき当然のことか…
実際のところはウィルス対策ソフト側の挙動によるもので、あくまでもこの設定は "可能にする" というレベルに過ぎないので(そんなところ拘らるより分かり易くしろという声が聞こえてきそうですが…)
# 更にしつこくいえば "簡単に可能にする" なんだけど、それはまぁもぅ…(^^;
また、テンポラリファイルも("Local Folders" ではないが)ローカルではあるのが矛盾に聞こえてしまうとか細々した事を配慮して、
ウィルス対策ソフトがウィルスを検出したとき、感染したメッセージだけを処理できるようにします。
[ ] 受信したメッセージは一旦個別の一時ファイルとして保存してからメールボックスに移動させる
はどうでしょうか。少し言い回しが良くないかな？
他の設定項目同様に、最初に全体の目的でチェックボックスには実際の挙動という感じです。
# 本当はウィルスを検出するのが先(検出したとき～)じゃなくて個別に保存するのが先なんだけど、そこは気にせず読みやすさ優先で。(^^;

HTML形式とMIMEエンコードについてはdynamisさんの案のほうがベターだと思います。
たしかにMIMEエンコードの設定はUIじゃなくてuser.jsでいいよなぁ？と思いますが、あるものは仕方がないですね。
ウイルス対策ソフト対策についてはもう少しこなれた表現がないものかと無い頭をひねってますがお手上げです。
一連の議論を追っかけてみて、日本語って難しいなぁとつくづく感じました Sad

dynamis wrote:

Anonymous wrote:

ちなみにこれがデフォルトでONでないのは何故なんでしょうね？？

この設定に関わるような動作をするウィルスソフトをインストールしていないユーザにとっては処理を遅くするだけの無意味な動作だからではないでしょうか。
ファイルを保存した瞬間の検出に対応していないか、POP などの通信時点で検出するか、MailDir 形式を解析して普通に単一メッセージだけを隔離する処理をしてくれるとか…
まぁ、安全性優先なら性能無視してデフォルト ON というのもありな気もしますが…

ウイルス対策ソフトを導入していないユーザーにとっては何の意味もありませんからね。
さすがにNortonなどがインストールされていることをThunderbirdのインストール時に検出して自動的にON,OFFを切り替えるなんて芸当は無理でしょうし（可能かもしれないけどバグが続出しそうなので...）

#むしろHTML形式がデフォルトなのが許せません Confused

#新しくノートPCに導入した時に、テキスト形式に直すのを忘れて一週間ほどHTML形式でメールをばら撒いていたという苦い思い出が...

ついでにJLPの動作報告です。
Thunderbird development JLP 1.0.14 + Thunderbird mozilla1.8 branch (2005111116) / Win2k SP4 and WinXP pro SP2
でパースエラーもなく特に問題なく動作しています。
ここしばらく大学の方が忙しくて死にかけてましたが、とりあえず今年いっぱいはそれなりに時間が作れそうな状況です。
死なない程度にフィードバックしていきます。

登録日: 2003年10月 05日 記事: 1744

Firefox は基本的な UI を一通り確認したところ、あちこちボロがあるなぁ…という感じでしたが、Thunderbird の方は…(>_<)…(T T)…(>_<)…という感じですね…m(_ _)m

小沢 wrote:

「メールには通常」をカットしちゃダメ？

カットしました。

小沢 wrote:

＞値を編集する項目を上から選んでクリックしてください
の方が好みかなぁ。

もっと言うと、
＞値を編集したい項目を上から選んでください
くらいでどかな、とか。

値を編集する項目を上から選んでください。
特に理由がなければ "～したい" という希望の形で書くことはなく、個々は単なる選択肢を選べといっているだけだから。

小沢 wrote:

HTMLのリスト：属性と値
CSSのリスト：プロパティと値
JavaScriptのリスト：属性と値
上記すべてについて、編集boxのラベル：属性名と属性値
で、attiributeとvalueを「属性／属性名」と「値／属性値」とそれぞれ訳し分ける必要があるかどうなんでしょう、
少なくともプロパティにも使われるものについては「属性値」にしてしまうより「値」にしておいたほうが無難なんじゃないかと。

実際の UI で確認しました。明らかに「値」でなければならなかったところですね。

小沢 wrote:

ターゲットという訳を使っている一方、
<td>formatRemoveNamedAnchors.label</td><td>Remove Named Anchors</td><td>名前付きアンカー(ターゲット)を削除</td></tr>
注釈として混在、その他アンカーという訳語の部分が大量にあります。
使い分けの意図が明確であればいいんですけれども。

使い分けの意図はありません。統一せず放置されていただけです。
<a> 要素についてはアンカーで統一したつもりです。

小沢 wrote:

「ターゲット」という単語は要りますか？もしくは、アンカーの方を追放する？
「表」と「テーブル」は単なる不統一？それとも、意味としての「表」と「tableタグ」を意識してわけた結果とか？

リンク元側から見る場合は「ターゲット」、リンク先として名前を付ける方からはアンカーで。
「表」に原則統一。タグを指す場合と区別するのもダメではないですが、現状そうなっていないし、あまりその利点が感じられないので。

小沢 wrote:

箇条書きについて、
「説明文」と「用語の解説」ってのは不統一ぎみですねぇ。
「行頭文字付き」と「記号付き」うーみ。

定義リストをベースにしたものに変更。
dl は定義を表すもので用語に限らないし、説明文という言い方も HTML 知っている人からすると意味不明なだけで利点はない。
行頭文字付きリスト。
ul を表すために使う言葉には行頭文字、行頭記号、順序無し、順番無し、番号無し、順不同、見出し記号…などなどで定訳がないので困ったものなのですが、少なくともこの UI 上では頭に何かを付けたリストを書くために使うものだということが分かることが必要十分と考えます。
そのため、順序無しなど否定表現ではなく、行頭文字があるという肯定表現にしました。
なお、記号とは限らないのと、Google さんの投票により行頭記号ではなく行頭文字。

小沢 wrote:

src\mozilla1.8\ja\editor\ui\chrome\dialogs\EdConvertToTable.dtd
<!ENTITY instructions1.label "Composer は各段落を新しいテーブルの行に変換します。">
「Composer」って他でも使ってましたっけ？

Suite 時代の残骸が残っているようです。取りあえず使われてそうな範囲のリソースについてはお亡くなりになってもらいましょう。
ここでは Firefox や Thunderbird 同様に必要ない主語として削除。
# ついでに別所で Navigator さんも一匹残っていたので駆除しました。

小沢 wrote:

<!ENTITY collapseSpaces.tooltip "Convert adjacent spaces to one separator">
<!ENTITY collapseSpaces.tooltip "隣接した複数のスペースを 1 つの区切り文字に変換します">
表に変換したいので、1 つの区切り文字とみなしてはいるかもしれませんが、separatorは文字ではなく、セルの境界なのではないかと。

小沢 wrote:

src\mozilla1.8\ja\editor\ui\chrome\composer\editor.properties
List = リスト
List=List
これが、メニューバーの「リストプロパティ」になって、
開くと、
mozilla1.8\ja\editor\ui\chrome\composer\editorOverlay.dtd
<!ENTITY listProps.label "箇条書きの@@PropertyCMD@@...">
<!ENTITY listProps.label "List Properties...">
と同じダイアログ
「箇条書きのプロパティ」になって、一方で、「リストプロパティ」と同じメニューで、

mozilla1.8\ja\editor\ui\chrome\composer\editorOverlay.dtd
<!ENTITY formatlistMenu.label "リスト">
<!ENTITY formatlistMenu.label "List">
が出てくる、と。
さーて、どうしたものか（号泣

「箇条書き」にもお亡くなりになってもらいました。