Applications requiring UTF-8 fail
Metadata
Current evaluation
UTF-8-dependent packaged apps can fail because host locales are unavailable; no generic fallback is visible, and the open report remains untriaged despite documented workarounds.
Suggested action: needs triage
Reason: The report provides a concrete Click traceback showing that en_US.UTF-8 is inherited but unavailable in the snap, and later comments corroborate the LC_ALL/LANG workaround without maintainer triage. Current code only sets C.UTF-8 for ROS dependency staging and KDE locale generation, so no generic runtime fallback is evident; ownership and desired locale behavior require assessment.
Evaluated by: mr-cal-bot
Impact:
58
Quick Win:
13
Complexity:
60
Confidence:
90
Actionability:
57
Issue body
UTF-8 support in snapcraft is still quite poor. For example, Python applications requiring UTF-8 fail on most systems because the snap only contains `C.UTF-8`, not the locale of the host machine. As a result, python seems to fallback to ASCII, breaking many libraries.
Existing python snaps solve this in a number of ways:
1. A wrapper script that sets LC_ALL to "C.UTF-8": https://github.com/juju/charm-tools/blob/c3cee3672978d19cb66b7a301c0fbae9542eb58d/helpers/snap-wrappers/charm#L8
2. Change the application itself to fallback to "C.UTF-8": https://github.com/snapcore/snapcraft/blob/4042556714400d2156cb89efb86bf294500d1f41/snapcraft/cli/__main__.py#L40
3. Setting LC_ALL to "C.UTF-8" in snapcraft.yaml (either using `environment` or by prefixing the command string): https://github.com/warner/magic-wormhole/blob/13102d3eeded33a4ad749078de9bbca5000ffbe6/snapcraft.yaml#L22
Since so many people have this issue, would it be possible to provide a fix for it in snapcraft?
Below you can find an example for the click library failing because the locale fallsback to ASCII.
```
Traceback (most recent call last):
File "/snap/gh-teacher/x4/bin/gh-tools", line 172, in <module>
cli(obj={}) #pylint: disable=E1123,E1120
File "/snap/gh-teacher/x4/lib/python3.5/site-packages/click/core.py", line 764, in __call__
return self.main(*args, **kwargs)
File "/snap/gh-teacher/x4/lib/python3.5/site-packages/click/core.py", line 696, in main
_verify_python3_env()
File "/snap/gh-teacher/x4/lib/python3.5/site-packages/click/_unicodefun.py", line 124, in _verify_python3_env
' mitigation steps.' + extra
RuntimeError: Click will abort further execution because Python 3 was configured to use ASCII as encoding for the environment. Consult https://click.palletsprojects.com/en/7.x/python3/ for mitigation steps.
This system supports the C.UTF-8 locale which is recommended.
You might be able to resolve your issue by exporting the
following environment variables:
export LC_ALL=C.UTF-8
export LANG=C.UTF-8
Click discovered that you exported a UTF-8 locale
but the locale system could not pick up from it because
it does not exist. The exported locale is "en_US.UTF-8" but it
is not supported
```
Related bug in snapcraft itself: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1576411
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
58
Quick Win:
13
Complexity:
60
Confidence:
90
Actionability:
57
|
needs triage | UTF-8-dependent packaged apps can fail because host locales are unavailable; no generic fallback is visible, and the open report remains untriaged despite documented workarounds. | |
| stealth/space-bunny-alpha |
Impact:
52
Quick Win:
15
Complexity:
55
Confidence:
82
Actionability:
63
|
needs triage | UTF-8-dependent packaged apps can fall back to ASCII when the host locale is unavailable; app-level C.UTF-8 workarounds work, but no maintainer resolution is recorded. | |
| stealth/space-bunny-alpha |
Impact:
60
Quick Win:
20
Complexity:
53
Confidence:
91
Actionability:
70
|
needs triage | Python and other snap-packaged applications can fall back to ASCII when the host locale is absent; a Snapcraft-level UTF-8 fallback has been requested but remains untriaged. | |
| qwen/qwen3.8-27b |
Impact:
65
Quick Win:
29
Staleness:
85
Complexity:
55
Confidence:
55
Support Request:
30
|
needs triage | Python snaps fail when host locale is not available inside the snap, causing UTF-8 fallback to ASCII. Issue requests snapcraft provide a built-in fix (e.g. default LC_ALL=C.UTF-8). Open since 2017, no maintainer response, no labels. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
30
Confidence:
85
Support Request:
70
|
close stale | Reports UTF-8 locale failures in Python snaps due to missing host locales, suggesting snapcraft should fix this by default. Issue is over 7 years old with no maintainer response. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
98
Complexity:
45
Confidence:
90
Support Request:
35
|
close stale | Extremely old report about Python locale failures in snaps due to missing host locale support. No maintainer interaction, multiple established workarounds exist, and the reported environment is obsolete. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
95
Complexity:
65
Confidence:
75
Support Request:
20
|
close stale | Untriaged 2017 issue reporting UTF-8 locale failures in Python snaps. Requests a snapcraft-level fix but has zero maintainer comments and over seven years of inactivity. Locale handling is now a known limitation with established workarounds. |
Update history
| Date | Change |
|---|---|
| created |
Related work
-
Related To:
snapd#1576411
(confidence 98%)
The report explicitly links this Launchpad bug about locale availability in snaps.
Related issues
No related issues found above the similarity threshold.