岩橋いさなです。 先月（2021年4月）、久しぶりにWeblateでの翻訳提案に少し取り組んでいたのですが、元気が足りなくてMLでの査読依頼を不精し、Telegramでだけ報告していました。提案にはいくらかの議論余地のあるものが（そこそこ）含まれていて、そのうち差し当たってひとつの論点について「背景についてMLに説明を投げ」るよう査読者から依頼がありました。依頼の背景（注目されている問題点）が汲めていない中ですが、一通りご説明したいと思います。 問題となっている論点は 「UIの、原文にアクセラレーターキー指定（「~」）がないメニュー項目において、翻訳でキーを指定することの是非」 だと思います。 代表してひとつ具体例を示します。 出現箇所 ： Draw メニュー シェイプ KeyID ： F3ogU 原文 英語 ： Rectangle 訳文 現状 日本語 ： 長方形 訳文 いさな提案 ： 長方形(~T) 実装 現状 7.2a0 ja ： 長方形(~J) 実装 現状 7.2a0 en-US ： Rec~tangle Weblate URL ： https://translations.documentfoundation.org/translate/libo_ui-master/officecfgregistrydataorgopenofficeofficeui/ja/?checksum=8455cfe7d290a884 # 「実装 現状」ではアクセラレーターキー表示位置をチルダで表現していますが、実際にはアンダーバー表示です。 ご覧のように、アクセラレーターキーの指定がない原文に対し、私からは勝手にキー指定を付した翻訳を提案しています。 このようなことをして良いのか？というのが論点だと思っています。 同様の提案は39件上げていて、ここに列挙すると収集がつかなくなるので割愛させていただきます。ニーズがあるようでしたら別メールで。 Telegramにはこの時の提案一覧を貼り付けていますので(https://t.me/liboja/6728)、ご覧になれる方はどうぞ。「作業区分」列で「Draw メニュー ～」としてあるものが対象になります。 話の発端はTelegramでの「Drawに「3D回転体に変換」というメニュー項目が2箇所存在するのは何故？」という問いでした(https://t.me/liboja/6666)。この問い自体についてもペンディングのままと思いますが、続く現象確認の会話の中で、それぞれに割り当てられているアクセラレーターキーが解せない、という話になりました（Telegramがご覧になれる場合は https://t.me/liboja/6676 この記事以下の流れです）。 原文「To 3D ~Rotation Object」と「In 3D Rotation Object」に対して、それぞれアクセラレーターキーが「R」と「B」に割り当てられているのが現状です。「何故Bだ？」と。これはキー指定がない項目について自動採番が行われるためでした。ところがen-US環境では状況が違っていて、それぞれ「R」と「I」（原文の先頭文字です）が割り当てられ、ja環境とは違ってしまってます。 そういう意識で眺めてみると、同様の状況が大量に存在していることを認識させられて愕然としました。Drawの「ページ」メニューなど特に酷い有様です。これがen-US環境では比較的（あくまで「比較的」）まっとうなキーが割り当てられているように見えます。 これは…よろしくないのでは？…というのが、今回の私の提案の背景です。 論点に対して、視点もいくつかあろうかと思います。 ひとつにはこのような翻訳（勝手にそれっぽい指定文字列の付与）をした際に「実際のアクセラレーターキーの動作がどうなるのか」ということがあるでしょう。 大変無責任で恐縮ですが、すみません、この点私自身確たる検証は出来ていません。他にそういうことをしている翻訳箇所があるのかどうかも確認できていません。 ただドイツ語などではそのような翻訳が行われていて、動作しているということなのではないかと推察します（CJKでないのがちと不安点ですが…）。 原文 英語 ： Rectangle 訳文 現状 ドイツ語 ： Re~chteck Weblate URL ： https://translations.documentfoundation.org/translate/libo_ui-master/officecfgregistrydataorgopenofficeofficeui/de/?checksum=8455cfe7d290a884 仮に動作に問題がないとして、そのような勝手なキー指定を翻訳で行うことが（日本語コミュニティーとして）許されるのかどうか、という話が次にあると思います。 これはコミュニティーの議論と判断に委ねるよりないところかと思いますが…、私は「やるべきではないだろうか」という立場で提案させていただいています。背景は次のようなところです。 【推進理由】 * 自動採番によるキー割り当てはなるべく少ない方がいいと考える（個人的には自動採番はない方がいいかも知れないとさえ考えている） + 従前より採用されてきている英語ベースのキー指定と考え方が整合せずユーザーを当惑させがち + （恐らくは）メニュー構成の変更によってキー割り当てが変化してしまい、将来の継承性に課題を抱える * 翻訳ではなく原文改訂や、場合によっては開発対応が望ましい案件かも知れないが、影響も大きくハードルが高いのではないか + 少なくとも私自身では対応困難 + 見通しの立たない対応を待っていつまでも放置するより、大きな害がなさそうならば差し当たってのその場対応を講じても良いのではないか + 現にドイツ語では同様の措置を実施しており、やっちゃいけないわけではなさそう（日本語では自国語合わせには出来ませんが…） 一方で躊躇い要素もあります。 【躊躇理由】 * 現在の自動採番キー自体も既にかなり長く実装されてきていて、ユーザーにとっては急な仕様変更となり一時的に操作上の支障を生じうる + ただそもそも自動採番に否定的な考えなのはこのためなので、いつまでも放置していいとは思えない * 本来は翻訳ではなく原文改訂や、場合によっては開発対応が望ましい案件かも知れない * 指定キーは基本的にはen-USに合わせるのが良いと考えているが、そのen-US環境でも自動採番の割り当てキーの挙動に疑問があり、無条件に合わせてよいのかどうか悩ましい + 先頭文字が割り当てれれているもの（先頭文字をアクセラレーターキーとする場合でも原文に「~」が設定されている項目もある） + 妥当な途中位置の文字が割り当てられているもの + 不自然な途中位置の文字が割り当てられているもの + アクセラレーターキーが割り当てられていないもの なお自動採番の処理アルゴリズムについてはソースコードの次の箇所あたりが該当するとhimajinさんに教えていただきました。が、私の方ではまともには追えてません（苦笑）。 https://opengrok.libreoffice.org/xref/core/vcl/source/window/menu.cxx?r=5b01ad53#239 https://opengrok.libreoffice.org/xref/core/vcl/source/window/mnemonic.cxx?r=b08a2b29 CJK環境とそれ以外で処理は全く変えているようです。この処理が今後も生き続けるとなるとなおのこと、CJKでの自動採番は今後も難儀を増やし続けることになるのではないかと感じるところです。 原文でのキー指定の徹底を希望したいところですが…。 あるいはCJK自動採番時の原文使用（引数さえ渡せれば出来なくはなさそう？）。 今回は試金石として（パワー不足もあってw）Drawの「ページ」と「シェイプ」メニューのみについて、39件提案を上げています(https://t.me/liboja/6736)。 ただし「シェイプ」-「挿入」の下にある孫メニュー（「線と矢印」などのもう一つ下）については、今回一切の提案を上げていません。数が多すぎて…というのもあるんですが、en-USのキー割り当てが上位メニュー以上に支離滅裂で、下手に合わせて割り当てるよりは自動割り当ての方がまだしもマシなのではと考えた次第です。 指定キーは7.2a0のen-USに合わせて選定したつもりです。 正直手に負えない感ありますが…、ひとまず問題提起として翻訳提案させていただいてます。コミュニティーで揉んでいただけると幸いです。よろしくお願いします。 --- 岩橋 伴典 CALL SIGN: JO3EMC E-mail: jo3emc@jarl.com -- Unsubscribe instructions: E-mail to discuss+unsubscribe@ja.libreoffice.org Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/ja/discuss/ Privacy Policy: https://www.documentfoundation.org/privacy