GNOME Bugzilla – Bug 736768
Need localized distance units in routing summary
Last modified: 2015-01-30 15:19:00 UTC
I'm in the USA and my stupid country uses miles. gnome-maps should show miles in locales that need it. Or maybe something like: 10 miles (16km)
Thanks for the suggestion! I think the countries that use imperial units are USA, Burma and Liberia, does that sound correct? So maybe a function that looks at the locale and converts to imperial distance units in those cases? I have marked this as gnome-love, as it seems like a nice entry point to gnome and gnome-maps development. Jonas
You can use the user's locale and look for the LC_MEASUREMENT setting http://man7.org/linux/man-pages/man7/locale.7.html On my system: $ locale LC_MEASUREMENT 2 UTF-8 The 2 means that my locale uses miles.
So, I researched a bit on how to implement this and I realized that we have a really wide range of possibilities. 1) Have a hardcoded list of languages in Maps with imperial units and match it with the user configured language by using the LANG env variable, this will ignore specific settings in LC_MEASUREMENT and we need to maintain a list of languages with imperial units, but it's easy to implement. We can solve the specific LC_MEASUREMENT setting if we can read its value, it seems it's not present as an environment variable, but it can be read by parsing /etc/locale.conf or by using systemd-localed service. 2) Have access to call nl_langinfo(_NL_MEASUREMENT_MEASUREMENT) from Maps JS code, this will return the configured unit system, we have many ways to do this: 2.a) Add some native code to Maps, like a little private GIR library that wrap the nl_langinfo function. The typelib file will be installed in /usr/lib/gnome-maps/girepository-1.0/GnomeMapsPrivate-1.0.typelib 2.b) Add native code to Maps but by hacking the Gjs context, I'm really not sure on how to do that, we need to research it a bit. This one is like a simpler version of (2.a) 2.c) Add nl_langinfo wrapper to Gjs, I asked this to IRC but it seems that its not a meaningfully requirements to most Gjs apps to add it. 2.d) Add support for nl_langinfo like features in GLib, I mean, some sort of cross-platform component to get locale information (not only measurement unit, but number format, page size, etc), this must be discussed with GLib authors, designed and written, so it's not an easy and fast solution. 3) Call "locale" command directly and parse its output. I'd go for (2.a) or (2.b), if we realize that is unnecessary complex, go for (1). Your opinions are welcome.
4) Show both units: 1.6 km (1 miles)
4) Would be good to have for now I like 2.d. As comparison, Apple offers this in their API: https://stackoverflow.com/questions/7413144/how-do-i-know-which-is-the-default-measure-system-imperial-or-metric-on-ios
(In reply to comment #3) > So, I researched a bit on how to implement this and I realized that we have a > really wide range of possibilities. Excellent. > > 1) Have a hardcoded list of languages in Maps with imperial units and match it > with the user configured language by using the LANG env variable, this will > ignore specific settings in LC_MEASUREMENT and we need to maintain a list of > languages with imperial units, but it's easy to implement. > We can solve the specific LC_MEASUREMENT setting if we can read its value, it > seems it's not present as an environment variable, but it can be read by > parsing /etc/locale.conf or by using systemd-localed service. > Well the list is three countries and we do not expect the list to grow, right? No countries are starting to use imperial units today? > 2) Have access to call nl_langinfo(_NL_MEASUREMENT_MEASUREMENT) from Maps JS > code, this will return the configured unit system, we have many ways to do > this: > > 2.a) Add some native code to Maps, like a little private GIR library that wrap > the nl_langinfo function. The typelib file will be installed in > /usr/lib/gnome-maps/girepository-1.0/GnomeMapsPrivate-1.0.typelib I do not want this. This does not merit supporting something like this and it feels to me like a defeat to have to add our own GIR library. If we ever do it will be for a must-have feature that we cannot implement in any other way. > > 2.b) Add native code to Maps but by hacking the Gjs context, I'm really not > sure on how to do that, we need to research it a bit. This one is like a > simpler version of (2.a) I do not get what you mean by this, could you explain a bit more? > > 2.c) Add nl_langinfo wrapper to Gjs, I asked this to IRC but it seems that its > not a meaningfully requirements to most Gjs apps to add it. > I do not think this is the right way. > 2.d) Add support for nl_langinfo like features in GLib, I mean, some sort of > cross-platform component to get locale information (not only measurement unit, > but number format, page size, etc), this must be discussed with GLib authors, > designed and written, so it's not an easy and fast solution. > This could be interesting, but needs investigating if it can be done portable and what should be in such a "locale" part of glib. > 3) Call "locale" command directly and parse its output. > Not sure I want. > > I'd go for (2.a) or (2.b), if we realize that is unnecessary complex, go for > (1). > > Your opinions are welcome. I think using GLib.get_language_names()[0] and checking for en_US, my_MM and en_LR is the simplest way to do this.
(In reply to comment #4) > 4) Show both units: 1.6 km (1 miles) No I do not like this at all :)
(In reply to comment #6) > > > > 2.b) Add native code to Maps but by hacking the Gjs context, I'm really not > > sure on how to do that, we need to research it a bit. This one is like a > > simpler version of (2.a) > > I do not get what you mean by this, could you explain a bit more? I mean use the GjsContext API in main.c to add a global function that wraps nl_langinfo. Let's discard it, it's pretty hacky and we will get rid of main.c soon.
Created attachment 287206 [details] [review] utils: Add suport for Imperial units
Review of attachment 287206 [details] [review]: Thanks, this looks nice! See some comments below. ::: src/utils.js @@ +47,3 @@ let _iconStore = {}; +let measurementSystem = null Having this as a global seems unnecessary @@ +170,3 @@ +{ + if (measurementSystem) + return measurementSystem; Don't bother with this, a function that wants to use this can use a variable to avoid multiple calls. @@ +172,3 @@ + return measurementSystem; + + let locale = GLib.getenv('LC_MEASUREMENT') || GLib.get_language_names()[0]; Which systems have the LC_MEASUREMENT env? And what is the return of it? How will the code below handle if GLib.getenv('LC_MEASUREMENT') returns something? @@ +339,3 @@ + distance = Math.round(distance * 100) / 100; + return _("%f miles").format(distance); + } So miles is the only imperial unit we need to bother with? No yards or feet or any of the rest?
Comment on attachment 287206 [details] [review] utils: Add suport for Imperial units >+ return _("%f miles").format(distance); Please see https://wiki.gnome.org/TranslationProject/DevGuidelines/Plurals
(In reply to comment #11) > (From update of attachment 287206 [details] [review]) > >+ return _("%f miles").format(distance); > > Please see https://wiki.gnome.org/TranslationProject/DevGuidelines/Plurals I think I will use "mi" instead.
Review of attachment 287206 [details] [review]: ::: src/utils.js @@ +170,3 @@ +{ + if (measurementSystem) + return measurementSystem; You think? This will overhead the app unnecessarily... mainly when populating instruction list, I followed the same convention we used for debug function here. Also, we won't get runtime notification about locale changes unless we use localed. @@ +172,3 @@ + return measurementSystem; + + let locale = GLib.getenv('LC_MEASUREMENT') || GLib.get_language_names()[0]; You can have different locales configured for different elements, so, for example, you can have your GUI in fr_FR and have the measurement units in en_US, namely imperial units. LC_MEASUREMENT variable has the locale to use for measurement units, /etc/profile.d/locale.sh is in charge to declare this variable by reading /etc/locale.conf. @@ +339,3 @@ + distance = Math.round(distance * 100) / 100; + return _("%f miles").format(distance); + return _("%f km").format(distance); I'm very ignorant on imperial units :) I think I will use the Google Maps algorithm here: for distances less than 0.1 miles, show the distance in feet.
Review of attachment 287206 [details] [review]: ::: src/utils.js @@ +170,3 @@ +{ + if (measurementSystem) + return measurementSystem; Ok. @@ +172,3 @@ + return measurementSystem; + + let locale = GLib.getenv('LC_MEASUREMENT') || GLib.get_language_names()[0]; Great. @@ +339,3 @@ + distance = Math.round(distance * 100) / 100; + return _("%f miles").format(distance); + } Seems fine. I think. I am ignorant as well :)
It would be best to show feet for things under .2 miles 1 mile = 5,280 feet I would prefer "mi" and "ft" over spelling the words out for consistency and brevity.
(In reply to comment #15) > It would be best to show feet for things under .2 miles > > 1 mile = 5,280 feet > > I would prefer "mi" and "ft" over spelling the words out for consistency and > brevity. Sorry, did you mean to show feet for things under 2 miles or under 0.2 miles?
(In reply to comment #16) > (In reply to comment #15) > > It would be best to show feet for things under .2 miles > > > > 1 mile = 5,280 feet > > > > I would prefer "mi" and "ft" over spelling the words out for consistency and > > brevity. > > Sorry, did you mean to show feet for things under 2 miles or under 0.2 miles? And why you think that? :)
Review of attachment 287206 [details] [review]: ::: src/utils.js @@ +216,3 @@ + return _("%f km²").format(area); + else + return _("%f miles²").format(area); I am going to use "sq mi" here instead of miles² or mi², seems to be more traditional.
Created attachment 287534 [details] [review] utils: Use circle radius to represent the accuracy ---- As we discussed in Hangouts, we think this is more natural and legible representation of the accuracy. Also, this helps to simplify the next patch that adds Imperial units support.
Created attachment 287535 [details] [review] utils: Add support for Imperial units ---- Mostly rewritten distance conversion algorithms and now we show distances in feet for distances smaller than 0.2 miles.
These patches should fix #729252.
I did mean 0.2 mi (which is something around "one thousand feet", which one would typically say instead of "point two miles"). Showing feet for very short distances matches Google Maps, and is the convention (at least in USA).
Review of attachment 287534 [details] [review]: Very nice.
Review of attachment 287535 [details] [review]: Aside from nit, Ack. ::: src/utils.js @@ +309,3 @@ + // Convert to feet + distance = Math.round(distance * 3.2808399); + if (distance >= 1056) { Maybe a comment here about this being 0.2 miles? Dunno.
Comment on attachment 287535 [details] [review] utils: Add support for Imperial units >+ return _("%f km").format(distance); >+ return _("%f m").format(distance); >+ return _("%f mi").format(distance); >+ return _("%f ft").format(distance); Please see https://wiki.gnome.org/TranslationProject/DevGuidelines/Use%20comments
(In reply to comment #21) > These patches should fix #729252. I agree. Marking as obsolete.
Created attachment 287616 [details] [review] utils: Add support for Imperial units - Add 0.2 miles comment - Add translator comments
Review of attachment 287616 [details] [review]: Thanks! (Marking as commit_now, but we need to branch out gnome-3-14 first, so please do not commit now :) )
Attachment 287534 [details] pushed as da1306b - utils: Use circle radius to represent the accuracy Attachment 287616 [details] pushed as 982cec1 - utils: Add support for Imperial units