When the "extract" button is clicked in the File Manager (eg: on a zip file), the $LANG value set in the environment does affect how the data is output. For security reasons, and call to any embedded script, DA first clears the environment to ensure nothing malicious was set. However, the call to zip/unzip (for example) does use the $LANG env variable to determine the encoding of the filenames shown, when displaying files. Also, it only applies to the CMD_FILE_MANAGER/CMD_API_FILE_MANAGEr, due to the skin file pre-processing, in advance of the chroot (which doesn't actually happen in this case, but it's pre-processed solely on the filename) As a result, even if the LANG was set correctly, if your skin makes an embedded script call in CMD_FILE_MANAGER, then result will be an empty environment, so the call later on to unzip would mean LANG is not set.. If you needed special encoding, the filename would end up showing in the ugly unicode format, eg: file-#U00cc#U0160n-name.txt Note, the extraction would still work correctly, assuming you use the directadmin.conf option: extra_unzip_option=-O cp396 ---- FIX To resolve this, prior to the zip/unzip/tar calls in CMD_FILE_MANAGER, DA checks for the existence of the LANG env variable. If it's unset, DA will set it to en_US.UTF-8. It's more desirable to use the skin's encoding name, but as it's either iso-8859-1 or UTF-8 for example, these are not valid LANG variable names. Since the number of affected people are quite low, this should be fine.