Ubuntu 18.04 Server / システムの言語を変更する方法

Ubuntu 18.04 Serverの既定の言語は、ロケールと翻訳パッケージを準備し、update-localeで設定してから再ログインすると変更できます。本記事では韓国語のko_KR.UTF-8を例に、設定ファイルの値と現在のログインセッションに適用された値を分けて確認します。

変更前の確認とバックアップ

ロケール(locale)は、プログラムが使用する言語、文字エンコーディング、日付・数値の表記や並べ替え規則などを定める設定です。対象はUbuntu 18.04 Serverの端末環境です。デスクトップの入力メソッドやキーボード配列は別の設定になります。

Ubuntu 18.04 LTSの標準セキュリティ保守は2023年5月に終了しました。既存サーバーを管理する場合は、言語設定とは別に、Ubuntu Proの拡張セキュリティ保守の適用状況やOSのアップグレード計画を確認してください。対応範囲はUbuntu公式のリリースサイクルで確認できます。

sudo権限のあるアカウントで接続し、次のコマンドをそれぞれ実行します。localeは現在のセッションの設定、locale -aは利用可能なロケール、最後のコマンドはシステムの既定設定ファイルを表示します。

locale
locale -a
cat /etc/default/locale

現在のセッションにLANG=en_US.UTF-8と表示されれば、既定のロケールは米国英語です。ただし、次の変数に値があれば、一部または全体の設定が上書きされるため、併せて確認してください。

変数 役割と確認事項
LANG 個別の項目が指定されていない場合に使われる既定のロケールです。
LC_MESSAGESなどのLC_* メッセージ・日時・数値などの特定の項目を設定し、その項目ではLANGより優先されます。
LC_ALL すべてのロケール項目を一括して上書きします。通常の永続的な既定値にするより、コマンド実行時の一時的な指定に適しています。
LANGUAGE GNU gettextを使用するプログラムの翻訳メッセージの優先順位を指定します。日付・数値の設定全体を変える変数ではありません。メッセージの言語が想定と異なる場合に確認します。

変数の役割と優先順位、LANGUAGEによるメッセージ翻訳の指定はUbuntu 18.04のlocale(7)マニュアルで確認できます。韓国語訳を持たないプログラムは、韓国語ロケールでも英語のメッセージを表示することがあります。

変更前に既定設定ファイルをバックアップします。次のバックアップ名がすでに存在する場合は、以前のバックアップを上書きせず別の名前を使ってください。復元時も実際に保存したファイル名を指定します。

sudo cp -a /etc/default/locale /etc/default/locale.backup

韓国語ロケールと翻訳パッケージの準備

ロケールデータとプログラムの翻訳メッセージは役割が異なります。設定ファイルにロケール名を書くだけでは、必要なデータやすべてのプログラムの翻訳はインストールされません。まずパッケージ一覧を更新し、ロケールツールと韓国語翻訳パッケージをインストールします。

sudo apt-get update
sudo apt-get install locales language-pack-ko
sudo locale-gen ko_KR.UTF-8
locale -a

各コマンドがエラーなく終了したことを確認してから次へ進みます。最後の一覧にko_KR.utf8があれば、韓国語UTF-8ロケールを使用できます。一覧の.utf8と設定例の.UTF-8では表記が異なる場合があります。locale-genはデータを生成するコマンドであり、システムの既定言語の選択は別途必要です。詳しくはUbuntu 18.04のlocale-genマニュアルを参照してください。

パッケージが見つからない場合やダウンロードに失敗する場合は、先にapt-get updateのエラー、リポジトリ設定、ネットワークを確認してください。インストールに失敗した状態でロケール名だけを指定すると、後続のコマンドでロケール警告が出ることがあります。

システムの既定言語を変更する

言語だけでなく、日付・数値の表記などにも韓国語ロケールを既定として使う場合は、次のように設定します。

sudo update-locale --reset LANG=ko_KR.UTF-8
cat /etc/default/locale

--resetは/etc/default/localeから、コマンドに指定していない変数を削除します。このファイル内の既存のLANGUAGEや個別のLC_*が韓国語の既定値を上書きしないようにするためです。一部の項目に別の地域設定を意図的に使っている場合は、このオプションをそのまま使わず、必要な設定を残して変更する変数だけを指定してください。

設定ファイルには次の項目が必要です。自動生成されたコメントが併記されていても問題ありません。

LANG=ko_KR.UTF-8

update-localeは値を検査して既定設定ファイルを変更しますが、すでに動作しているシェルの環境変数までは変更しません。この動作と--resetの意味はUbuntu 18.04のupdate-localeマニュアルで説明されています。

再ログインして適用を確認する

SSHで接続している場合は切断し、新しいセッションで接続します。通常、サーバー全体の再起動は不要ですが、既存のセッションや実行中のプログラムは以前の環境を使い続ける場合があります。tmuxやscreenへの再接続だけで新しいログイン環境が適用されたと判断しないでください。システムサービスでは、サービス固有の環境設定も確認します。

新しいセッションで次のコマンドを実行します。

locale
locale charmap

LANG=ko_KR.UTF-8と表示され、上書きされていない項目が韓国語ロケールを参照し、文字エンコーディングがUTF-8なら、基本的な適用を確認できます。LC_ALL=のような空の値はエラーではなく、一括上書きをしていない状態です。localeコマンドのマニュアルを参考に実際の環境を確認してください。

同じ日付を2つのロケールで出力すると、表記の違いを比較できます。次の例は各コマンドに対してだけ一時的にロケールを指定するため、既定設定ファイルは変更しません。

LC_ALL=C date -d '2026-01-02' '+%A %B'
LC_ALL=ko_KR.UTF-8 date -d '2026-01-02' '+%A %B'

最初のコマンドはFriday Januaryという英語表記、2つ目はインストールされた韓国語ロケールの曜日名・月名で表示されるはずです。日付の表記言語とタイムゾーンは別の設定です。時刻自体がずれる場合は、Ubuntu 18.04 Serverのタイムゾーン設定方法を確認してください。

設定が反映されない場合の確認箇所

  • ロケール警告が出る場合:設定したロケールがlocale -aにあるか確認します。なければパッケージのインストールとロケール生成から見直してください。ファイルに文字列を追加するだけでは不足しているデータは生成されません。
  • ファイルは韓国語なのにセッションは別の言語の場合:localeでLC_ALL、個別のLC_*、LANGUAGEを確認します。~/.profile、~/.bashrc、/etc/environmentなどにも別の指定がないか調べ、必要な箇所だけを修正して再ログインします。
  • SSHで接続した場合だけ言語が変わる場合:クライアントのSendEnvとサーバーのAcceptEnvによりLANGやLC_*が送信されることがあります。クライアント側のロケールとサーバーで生成済みのロケールを併せて確認してください。OpenSSHクライアント設定とOpenSSHサーバー設定に動作の説明があります。言語の不一致を直すために、接続設定をむやみに変更したりSSHを再起動したりする必要はありません。
  • 一部のメッセージだけ英語の場合:そのプログラムに韓国語訳があるか、LANGUAGEに別の指定がないか確認します。1つのメッセージが英語というだけでロケール全体の適用失敗とは判断できません。
  • 韓国語が四角や文字化けで表示される場合:SSH端末のUTF-8設定と韓国語対応フォントを確認します。サーバーのロケール変更だけでは、クライアントにフォントや韓国語入力メソッドはインストールされません。

元の設定に戻す、または英語に変更する

変更前の状態に戻すには、最初に作ったバックアップを復元して再ログインします。バックアップに保存されていた個別の地域設定も復元されます。

sudo cp -a /etc/default/locale.backup /etc/default/locale
cat /etc/default/locale

以前の状態を復元するのではなく、米国英語UTF-8を新しい既定値にする場合は、そのロケールを生成してから設定します。次のコマンドも既定設定ファイル内の個別のロケール指定を初期化するため、必要な例外がある場合は先に確認してください。

sudo locale-gen en_US.UTF-8
sudo update-locale --reset LANG=en_US.UTF-8

再ログイン後、localeとlocale charmapで確認します。復元後もSSH接続時だけ異なる値になる場合は、バックアップを繰り返し上書きするより、ユーザーの環境変数とSSHの転送設定を見直してください。