[PATCH 1/2] Models: translate the user entered weight units

Dirk Hohndel dirk at hohndel.org
Fri Jan 3 09:40:04 UTC 2014


On Fri, 2014-01-03 at 09:36 -0800, Linus Torvalds wrote:
> On Fri, Jan 3, 2014 at 9:08 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
> >
> >> In particular, remember: if the string is some translation of the
> >> standard unit, matching _that_ doesn't even *matter*, because it will
> >> be matched by default by simply matching the locale setting (which
> >> will always match the translated unit name, since that is where it
> >> came from). See?
> >
> > I don't understand that last sentence. I think we should compare to
> > "lbs" and tr("lbs") and accept both. Same for "kg".
> 
> The point is, nobody sane likely *uses* tr("lbs"). There's no reason
> to ever compare it. And "kg" is either always "kg" or falls under the
> same heading.
> 
> Let me explain the "nobody uses tr("lbs")" by a practical example.
> 
> Let's say that you have set your units to imperial, but are in a
> German locale, so that subsurface translates a 10kg weight to "22 US
> Pfund".
> 
> Now, that means that if somebody just edits the number to fix it up to
> "28 US Pfund", we'll actually see that "US Pfund" part, but it doesn't
> actually *matter* whether we match it or not. The only thing that
> matters is that we don't match "kg". Because if we don't match any
> unit at all, we'll use our user units - which are lbs. So we do the
> right thing.
> 
> And if the user is in metric, and the weight started out as "10kg",
> but the user realized that "Ooops, I'm in Hawaii, and their weights
> are all imperial, I'd better fix it to be "10 lbs" instead, I can
> pretty much guarantee that no sane German ever will come up with "US
> Pfund" on his own (ie if that string wasn't already fed to him
> *because* he was in an imperial locale). He might try a lot of things,
> but the likelihood that he'd enter that random string is basically
> zero. Agreed? But at the same time, he'll be *physically* in a locale
> where "lbs" actually does make some sense (ie it might be written on
> the dive board).
> 
> So reasonably, I don't think there's a lot of upside to translating
> "lbs". All sane countries use metric measures and will either use "kg"
> or whatever translation of it (but not matching it won't matter, since
> we'll default to "kg" in a metric unit model anyway).
> 
> So the *only* time you actually care about trying to match the unit
> string is when it's a *foreign* unit string, and that by definition
> means that you'll not know what the hell those crazy furriners use,
> because by definition, that foreign unit is foreign in your locale.
> But "kg" and "lbs" you at least have a *chance* with. If you're
> American, you might just know about "kg" or at least ask your dive
> buddy. And if you're not, you're going to write something random,
> because you'll have no f*cking idea what a pound is in your language
> anyway.
> 
> (Side note: I think we might want to change the three-character "lbs"
> comparison to a two-character "lb" comparison, because somebody who
> actually does know what they are doing might well write "10lb").

side note: I am amused by how much energy we are spending on figuring
out whether we should correctly parse the local translation of an
antiquated unit of weight used by roughly one country in the world...

:-)

/D



More information about the subsurface mailing list