2025年11月現在、W3Cの最新情報と関連する調査結果によると、ウェブブラウザによるモンゴル文字のレンダリングサポートは進展しているものの、依然として課題が残っており、特に文脈依存の文字整形（コンテクスチュアル・シェイピング）に関しては、フォント内部の技術（GSUBテーブル）に大きく依存している状況である。 垂直方向のレンダリング: ブラウザはモンゴル文字の垂直方向の表示（writing-mode: vertical-lr）を正しく回転させるようになった。これは以前のバージョンのWebKitベースのブラウザでの問題が解決されたことを示す。 文脈依存の文字整形（シェイピング）: W3Cのギャップ分析レポート（2023年6月/7月、および最新の2025年8月のドラフト）は、モンゴル文字のUnicodeエンコーディングモデルの複雑さに起因する、フォントやレンダリングエンジン間の相互運用性の欠如を指摘している。 同じ意味の単語でも、フォントによって正しい表示が異なる場合があり、標準化された方法で表示を保証することは「不可能」とされている。 このため、フォント開発者は依然として多くのフォールバックGSUBパッチや非標準のバリエーションシーケンス定義に頼らざるを得ない状況。 W3Cレポートの見解: ギャップ分析レポートは、ブラウザがモンゴル文字のコンテクスチュアル・ルール（結合、後続文字に応じた字形変化など）を完全に実装しているとは述べていない。むしろ、これらのルールの多くは十分に定義されておらず、結果としてレンダリングが曖昧になると結論付けている。 MVS/FVSの扱い: モンゴル母音分離記号（MVS）や自由異体字セレクター（FVS）の振る舞いは、ブラウザやフォントの実装によって異なり、一貫性がない。これは、ブラウザのテキストエンジンがこれらの特殊な規則を標準化された方法で処理できないため。 全体像: 現状、正しいモンゴル文字の表示は、フォントが非公式な「ハック」を含むかどうかに大きく左右される傾向がある。特定のフォント（例えばMongolian Baiti）で正しく表示されるのは、そのフォントが独自のGSUBルールでブラウザの制限を補っているため。 結論として、2025年現在も、標準的なブラウザのレンダリングパイプラインだけで、すべてのモンゴル文字フォントで一貫した正しいコンテクスチュアル・シェイピングを保証できるわけではない、という状況は変わっていない。

20年越しのデータと向き合う Webサイトの引っ越しを機に、長年蓄積してきたデータを整理している。その中で改めて数えてみたところ、モンゴル語の辞書の書誌データが420冊分もあることがわかった。昔からコツコツと入力してきたものだが、こうして数字にしてみると、自分でも驚く量になっていた。 便利だが限界がある「漢字表記システム」 これまで、辞書を区別するために「モ英(生)2013」のような記号を使ってきた。モンゴル語の辞書には似たような名前のものが多いため、後で整理しやすいように工夫したものだ。 漢字は1文字が1つの概念を表すため、情報を圧縮して表記するには非常に便利だ。しかし、非漢字圏の閲覧者には理解しにくいという問題がある。 ISO言語コードへの移行 そこで、国際標準であるISO言語コードを採用することにした。これにより、誰にでも理解できる形式になる。 具体的な変換例 キリル文字モンゴル語の辞書: 伝統モンゴル文字の辞書: これまで便宜的に「蒙」の字を使用してきたが、ISO表記では以下のようになる: 文字コードの利点 この表記方法には、さらなる工夫がある。文字の順番で、どちらが見出し語でどちらが訳語かが自動的にわかるようになっている: 標準化がもたらすもの この標準化により、データの管理が格段に楽になるだけでなく、国際的な協力や情報共有の可能性も広がる。420冊という膨大な書誌データが、より多くの研究者や学習者にとってアクセスしやすくなることを期待している。

モンゴル語辞書プロジェクトの各種Webページで、デザインの統一性を持たせることにした。その一環として、CSSのみで作成したアート要素(時計、システム手帳、消しゴムなど)を開発した。 CSSアートというと装飾的で無駄なもの、という印象があるかもしれない。しかし、適切に使えば、サイトのアイデンティティを確立する有効な手段になる。画像ファイルと違い、コードで直接記述されているため、ページの読み込みも速い。 今回作成したのは、レトロな雰囲気のオフィス用品をモチーフにしたCSS要素だ。革製のシステム手帳、鉛筆、消しゴム、懐中時計など。これらはすべてCSS変数を使って統一的に管理されており、色やサイズの調整が容易だ。 同時に、プロジェクトの各種ツール(ダッシュボード、伝統モンゴル文字ビューア、データ処理ツールなど)のUIデザインも統一した。色彩スキーム(ブラウン系のグラデーション)、スペーシングシステム、カードの影、ボタンのホバー効果など、共通のデザインパターンを確立した。 特に重要だったのは、レスポンシブデザインへの対応だ。モバイル環境ではCSSアートは非表示にし、実用的な情報のみを表示するようにした。画面幅768px以下でメディアクエリが発動する設定だ。 WordPressの複数のテーマ(ブログ、辞書DB、言語学ポータル、小説翻訳サイトなど)に対して、この統一されたデザインシステムを適用することができた。共有アセットフォルダを活用することで、一箇所の変更が全サイトに反映される仕組みだ。 デザインの統一は、単に見た目を良くするだけでなく、ユーザーの認知負荷を減らし、プロジェクト全体の一貫性を高める効果がある。今後も、この方向性を維持していく予定だ。

最近、モンゴル語辞書プロジェクトの作業効率化のため、複数のAIを活用した自動化システムを構築している。具体的には、Claude、Gemini、ChatGPTなどの異なるAIがそれぞれ専門分野を担当する形だ。 Claudeはクロスプラットフォームのコーディネーターとして、GeminiはGoogle Apps Scriptの自動化を、ChatGPTは歴史言語学の検証を担当している。各AIが作成したコードやデータは、Google DriveとGitHubを経由して同期される仕組みになっている。 当初は単純な作業の自動化を考えていたが、実際に運用してみると、AIごとに得意分野が異なることがわかってきた。例えばGeminiはGoogleのエコシステムとの連携が得意で、ClaudeはGitHub操作やマークダウン処理が得意だ。 ただし、課題もある。AIが生成したコードをそのまま使うと、時々予期しないエラーが発生する。特にGoogle Apps Scriptの権限設定周りは注意が必要だ。結局、人間が最終チェックを行う体制は欠かせない。 今後は、この複数AI協働システムをさらに洗練させ、辞書データの検証作業などにも応用していく予定だ。詳細はまた後ほど報告することにしよう。

辞書DBサイト（itako999.com/dict-db/）をBloggerからWordPressに移行する際、420件以上の記事データを処理する必要があった。単純な移行だけでなく、メタデータの抽出と修復も必要だった。 第一段階は、BloggerのXMLエクスポートからWordPressへの投稿変換だった。migrate-posts.phpスクリプトを開発し、各記事を「Dictionary」という専用投稿タイプに変換した。同時に、日本語のカテゴリスラッグによる404エラーも修正した。 第二段階が最も困難だった。Bloggerの記事本文には、構造化されていない形で著者名、出版年、言語情報が含まれていた。これらを抽出し、WordPressのカスタムフィールドに保存する必要があった。 repair-metadata.php（v1.2）を開発し、「ファジースキャン」を実装した。このスクリプトは記事本文を解析し、以下の情報を抽出する： 正規表現だけでは不十分で、文脈を考慮した解析が必要だった。例えば、「編著者：山田太郎」という行があれば著者フィールドに保存するが、単に本文中に「山田太郎」と出てきても、それは著者ではないかもしれない。 第三段階は、テンプレートファイル（content-dictionary.php）の修正だった。当初、モックデータがハードコードされていたが、これを実際のカスタムフィールドから読み取るように変更した。PHPの変数スコープの問題（global $postの使用）も解決する必要があった。 興味深い発見は、一部の記事で書籍タイトルと著者名が逆になっていたことだ。タイトルフィールドに著者名が入り、著者フィールドに書籍名が入っている。これは手動で修正する必要がある。 現在、Dict-DBサイトは完全に機能している。420件以上の辞書記録が正しく表示され、著者名、出版年、言語でフィルタリングできる。クライアントサイドJavaScriptによるフィルタリングを実装したため、ページのリロードなしで即座に結果が更新される。

ᠣᠯᠠᠨ᠎ᠠ ᠡᠷᠭᠦᠭᠳᠡᠭᠰᠡᠨ ᠤ ᠳᠦᠳᠦᠭᠡᠷ ᠣᠨ ᠤ ᠵᠤᠨ ᠤ ᠡᠭᠢᠨ ᠰᠠᠷ᠎ᠠ ᠶᠢᠨ ᠨᠢᠭᠡᠨ ᠡᠳᠤᠷ ᠶᠡᠭᠡ ᠳᠠᠮᠢᠷ ᠤᠨ ᠬᠣᠢ᠌ᠭᠤᠷ ᠭᠠᠷᠤᠠᠠᠰᠠᠨ ᠵᠠᠮ ᠢᠶᠠᠷ ᠭᠤᠴᠢ ᠣᠷᠴᠢᠮ ᠨᠠᠰᠤᠨ ᠤ ᠬᠠᠷ᠎ᠠ ᠭᠦᠮᠤᠨ᠂ ᠨᠠᠯᠢᠶᠠᠤᠨ ᠠᠴᠢᠶ᠎ᠠ ᠲᠡᠶ ᠮᠤᠷᠢᠨ ᠳᠡᠷᠭᠡ ᠭᠦᠳᠦᠯᠦᠭᠡᠳ ᠶᠠᠪᠣᠵᠤ ᠪᠠᠢ᠌ᠪᠠ᠃ ᠨᠠᠷᠠ ᠰᠠᠯᠭᠢᠨ ᠳᠤ ᠭᠠᠩᠳᠠᠵᠤ᠂ ᠭᠬᠢᠷ ᠭᠦᠯᠦᠰᠤᠨ ᠳᠤ ᠨᠠᠪᠳᠠᠷᠠᠵᠤ ᠣᠷᠠᠠᠠᠳᠠᠠᠠᠰᠠᠨ ᠳᠠᠪᠠᠯ ᠢᠶᠠᠨ ᠶ‍ᠢᠰᠤᠨ ᠥᠩᠭᠡ ᠶᠢᠨ ᠶᠠᠭᠤᠮ᠎ᠠ ᠪᠠᠷ ᠨᠥᠭᠦᠭᠰᠡᠨ ᠪᠣᠯᠠᠠᠤᠷ ᠶᠠᠮᠠᠷ ᠡᠳ᠋ ᠢᠶᠠᠷ ᠭᠢᠭᠰᠡᠨ ᠨᠢ ᠮᠡᠳᠡᠭᠳᠡᠭᠦ ᠠᠷᠭ᠎ᠠ ᠦᠭᠡᠶ ᠠᠵᠢ᠃ ᠬᠠᠩᠠᠠᠠᠭᠠᠷ ᠳᠦᠷᠪᠠᠯᠵᠢᠨ ᠮᠦᠷᠤᠨ ᠳᠡᠭᠡᠨ ᠣᠳᠤᠭ᠎ᠠ ᠪᠣᠯᠤᠠᠠᠰᠠᠨ ᠴᠠᠭᠢᠭᠤᠷ ᠫᠣᠤ ᠭᠦᠡᠳᠡᠯᠡᠨ ᠡᠭᠦᠷᠴᠤ᠂ […]

2009年に初めて伝統モンゴル文字のブログを作成したとき、IEでしか表示できず、他の文字との混在表示も困難だった。あれから15年以上が経過し、状況は大きく変わった。 現在、Unicode対応が進み、Noto Sans Mongolianなどのフォントを使えば、主要なブラウザで伝統モンゴル文字を表示できるようになった。しかし、新たな課題も見えてきた。 最大の問題は、縦書きレイアウトの実装だ。CSSのwriting-modeやflexboxを使っても、期待通りに表示されないことが多い。特に、伝統モンゴル文字の「左から右への改行」を実現するのは難しい。ブラウザが想定しているのは主に東アジアの縦書き(右から左改行)だからだ。 試行錯誤の結果、white-space: nowrapを使った親要素と、inline-blockの子要素を組み合わせる方法が最も安定していることがわかった。FlexboxやCSS Grid、CSS Columnsといった新しいレイアウト技術は、伝統モンゴル文字の表示には必ずしも適していない。 また、MVS(Mongolian Variation Selector)やFVS(Free Variation Selector)といった制御文字を正しく処理できるフォントの選択も重要だ。間違ったフォントを使うと、格助詞などが正しく表示されない。 WordPressテーマの開発では、これらの知見を活かして、日本語・キリル文字モンゴル語・伝統モンゴル文字の3つの言語モードに対応したシステムを構築できた。ただし、モバイル環境での表示最適化など、まだ改善の余地はある。 技術は進化したが、伝統モンゴル文字のWeb表示は依然として一筋縄ではいかない。今後も新しい解決策を模索していく必要がありそうだ。

ブログの伝統モンゴル文字投稿で、長年にわたって悩まされてきたレイアウトバグをついに解決した。縦書きのモンゴル文字が、画面を横切る「水平リボン」のように表示されてしまう問題だ。 原因は、blog-theme.jsが自動的に適用するdisplay: flexと、blog-theme.cssの縦書きレイアウトルールの衝突だった。JavaScriptが言語モードを検出し、適切なクラスを追加する前に、flexboxレイアウトが適用されてしまっていた。 解決策は二段階だった。第一に、blog-theme.jsの実行タイミングを修正した。スクリプト全体をDOMContentLoadedイベントリスナーで囲むことで、HTMLが完全に読み込まれてから実行されるようにした。 第二に、CSSのレイアウト戦略を変更した。Flexboxを諦め、white-space: nowrapを使った親要素と、inline-blockの縦書き子要素を組み合わせる方式に変更した。 この方法が伝統モンゴル文字に適している理由は、ブラウザが想定している東アジアの縦書き（右から左への改行）と、モンゴル文字の縦書き（左から右への改行）が逆だからだ。FlexboxやCSS Multi-columnといった最新のレイアウト技術は、CJK（中国語・日本語・韓国語）の縦書きを前提としており、モンゴル文字には適さない。 さらに、言語切り替えスイッチャーにも改良を加えた。mn-trad（伝統モンゴル文字）投稿では、スイッチャーを「ロック」し、他の言語に切り替えられないようにした。これはdata-is-vertical=”true”属性とJavaScriptのチェックで実装した。 この知見を「📙 伝統モンゴル文字Webレイアウト作成マニュアル」として文書化した。15年間の試行錯誤の結果が、再現可能な手法として確立された。

ブログの伝統モンゴル文字投稿で、格助詞などの一部の文字が正しく表示されないという報告を受けた。調査の結果、ブラウザがデフォルトでMongolian Baitiフォントを使用していることが判明した。 問題は、blog-theme.cssの@font-face規則にあった。フォントファイル名が間違っていた。 実際にサーバーに保存されているファイル名は、はるかに長い： この不一致により、ブラウザはカスタムフォントの読み込みに失敗し、システムのフォールバックフォント（Mongolian Baiti）を使用していた。 Mongolian Baitiフォントの問題は、MVS（Mongolian Variation Selector）とFVS（Free Variation Selector）の処理が不完全なことだ。これらの制御文字は、同じ基本文字の異なる形態を選択するために使用される。例えば、格助詞の形態は、先行する母音によって変化する。 解決策は簡単だった。@font-faceのファイルパスを正しい長いファイル名に修正する。 さらに、functions.phpでCSSのバージョン番号を更新（2.14→2.15）し、ブラウザキャッシュを強制的にクリアした。 現在、伝統モンゴル文字は正しく表示される。格助詞、母音の変異形、すべてのMVS/FVS制御文字が、Noto Sans Mongolianフォントで適切にレンダリングされる。フォントファイル名の管理は、多言語サイトでは特に注意が必要だということを学んだ。

言語学ポータルサイトのために、既存の2つのテーマの長所を組み合わせた新しいWordPressテーマを開発した。anagura-linguisticsの3カラムレイアウトと、anagura-portalのモダンなカードデザインを統合した。 開発過程では、いくつかの致命的なエラーに遭遇した。最初の問題は、functions.phpの構文エラーだった。コメントアウトされていないremove_action呼び出しがあり、これがテーマのアクティベーションを阻止していた。PHPはコンパイル言語ではないため、このようなエラーは実行時にしか検出されない。 次に、新しいportal-theme.cssに3カラムグリッドのCSS（.dict-page-grid）が欠けていることが判明した。これにより、サイドバーが正しく配置されず、すべてのコンテンツが縦に積み重なってしまった。元のanagura-linguisticsからCSSをコピーして解決した。 日本語の抜粋生成も問題だった。WordPressのデフォルト関数wp_trim_words()は単語数でカウントするため、日本語では正しく動作しない。新しい関数anagura_get_char_excerpt()を作成し、mb_substr()を使って文字数ベースで抜粋を生成するようにした。 サイドバーのドロップダウンメニューも機能していなかった。これには3つの修正が必要だった： 最も厄介だったのは、CSSに残っていた生のHTMLエンティティ（›）だった。これがコンパイルされずにそのまま表示され、矢印の代わりに文字列が表示されていた。正しいUnicode文字（\203A）に置き換えることで解決した。 現在、新しい言語学ポータルテーマは完全に機能している。3カラムレイアウト、レスポンシブカードデザイン、機能的なサイドバーメニュー、正しい日本語抜粋生成、すべてが統合されている。