Geographic location (city, country) from the geo APIs is UTF-8, but the client
and several server paths converted or stored it in the system ANSI code page,
turning umlauts ("ö"/"ä") into "?" or GBK mojibake ("B枚blingen"). Keep the
value UTF-8 end to end: the client caches it as UTF-8 and re-queries once after
an upgrade (keyed by __DATE__, the app's version convention), while the server
stores and displays it as UTF-8 in the online list, the activity log, the
client-info export, JSON/email payloads and search.
Also add a confirmation prompt before opening a remote chat from the toolbar,
with German, English and Traditional-Chinese translations.
Co-Authored-By: deepseek-v4-pro
The client reports its own exe path as UTF-8 in RES_FILE_PATH. Two
display sites re-decoded those bytes with the wrong code page and turned
Chinese paths into mojibake on non-Chinese servers:
- The client-list "程序路径" column wrote ProgramPath through the ANSI
SetItemText path, so the UTF-8 bytes were misread as the system ACP.
Decode UTF-8 to wide and write with LVM_SETITEMTEXTW instead (same
pattern as the window/process lists).
- The double-click info popup normalized the client RES_* fields to the
system ACP and rendered strText with CP_ACP -> wide. The app's internal
ANSI convention is fixed GBK/936 (/execution-charset:.936 plus
setlocale(".936")), so on non-Chinese systems the path collapsed to '?'.
Normalize to 936 and decode 936 instead, which also fixes the popup's
GBK labels and username in the same pass.
Co-Authored-By: deepseek-v4-pro
