rtk ls returns "(empty)" with non-English locales (LANG=de_DE.UTF-8, fr_FR.UTF-8)

Summary

rtk ls silently returns "(empty)" on any directory when LANG is set to a non-English UTF-8 locale. Exit code is 0, no error message. The parser appears to be hardcoded to English/C locale output formats.

Environment

• rtk 0.37.2 (installed via Homebrew)
• macOS (Apple Silicon)
• iTerm2 with "Set locale environment variables automatically" enabled (iTerm's default behavior on systems with non-English system language)

Minimal Reproduction

mkdir /tmp/rtk-bugtest
cd /tmp/rtk-bugtest
touch a.txt b.txt c.txt
mkdir src

# Works correctly:
env -i HOME=$HOME PATH=/opt/homebrew/bin:/usr/bin:/bin \
    LANG=en_US.UTF-8 rtk ls /tmp/rtk-bugtest
# Output:
#   src/
#   a.txt  0B
#   b.txt  0B
#   c.txt  0B
#   Summary: 3 files, 1 dirs (3 .txt)

env -i HOME=$HOME PATH=/opt/homebrew/bin:/usr/bin:/bin \
    LANG=C.UTF-8 rtk ls /tmp/rtk-bugtest
# Output: same as above, correct

# Broken:
env -i HOME=$HOME PATH=/opt/homebrew/bin:/usr/bin:/bin \
    LANG=de_DE.UTF-8 rtk ls /tmp/rtk-bugtest
# Output: (empty)
# Exit code: 0

env -i HOME=$HOME PATH=/opt/homebrew/bin:/usr/bin:/bin \
    LANG=fr_FR.UTF-8 rtk ls /tmp/rtk-bugtest
# Output: (empty)
# Exit code: 0

Root Cause Analysis

macOS ls -l produces locale-dependent output:

• LANG=en_US.UTF-8: Apr 23 14:55
• LANG=de_DE.UTF-8: 23 Apr. 14:55 (different order, period after month abbreviation)
• LANG=fr_FR.UTF-8: 23 avril 14:55

File size formatting also differs (e.g. 1.5K vs 1,5K with comma as decimal separator).

rtk's ls output parser appears to only match English-locale formats, resulting in zero parsed entries → (empty) displayed regardless of actual directory contents.

Debug Notes

• Other rtk subcommands (rtk git status, rtk git log, etc.) work correctly under all locales — only rtk ls is affected
• RUST_BACKTRACE=full produces no output (silent failure)
• -vvv flag also produces no debug info
• Exit code is always 0, masking the failure from callers

Impact

Affects all users in non-English locales. On macOS, iTerm2's "Set locale environment variables automatically" (the default) propagates the system language as LANG, so any user with a non-English macOS installation hits this. Estimated significant portion of the user base.

Suggested Fix

Spawn the ls subprocess with a forced C/English locale to get parseable, locale-independent output:

Command::new("ls")
    .env("LC_ALL", "C")
    .args(...)
    .output()

This is the same pattern git, cargo, and most locale-sensitive CLI tools use internally. The user's locale is preserved for their own interactive shell; only the tool's internal ls invocation runs in C.

Workaround

Until fixed, users in non-English locales can either:

1. Change iTerm2 (or their terminal) locale setting to English
2. Wrap rtk in shell config: rtk() { LC_ALL=en_US.UTF-8 command rtk "$@"; }