モンゴル語辞書プロジェクトの各種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カラムレイアウト、レスポンシブカードデザイン、機能的なサイドバーメニュー、正しい日本語抜粋生成、すべてが統合されている。

言語学サイトのWordPressテーマを開発中、ブロックエディタの「カラム」ブロックが突然機能しなくなった。2カラムレイアウトを設定しても、コンテンツが縦に積み重なってしまう。 調査の結果、functions.phpの誤った設定が原因だと判明した。不要なスタイルを削除しようとして、wp-block-libraryをdequeueしていたのだ。 wp-block-libraryは、WordPressのブロックエディタが生成するすべてのブロックの基本スタイルを含んでいる。これを削除すると、カラムブロックだけでなく、ギャラリー、引用、ボタンなど、すべてのブロックが正しく表示されなくなる。 正しいアプローチは、wp-block-libraryを保持しつつ、テーマでブロックスタイルのサポートを明示的に宣言することだった。 この一行を追加することで、WordPressはテーマがブロックエディタと互換性があることを認識し、適切なスタイルを適用する。 同時に、年表（Chronology）セクションのリファクタリングも行った。複雑なHTMLテーブルを廃止し、新しいショートコードシステム（[chronology_section]）に置き換えた。このショートコードは、functions.phpで定義され、モバイルレスポンシブな年表テーブルを生成する。 モバイルCSS版でも苦労した。年表テーブルが小さな画面で崩れていた。最終的に、完全に書き直したchronology.css（v4）を作成し、flexboxベースのレスポンシブレイアウトを実装した。 現在、言語学サイトのWordPressテーマは、ブロックエディタと完全に互換性がある。カラムブロックは正しく動作し、年表セクションはすべてのデバイスで読みやすく表示される。

言語学ポータルサイトの「モンゴル語学の歴史」年表ページで、21世紀セクションの構造を整理した。当初、テーブルの上部に2行の「概要行」があり、その後に2000年代、2010年代、2020年代の詳細が続いていた。 しかし、この概要行は冗長だった。21世紀が「進行中の過程」であることは、2020年代のセクションを見れば明らかだ。わざわざ冒頭で述べる必要はない。 そこで、2つの概要行を削除し、年代見出し（2000年代、2010年代、2020年代）だけに依存する構造に変更した。これにより、テーブルの構造が明確になり、各年代のセクションが等しく扱われるようになった。 同時に、概念的なスタンスは維持した。21世紀は「完結した歴史的時代」ではなく「進行中のプロセス」だという認識だ。これはコンテンツの書き方（現在形の使用、暫定的な評価など）に反映されている。 視覚的な改善として、年代見出しに軽い背景色を付けることも検討している。ただし、これはデザインの方向性を先に決める必要がある。選択肢は3つだ： この選択は、サイト全体のデザイン言語に影響するため、慎重に決定する必要がある。現時点では、シンプルな構造の整理だけを実施し、視覚的な装飾は保留としている。

辞書サイト（itako-dict）と言語学ポータル（linguistics）で、スマートフォンでの表示が崩れているという報告を受けた。3カラムレイアウト（左サイドバー、メインコンテンツ、右サイドバー）が横並びのままで、メインコンテンツが押し潰されて読めない状態だった。 原因を調査したところ、共有CSSファイル（/shared-assets/css/dict-style.css）にモバイル用のメディアクエリが完全に欠けていることが判明した。デスクトップ版のCSSしか定義されていなかったため、小さな画面でも3カラムレイアウトが維持されていた。 解決策は、適切なメディアクエリを追加することだった。画面幅780px以下の場合、レイアウトをdisplay: flexとflex-direction: columnで縦積みに変更する。さらに、表示順序も調整する必要があった。モバイルでは、メインコンテンツ→左サイドバー→右サイドバーの順が最も読みやすい。 この修正を共有CSSファイルに適用したことで、itako-dictとlinguisticsの両サイトが同時に修正された。これが共有アセットアーキテクチャの利点だ。 さらに、両サイトのfunctions.phpでCSSのバージョン番号を’2.4’から’2.5’に更新した。これにより、ユーザーのブラウザキャッシュが強制的にクリアされ、新しいCSSが確実に読み込まれる。 現在、両サイトはすべてのデバイスサイズで正しく表示される。デスクトップでは3カラムレイアウト、タブレットでは2カラム、スマートフォンでは1カラムと、画面サイズに応じて適切にレイアウトが変化する。モバイルUXが大幅に改善された。