Sublime Forum

Where does ST3 look for locale settings?

#1

I am new to ST3 and installed it on a Linux Mint 19.2 system. At startup, I get the message:

"Package Control

Your system’s locale is set to a value that can not handle non-ASCII characters. Package Control can not work properly unless this is fixed.
…
As a temporary work-around, you can launch Sublime Text from the terminal with:

LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 sublime_text"

  1. “locale -a” output replies with list which includes “en_US.utf8”
  2. /etc/locale.conf has been edited to include “LANG=en_US.UTF-8”
  3. I have written a bash script which incorporates the work-around, but I would like a cleaner solution.

Any suggestions would be appreciated.

Thanks.

0 Likes
#2

What does running locale on a terminal yield?

0 Likes
#3

Here’s the complete list:

LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE=“en_US.UTF-8”
LC_NUMERIC=“en_US.UTF-8”
LC_TIME=“en_US.UTF-8”
LC_COLLATE=“en_US.UTF-8”
LC_MONETARY=“en_US.UTF-8”
LC_MESSAGES=“en_US.UTF-8”
LC_PAPER=“en_US.UTF-8”
LC_NAME=“en_US.UTF-8”
LC_ADDRESS=“en_US.UTF-8”
LC_TELEPHONE=“en_US.UTF-8”
LC_MEASUREMENT=“en_US.UTF-8”
LC_IDENTIFICATION=“en_US.UTF-8”
LC_ALL=

Thanks

0 Likes
#4

Did you relogin after doing this? It may be that whatever process/terminal you were using to run ST hasn’t picked up the updated locale config yet. Logging out and in or alternatively rebooting should make it work.

0 Likes
#5

Yes, I did re-login as well as reboot just in case. Added and removed “LANG=…” to /etc/locale.conf. Also tried adding it to .bashrc as an EXPORT.

localectl -a (list available locales) returns:

C
C.UTF-8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IL
en_IL.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
POSIX

However, “localectl status” returns:

System Locale: n/a (This makes me suspicious!)
VC Keymap: n/a
X11 Layout: us
X11 Model: pc105

As a swag, it looks like ST3 does not look at /etc/locale.conf as I’ve read in a number of forums…and that’s why I’m asking.

0 Likes
#6

Resolved: (sometimes it’s just a matter of seeing what you’re looking at!)

Ran:
“sudo localectl set-locale LANG=en_US.UTF-8”

Problem appears resolved.

1 Like
#7

Spoke too soon. This worked when I logged in from a Windows Remote Desktop session, but not when I log in from a Cygwin X11 session or directly from the system console.

It appears that ST3 is checking something for locale info and I cannot find what would be different.

"localectl status: returns the same results as above on all logins.

Still looking.

0 Likes
#8

Sublime Text itself isn’t directly “checking” anything. As far as I understand how Python bootstraps, the Python 3.3 environment embedded in plugin_host reads the environmental variables to initialize the decoding of bytes to unicode. For some reason it is not getting a value that works for non-ASCII values.

Are you launching Sublime Text via the command line normally, or via a .desktop file?

0 Likes
#9

Confusing results:
A) System console:
1) Launch from command line (LANG/LC_CTYPE set in .bashrc): works OK
2) Launch from .desktop: fails

B) Cygwin X11 session logged in with same user ID:
1) Launch form command line: works
2) Launch from .desktop: fails

C) Windows Remote Desktop session via xrdp
1) Launch from command line: works
2) Launch from .desktop: WORKS!

D) If “export LANG=en…” in either /home/user/.bashrc or in /etc/bash.bashrc, command line works. If it is not one or the other, fails.

E) New user: I set up a new user and both command line and .desktop fail. “localectl status” show LANG is set to en_US…

Tests were run after changes made, logout, re-login.

Python2 version is 2.7.15
Python3 version is 3.6.9

Command links to python 2.7.15 (Could this be the problem?)

Running Linux Mint 19.2 XFCE

0 Likes
#10

I have python 2.7 and python 3.6 installed. It appears that sublime downloads python 3.3 but does not install it.

Running python command gives some interesting results:

A) Invoke “python” from command line (runs version 2.7.15)
>>> import locale;
>>> locale.getdefaultlocale();
(‘en_US’, ‘UTF-8’)

locale.getlocale();
(None, None)

B) Invoke python3.6
>>> locale.getdefaultlocale();
(‘en_US’, ‘UTF-8’)

locale.getlocale();
(‘en_US’, ‘UTF-8’)

Different results for locale.getlocale() between version 2.7 and 3.6!

Questions:

  1. Is it possible that sublime is using “python” which invokes python 2.7 on my system when it is or should be looking for python 3.x?

  2. Should sublime be calling locale.getdefaultlocale()?

  3. Why would there be a difference between an RDP session and a X11 session. (I can understand why there is a difference between command line and .desktop invocation when LANG is set in .bashrc.)

0 Likes
#11

It seems the issue is that your app launcher that uses the .desktop files is not setting the locale properly. I’d recommend modifying the .desktop file to explicitly set the locale.

Sublime Text 3 does not use Python on your system at all. You don’t need Python installed and it won’t use it even if you have it. The executable plugin_host in the Sublime Text dir has Python 3.3 embedded inside of it. The Python 3.3 stdlib is contained in a zip file in the Sublime Text dir.

The rest of the tests and output you included aren’t really relevant since Sublime Text doesn’t use those versions.

0 Likes
#12

Thanks,

You just confirmed some of the conclusions I had arrived at.

I wrote a short bash script that set LANG then invoked sublime and that, of course, worked.

Now, I am tracking the difference between an xRDP session and a X11 session.

I guess my OCD has kicked in on this issue.

0 Likes
#13

OKAY!! I think I got it!

Remote Desktop exports LANG at startup into the xrdp session manager.

Xfce4 start session does not!

To fix: Edit “/usr/bin/startxfce4” and add: “export LANG=$LANG;” before “/usr/bin/xfce4-session”

I’m going to mark this solved until I find otherwise!

3 Likes
#14

This is interesting because I’m also using XFCE (not on Mint though, on Slackware); I don’t have that in my startxfce either, but it still works both ways for me. On Slackware /etc/profile.d/lang.sh sets LANG to the appropriate locale as part of the global environment.

As such I don’t think startxfce needs to export it specifically (in my case) because it’s just always there as long as everything runs as you or is started by something that was run by you, since the environment is inherited by child processes.

It’s easy to get caught out by changes to these things seemingly having no effect, like modifying the file and not quitting and restarting X, or quitting and restarting but not logging out in between; basically anything that stops the inherited process environment from seeing the changes.

I don’t think that’s the case here though since you mentioned you did that. It’s interesting that something was injecting things into the environment that fixed it in some cases though; that’s the sort of vector for things like this that are not immediately obvious.

1 Like
#15

It only fails if starting from the xfce .desktop (launcher). It appears that the .bashrc is not run at login, but that is where the startxfce4 was getting run.

I won’t pretend to be an expert on the sequence xfce4 uses in bringing up a desktop, but it was when I started checking where other environment variables were set in xrdp and xfce that I noticed that xrdp exported all the env output and startxfce4 only exported selected variables.

I do not have a /etc/profile.d/lang.sh

0 Likes
#16

Ahh interesting; on Slackware the system boots into a console where I log in and then manually run startx when I want to go graphical; so X (and thus XFCE) end up with the global environment.

If you’re running a system where it boots directly into a graphical login prompt, that is a potential situation where logging out and in again may not do what you expect because nothing is restarting to get a new environment (possibly).

In a case like yours I would expect that there would be some system-specific configuration to get the locale set if it’s not going to use the bashrc by default.

0 Likes
#17

Spot on!

The startxfce4 script gets run at startup. It uses “env” to export certain variables such as PATH, DISPLAY, HOME, etc.

0 Likes