translations system is disabled: No such file or directory

Daku

Verified User
Joined
Sep 24, 2015
Messages
16
Hello,

I review logs, and see every minute log like that from directadmin process.

2026:04:02-09:53:39: failed to set locale to "en_US.UTF-8", translations system is disabled: No such file or directory

locale:
LANG=C.UTF-8
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=

localectl:
System Locale: LANG=C.UTF-8
VC Keymap: pl
X11 Layout: pl
X11 Model: pc105


Someone meet that error ?
 
Modern libc decided to treat C.UTF-8 locale as a flag that disables the gettext system similar to how C locale used to do. This affects only modern distros like Debian 13 and RHEL 10 (glibc-2.39 or newer) . The reason was to allow users to use UTF-8 but still have translations system disabled.

More details:


To avoid the gettext system (translations for the backend service) to get silently disabled DA tries to set locale to en_US.UTF-8 on startup. If it fails to do it, then this message is printed out. On older systems this message is not really true, having C.UTF-8 locale will not disable the gettext and all translations will work fine.

The easiest way to get rid of this message is just to make sure you have en_US.UTF-8 locale installed.

List of available locales:
Code:
localectl list-locales

If en_US.UTF-8 is in the list there is nothing to do, if DA still shows the error please open a support ticket.

On Debian based systems:
Code:
echo "en_US.UTF-8 UTF-8" >> /etc/locale.gen
locale-gen --keep-existing

On RHEL based systems it always installed with the glibc-langpack-en package. In case you have a very minimal system you can install it with:

Code:
dnf install glibc-langpack-en
 
DA will switch to the user-selected language at runtime (when it receives a request and identifies the user). We need the en_US locale to be available only to make sure gettext-related functions work and we will be able to switch to the correct language at runtime.

The instructions in my previous post do not change the system locale. It installs the en_US locale to be available but does not reconfigure the system to use it. Executing those commands will keep the system using C.UTF-8.

If you change your system locale to anything except C or C.UTF-8, then DirectAdmin service will not need to jump into en_US anymore, because all other locales except C keep the translation system functional.

Changing the default system locale will also get rid of those error messages (as well as stop changing to en_US.UTF-8 at service startup). It is an alternative way of getting rid of those error messages. However, keep in mind that changing the locale system-wide will also affect your CLI command output.
 
Back
Top