<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 11:15 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/9/20 7:19 PM, enh via Toybox wrote:<br>
> don't apps need libc localization? not really. the POSIX localization<br>
> functionality is so anaemic that it's really not useful even for "major<br>
> minority" languages.<br>
<br>
I try to have strerror() display the error codes (but still think it's a missed<br>
opportunity that the "C" locale doesn't output EPERM and friends as the actual<br>
strings), and keep my error message vocabulary small and simple. I also try to<br>
preserve and display utf8 input for usernames and filenames and such.<br></blockquote><div><br></div><div>glibc 2.32 actually added new functions for 9 -> "KILL" and 1 -> "EINVAL". i plan on adding those to bionic too, if only so i can add the moreutils "errno" to toybox, which i've found useful at times. (one of these days i'll write a static analyzer to catch people adding new %d errno printfs to the code base. do they not know about strerror()? do they not know that errno values aren't constant across architectures?)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Beyond that, I've stayed away from internationalization up until now, and if<br>
your response is "kill it with fire" I can revert it.<br></blockquote><div><br></div><div>that would be my choice, certainly.</div><div><br></div><div>if you weren't already convinced by my examples, a couple more common ones: when you add i18n to _output_ people (not unreasonably) expect it for _input_ too, which is a nightmare you don't want to get into. also the answer to "will the kernel ever localize the content of files in /proc?" means we're not doing our actual intended users (human or machine) any favors here. it's easier to learn when things are consistently wrong (like me dealing with the victorian^WUS use of Fahrenheit and the twelve-hour clock --- since they're _consistently_ wrong i know to be on the lookout, and i can cope). [for an example of the confusion that comes from inconsistency that you're already familiar with: which way round do you write a Korean or Japanese name in English?]</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> if you're serious about localization, you're going to need<br>
> icu4c anyway, which isn't scared to embrace all the diversity that's<br>
> actually out there (rather than the tiny subset that the POSIX folks could<br>
> imagine, which doesn't even stretch to the need for the genitive case in dates,<br>
> to pick one random fairly mainstream example).<br>
<br>
Nope. Not going there.<br></blockquote><div><br></div><div>nor should you. "you are not an app", so real people never need to see you. developers and sysadmins do, often from machines in random locations/locales/timezones, and they (and their scripts) are better served by consistency.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I vaguely intend to have toysh command line editing handle right-to-left mode<br>
due to a completionist streak, </blockquote><div><br></div><div>to me that's different. that's more in the bucket of "full UTF-8 support", which is clearly a good thing. _someone_ is going  to have to deal with Arabic filenames at some point (and they won't necessarily be able to  read them). thanks to confusion about uppercasing/lowercasing Turkish dotted/dotless 'i's i see rather more Turkish input than you'd expect from someone who doesn't speak Turkish  and has never been there.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">and back when I was planning on implementing vi<br>
by vertically stacking the line editing plumbing (hence "linestack.c") I was<br>
gonna make sure that did it properly too. But now there's a vi there that I have<br>
nothing to do with which shares no infrastructure with anything else, so I guess<br>
that part's not my problem anymore.<br>
<br>
But that's all utf8 and unicode stuff. I haven't got a clue what the strings it<br>
includes MEAN.<br></blockquote><div><br></div><div>yeah, exactly.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> luckily, i've also been able to neuter Android's libc so none of this will<br>
> affect Android whichever way toybox goes[1]. but i still think it's a bad idea.<br>
<br>
I wouldn't have volunteered to do it myself, I'm being presented with complaints<br>
and attempting to find the least bad way to resolve them. :)<br>
<br>
"This is too many digits for humans to handle" is why adding commas to numbers<br>
was invented. It was the obvious solution. And then somebody complained that<br>
using commas is parochial, so I added the periods which should cover just well<br>
over 90% of the planet's population. (China uses 1,000.0 about everybody.<br></blockquote><div><br></div><div>the question for a lot of  those people that you need to ask yourself is: do they group in 2s or 3s or 4s or a mix or a mix at the same time? chinese-numbering-influenced countries sometimes count in ten-thousands rather than thousands, and indian numbering can let you have something 12,34,56,789 (2s and 3s in the same number).</div><div><br></div><div>#include <if you really care, you need icu4c because humans are really really weird></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If "consistently show megabytes for systems > X gigabytes" vs 'consitently show<br>
kilobytes for systems < X gigabytes" is good enough, even when the resulting<br>
numbers are long, I'm happy to rip the comma support back out.<br></blockquote><div><br></div><div>personally, that's my preferred solution. (and what i _think_ current procps top is doing, though i  don't have enough systems to be sure, and i'm not sure what  to think about your  results.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> no "real people" should ever need to look at this, but machines and developers<br>
> will, and every bit of localization hurts the real audience.<br>
<br>
Yes and no. There's a lot of developers out there who don't speak english,<br>
certainly not as their first language. I don't want to unnecessarily exclude them.<br></blockquote><div><br></div><div>they're going to have more trouble with --help output than they are here. and like i said, i'm  pretty  sure that "C/POSIX number formats" is something you  need to  learn  pretty  early on. no-one likes a for loop  condition like x <= 70,2 after all, and the kernel's never going to localize :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> at least 15'936.2 would be a valid C++14 identifier (and i'm assuming will make<br>
> it into C2x) :-)<br>
<br>
That's the opposite of helping.<br></blockquote><div><br></div><div>sorry,  just winding you up. probably  not the best time for it!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> ___<br>
> 1. strictly, the fact that you're doing your own insertion of ',' separators<br>
> might hurt me (in the `top -b` case), but i'll worry about that if i notice it<br>
> actually break any parsing. i know that's included in Android's standard<br>
> bugreports, but i _don't_ know that anyone's parsing it.<br>
<br>
If the units weren't constant before then their parsing was iffy at best. Now at<br>
least the units should be constant on a given system.<br>
<br>
Rob<br>
_______________________________________________<br>
Toybox mailing list<br>
<a href="mailto:Toybox@lists.landley.net" target="_blank">Toybox@lists.landley.net</a><br>
<a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" rel="noreferrer" target="_blank">http://lists.landley.net/listinfo.cgi/toybox-landley.net</a><br>
</blockquote></div></div>