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.
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.
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).
--
Regards,
Arthur2e5
signature.asc
Description: OpenPGP digital signature
