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

Lubomir I. Ivanov neolit123 at gmail.com
Fri Jan 3 09:53:39 UTC 2014


On 3 January 2014 19:36, Linus Torvalds <torvalds at linux-foundation.org> 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").
>

i guess we can leave the translation out.
apart from the patch being bad, a russian for example being with
metric options wanting to enter "10пунта" (lbs) in place of the
previous value that is "10кг" (kg) is plausible only if he/she want's
the app to do the calculation for him/her and convert "10пунта" to the
equivalent in "kg". this might happen if he was in country where they
use imperial and told him/her your weight aid is "10lbs".

in such a case, we can instruct via the documentation to use the
english strings "lbs" (or "lb") if a conversation is required.

lubomir
--


More information about the subsurface mailing list