30 年にわたって積み重なったキーボードのバグ：「Ś」を入力できない理由とその修復

2015 年 2 月 2 日、マルチン・ウィチャリ氏は Medium Engineering にて発表した技術的な物語です。ポーランド語入力時の不可解なバグに潜む、歴史と技術の奇妙な衝突を解説します。

問題発覚：なぜ「Ś」は入力されないのか

Medium の編集部から以下のような報告がありました。

• 症状: ポーランド語で記事を作成できるが、『Ś』という文字だけはキーを押しても表示されない。
• 発生場所: Mediaum (Medium) 上でのみ発生する現象。
• 奇妙さ: 言語全体に対して特別扱いをしないポリシーがある中で、32 のポーランド文字の内の 1 つだけが例外になるのは偶然ではないはずだ。

実は、このバグは単なる偶然ではなく、4 つの偶発的な要因が数十年（あるいは世紀単位）をかけて集まった結果であり、それをどのように解決したかが今回の物語です。

---

背景事情

この問題を引き起こしたのは、以下の 4 つの要素の相互作用でした。

材料 1：ポーランド語とタイプライターの歴史

• 言語の特徴: スラブ系言語の中でロシア語に次いで使用頻度が高く、英語（ラテン文字体系）を基盤としつつ独自の追加文字を導入。
• 追加文字: 「Q」「V」「X」は不要ですが、9 つの diakritics（アクセント記号付き文字） が頻繁に使われています。
  • 例：

    Ł, Ż

    など。
• タイプライターの進化:
  • アメリカ製キーボードにはないこの 9 文字を扱うため、ポーランド製のタイプライターでは独自の配列を採用。
  • 数字キーと共有するか、独立したキー（

    Ł

    ,

    Ż

    ）を配置するなどの工夫がなされました。
  • ピリオドやコロンなどの記号を手放すことで、新たな文字を受け入れる余地を作りました。

材料 2：共産主義体制下でのパソコン事情

• 当時の状況 (1980 年代):
  • 個人計算機の導入が制限されており、西側からの商用輸入が禁止されていた。
  • 多くの PC はアメリカ製キーボード（英語配列）のまま海外から輸入され、説明書も翻訳されていませんでした。
• 入力手段の悩み:
  • 言語固有の 9 つの diakritics を入力する方法を探す必要がありましたが、物理的なキーボード改修は不可能。
  • 解決策として採用された配列:

    Ctrl

    （現在の Caps Lock 位置）と

    Alt

    を活用する「プログラマー型配列」。
    • 8 つの diakritics はラテン文字に対応する位置に、残り 1 つを近傍に配置。
    • 「タイピスト型」から「プログラマー型」へ移行しましたが、人体工学上は非効率的（左手で Alt を多用するなど）でした。
  • しかし、ハードウェア改造が不要で理解しやすいため、この配列は長期間根付いていました。

材料 3：悪習慣は死ぬまでに強い（保存ダイアログのブロック）

• 自動保存の導入問題:
  • Web ブラウザでは「Command+S」または「Ctrl+S」を押し次第に保存ダイアログが開くのがデフォルト。
  • これにより、不要な HTML 保存オプションや煩わしいアニメーションが表示され、ユーザー体験が阻害されていました。
• Medium の対策:
  • 以前は単純に「Command+S / Ctrl+S」を押した際にブラウザのダイアログを表示せず、内部的に編集内容を保存するように処理していました。
  • 那时的コード例:

    if ((e.metaKey || e.ctrlKey) && e.keyCode === goog.events.KeyCodes.S) {
      this._editors.save();
      e.preventDefault();
    }
    

  • これは「S キーと組み合わせキーで保存し、他の動作を防止する」という意図でしたが、『Ś』を入力するには Alt+S が必要なのに、この処理が干渉しているという矛盾を生みました。

材料 4：Microsoft Windows と Alt キーの衝突

• Windows のショートカット文化:
  • Windows システムではメニュー操作やダイアログへの迅速なアクセスのために

    Alt

    キーが広く使われていました（例：

    Alt+F

    でファイルメニュー）。
  • ポーランド語入力に使われる「左側の Alt キー」と、Windows のショートカット機能が衝突しました。
• 解決策としての「Right Alt (右 Alt)」:
  • 両方の機能を満たすために、「左 Alt」を Windows ショートカットに、「右 Alt」をポーランド語入力に使おうとする案が出ました。
  • しかし、これは指の配置が不自然で人間工学的に悪劣でした。
• Microsoft の内部的なマップ:
  • 単一キーしかない古いモデルでも「右 Alt」機能が必要となったため、Microsoft はシステム上で**「右 Alt = Ctrl + Alt を同時に押す」**としてマッピングするようになりました。
  • これにより、実際のショートカットは

    Ctrl+Alt+S

    という奇妙な組み合わせになってしまいました。

---

衝突：バグの原因が明確になる

上記の経緯を整理すると、バグの正体が見えてきます。

1. 歴史的要因: ポーランド語ユーザーは長年、『Ś』を入力するために**「右 Alt+S」**を使用してきました。
2. システムのマップ: Microsoft の設定により、「右 Alt」は内部的に**「Ctrl+Alt」**と認識されています。
3. 結果としてのショートカット: 実際の入力操作

   右 Alt + S

   は、システム側で**

   Ctrl+Alt+S

   **として解釈されます。
4. Medium のブロック処理: Medium は以前から

   Ctrl+S

   を押した際だけ保存ダイアログを表示しないようにブロックするコードを持っていました。
5. 致命的な衝突:
   • ユーザーは『Ś』を入力しようと

     右 Alt + S

     を押します。
   • 内部ではこれを

     Ctrl+Alt+S

     と解釈。
   • Medium の古いコードが「S キー」と「組み合わせキー（Mac: Meta/Windws, Linux/Win: Ctrl）」があれば保存処理を行うため、この場合も条件に合致しして保存ダイアログを無視する処理が実行され、文字入力自体がブロックされてしまったのです。

---

解決策：コードの修正

原因を理解した上で、パッチ適用は比較的簡単でした。 単純に

Ctrl+S

を無条件でブロックするのではなく、「Alt キーが押されていない場合だけ」をブロックする条件付けを行いました。

修正前のコード（問題がある場合）

// Alt キーの有無を考慮せず、Meta(Ctrl) + S で保存処理を行うと『Ś』入力時に干渉する
if ((e.metaKey || e.ctrlKey) && e.keyCode === goog.events.KeyCodes.S) {
  this._editors.save();
  e.preventDefault();
}

修正後のコード（問題解決）

// Alt キーが押されていない場合のみ、Ctrl+S で保存処理をブロックする
if ((e.metaKey || (e.ctrlKey && !e.altKey)) && e.keyCode === goog.events.KeyCodes.S) {
  this._editors.save();
  e.preventDefault();
}

この修正により、

右 Alt + S

（内部的には

Ctrl+Alt+S

）での文字入力は可能になりつつ、通常の

Ctrl+S

による保存ダイアログ表示は依然として防げるというバランスを取りました。

---

まとめと考察：言語の多様性と標準化

今回の教訓

• このバグは単なるコードミスではなく、ポーランド語ユーザーが数十年かけて身につけた「運動記憶」と、グローバルなソフトウェアの「恣意的な設計判断」が衝突した結果です。
• 開発者は複雑な調査をせずとも、過去の技術的決断と現在のバグレポートを組み合わせて原因と解決策を直感的に把握できました。

より大きな物語へのつながり

• このコードは、アメリカ中心の計算機業界が覇権を握っていることを示しています。
  • 26 つの文字で構成されるシンプルな英語を中心に進化する規範が、多言語環境では不向きになっています。
  • ポーランド語のような言語は、QWERTY ベースのレイアウトのコピーからコピーへと移り変わっただけで生きている状態です。
• 多くの言語が英語ほど幸運ではなく、書き言葉自体が標準語から遠く離れている現実を浮き彫りにしました。

開発者への感謝

この小さな変更は、異なる言語を話す人々が、ソフトウェアをよく使い、英語由来の仮定や判断、例外に直面せずに作業できるようにする一助となります。 これからの開発においても、ユーザーの歴史的文脈と実際の使用法を深く理解し、より包括的な設計ができることを願っています。