Hi, thanks for letting me know of those issues!
On Wed Apr 20, 2016 at 12:04:37 -0400, Mingye Wang (Arthur2e5) wrote: > Package: minicom > Version: 2.7-1 > > A few months ago I was doing some minicom zh_CN l10n on > TranslationProject.org. Since the work is has been assigned to someone > else, I was not able to submit the done files. Interestingly, the > coordinator of the zh_CN language actually presented me with an extra > reason why they are not accepting strings (even if someone else has done > that years ago) -- translating minicom makes the UI a mess [1]. > [1]: https://groups.google.com/d/topic/i18n-zh/X-FCRHzWuYc/discussion > > multi-column scripts like CJK and emoji takes up multiple terminal > columns for each character. (For the two specifically, well, two cols.) > However, these segments in minicom appears to be ignoring all such > characters: > > config.c: > > static void dologopt(void) > > { > > /* ... */ > > while(1) { > > mc_wlocate(w, mbslen(question) + 5, 5); > > This mc_wlocate call assumes that mbslen(str) is the colomn width of > str. However, due to the reasons mentions above, CJK strings like "要修 > 改哪个选项？" will end up giving a cursor stuck in the middle. > > wcswidth(wchar_t *) may be a better solution, but you may want to add > some comments to ask translations not to use tabs (which screws up > things in the current implementation too.) Unprintable chars (including > ctrl chars like tab and newline) in wcswidth will cause it to return -1. Probably a wrapper for wcswidth() will do here that counts unprintable characters as 1 char/column (and just ignoring the speciality of TAB). > window.c: > > void mc_wputc(WIN *win, wchar_t c) > > { > > /* ... */ > > if (win->cury == win->sy2 - win->y1 + 1) > > The windows x/y knowledge is also crippled here. For single-char width > info, use wcwidth(wchar_t). Like wcswidth, it returns -1 for unprintable > chars. Yes, needs to be fixed. > Note that emoji suport in glibc wcwidth() comes with Unicode 7.0 support > in glibc, which is in glibc 2.22. Some extra even newer emojis require > Unicode 8.0 (glibc 2.23). Ok, good to know, thanks. Adam
