中嶋悟
名前：中嶋 悟（なかじま さとる） ニックネーム：サトルン 年齢：28歳 性別：男性 職業：会社員（IT系メーカー・マーケティング部門） 通勤場所：東京都千代田区・本社オフィス 通勤時間：片道約45分（電車＋徒歩） 居住地：東京都杉並区・阿佐ヶ谷の1LDKマンション 出身地：神奈川県横浜市 身長：175cm 血液型：A型 誕生日：1997年5月12日 趣味：比較記事を書くこと、カメラ散歩、ガジェット収集、カフェ巡り、映画鑑賞（特に洋画）、料理（最近はスパイスカレー作りにハマり中） 性格：分析好き・好奇心旺盛・マイペース・几帳面だけど時々おおざっぱ・物事をとことん調べたくなるタイプ 1日（平日）のタイムスケジュール 6:30 起床。まずはコーヒーを淹れながらニュースとSNSチェック 7:00 朝食（自作のオートミールorトースト）、ブログの下書きや記事ネタ整理 8:00 出勤準備 8:30 電車で通勤（この間にポッドキャストやオーディオブックでインプット） 9:15 出社。午前は資料作成やメール返信 12:00 ランチはオフィス近くの定食屋かカフェ 13:00 午後は会議やマーケティング企画立案、データ分析 18:00 退社 19:00 帰宅途中にスーパー寄って買い物 19:30 夕食＆YouTubeやNetflixでリラックスタイム 21:00 ブログ執筆や写真編集、次の記事の構成作成 23:00 読書（比較記事のネタ探しも兼ねる） 23:45 就寝準備 24:00 就寝
i18nとl10nの違いを知ろう
国際化を考えるとき、ソフトウェア開発者は二つの言葉に出会います。「i18n」と「l10n」です。i18n は internationalization の略で、日本語では「国際化」と呼ばれます。l10n は localization の略で、日本語では「現地化」や「地域最適化」と言われます。
この二つは目的が似ているように見えますが、役割は違います。
i18n は土台づくり、l10n は仕上げの作業のように分けて考えると混乱しにくいです。
まず押さえたいポイントは三つです。第一に「文字コードと言語データの扱い」。第二に「日時・数値・通貨の形式の違い」。第三に「翻訳と文化的適合の関係」。
i18n がアプリ全体の構造を、l10n がその構造の中身を変えるイメージです。
例えば日付の表記が日本と英語圏で異なるように、ソフトウェアは locale に応じて表示を変える必要があります。
次に実務での違いを見てみましょう。
i18n の実務 は設計段階での国際化対応の決定、リソースの分離、テキストの抽出・管理、日付・数値のフォーマット規則の設計などを含みます。
l10n の実務 は実際の翻訳作業、地域の慣習の適用、右から左への言語対応、地域ごとの法令や表示規制の適用です。
わかりやすい具体例と実務ポイント
実例として、アプリの表示言語を変えるとき、i18n では「どの部分を翻訳対象にするのか」「どのフォーマットを使うのか」を設計します。
次に l10n では、英語の文章を日本語へ翻訳する際の語順・敬語の使い方・表現のニュアンスを現地のユーザーに合わせて調整します。
この流れを崩さず実装するには、リソースファイルを適切に分割して管理すること、翻訳の品質を保つワークフローを作ること、そして現地テストを欠かさないことが大切です。
最後に、よくあるミスと対策を挙げておきます。
ミス1：翻訳をハードコードしてしまう。
対策：テキストをリソース化して、言語リソースを分離する。
ミス2：日付や数値のフォーマットを locale で切り替えない。
対策：フォーマットのカレンダー・ロケール規則を統一して管理する。
ミス3：右から左の言語に対応していない。
対策：UI のレイアウトをロケールに合わせて動的に変える。
これらを守ると、海外のユーザーにも違和感の少ないアプリになります。
実務での実例と現場の工夫
現場の実務では、言語ごとに異なる文体の扱い、翻訳の品質管理、テストの方法などが含まれます。
まず、リソースの命名規則を統一します。
国際化対応のディレクトリ構造を決め、翻訳対象テキストを抽出する仕組みを整えます。
次に l10n のフェーズでは、翻訳者チームと開発チームが協力して文体ガイドを作成し、Terminology を統一します。
リアルな現場の例として、ニュースアプリで「Yesterday」を翻訳する場合、日本語では「昨日」と「この前の日付」の区別が重要です。
このような場面で i18n の設計が不十分だと、翻訳が崩れ、表示が乱れることがあります。
だから、設計時に「どのテキストを翻訳対象にするか」「どの言語コードが使われるか」を決めておくことが大切です。
友達とカフェでの雑談風に i18n の深掘りをしてみました。i18n は internationalization の略で、アプリが世界中のユーザーにも使われるように設計する考え方です。つまり“新しい言語を追加しても壊れないようにする土台作り”のようなもの。実務では文字コードや日付の表現、通貨表示のフォーマット、リソースの抽出・管理といった作業が含まれます。たとえば日本語と英語の表示順の違い、長文の翻訳時の句読点の扱い、同じ言葉でも地域によって意味が変わる表現の対応など、ちょっとした差が使い心地を大きく左右します。現場でありがちな失敗は「翻訳をコードの中に直書きしてしまうこと」です。これを避けるには、すべての表示テキストをリソースファイルに集約し、翻訳者と開発者が同じガイドラインで動くことが大切だと語り合いました。
言語の人気記事
