GNOME Bugzilla – Bug 50595
need option for units other than kph and knots
Last modified: 2006-02-13 07:28:36 UTC
If you double-click on the gnome-weather 0.05 applet, it will display the wind speed in "kph" if metric units is selected. The problem is that this is not the standardized way to write the unit kilometers per hour; it should be written "km/h" in many locales other than en_US. The basic problem is that the "kph" message is not marked for translation by translators. Also "knots", which is displayed when not using metric units, is not marked for translation and will be displayed as "knots" in every language.
Although unrelated to the specific problem in the bug, I can add that, to the best of my knowledge, meters per second (m/s) is more common than kilometers per hour (km/h) for measuring wind speed.
Mass-moving all relevant matches for [Ww][Ee][Aa][Tt][Hh][Ee][Rr] to gnome-applets/gweather (out of general)
Are you sure it isn't knots per hour? Could anyone verify this? I've added translation markers around these strings but we need to make sure the strings are correct.
In Sweden at least, all weather reports measure wind speed in meters per second (m/s), and different wind-related weather scenarios (like storm) is defined to be a value specified in m/s (in the case of storm, I believe it is >= 25 m/s). I believe Germany also measures wind speed in m/s. The situation could very well be that wind speed is measured in knots/h at sea, I don't know about that, but my guess is that GNOME is much less used at sea than at land...
Correction: In Sweden, all weather reports, both for sea and land, use m/s for wind speed. But different wind speed types are exactly defined in Beaufort, which closely matches knots/h, and so storm is in Sweden really 24.5 m/s. Info gathered from SMHI, the Swedish weather institute at the page listed in the URL field. Nevertheless, as m/s is what is normally used for wind speeds, I think gweather should use that when using metric units.
*** Bug 54214 has been marked as a duplicate of this bug. ***
Knots is never per hour; it is defined as distance/time (though I forget the exact units.)
I can add that France (and maybe other countries) seems to use km/h as measurement for wind speed. The default unit regarding this should really be definable by the translator.
The change proposed by Christian seems like a good idea. However implementing the functionality would break the current "string freeze" quite badly. I reckon we should wait until 2.2 to fix this correctly (you might be happy that I changed the pressure unit to hectoPascals for metric already)
Hrm... this does break the string freeze but it fixes a real bug, not just mixing things around. Keep this bug in mind, I guess, if/when the freeze is thawed.
Freeze is thawed; adding easy-fix keyword and bumping priority.
Can we have this fix in 1.4.x too please?
This bug appears to actually be fixed. [sam@bur-jud-175-069 gweather]$ grep -rI 'knots\|kph' * weather.c:#define WINDSPEED_KNOTS_TO_KPH(knots) ((knots) * 1.851965) weather.c:#define WINDSPEED_KPH_TO_KNOTS(kph) ((kph) * 0.539967) weather.c:#define WINDSPEED_UNIT_STR(units) (((units) == UNITS_IMPERIAL) ? _("knots") : _("kph"))
Closing then.
Well. What happens when the swedes want to translate knots and kph to m/s etc? The numbers will be totally off, no? Maybe we need to think about this a bit more?
Clarifying, then, and removing HIGH... this is a fairly minor functionality of a single capplet. Would still be nice to fix, of course. [is easy-fix still relevant here, since we aren't really talking about pure translation, obviously?]
To print the units in m/s for swedis and germans, Shall I use the flag from the user entry for location (Eg: location=sweden/...) or I should use something like get_locale for dynamically getting the flag to convert unit from kph/knot to m/s. kjarthana maraas:kevin:C Rose: can u give me ur comments on this? my patch is in mid way.
The unit to use should probably be chosen by which locale is used, and not so much location (after all, other choices in unit are defined by the locale). And I'm not really sure Germany uses m/s instead of km/h for wind speed. That should probably be confirmed before being coded into the patch.
I think the unit shouldn't be hardcoded in locale. For example even though I live in Poland (we usually use km/h), I would like to see wind speed in knots, because I'm a yachtsman :-) Therefore it would be nice if the default was set according to current locale, but there was also a way to change the unit. BTW: (1 knot) == (1 nautical mile / 1 hour)
I asked translators what unit for wind speed is used in their regions. Here are the results: locale unit status ------------------------------------------------------------------------------- de_DE m/s ? el_GR km/h ? et_EE m/s ? fr_FR km/h CONFIRMED (used by the official French weather office on its website) hu_HU km/h CONFIRMED (National institute for weather forecast, www.met.hu) lt m/s ? pl_PL km/h CONFIRMED (e.g. http://www.imgw.pl/cgi-bin/imgwtod?miasto=krakow)sk_SK m/s ? sv_FI m/s ? sv_SE m/s CONFIRMED (http://www.smhi.se/, http://www.tt.se/sprak/ordval.asp) I don't know if the default (for locales not specified above) for metric should be m/s or km/h, though. Perhaps m/s as meters and seconds are base units, but I really don't know what makes the best default here.
That got somewhat messed up. Here's a more readable version: locale unit status ----------------------- de_DE m/s ? el_GR km/h ? et_EE m/s ? fr_FR km/h CONFIRMED hu_HU km/h CONFIRMED lt m/s ? pl_PL km/h CONFIRMED sk_SK m/s ? sv_FI m/s ? sv_SE m/s CONFIRMED
Addition: it_IT km/h ?
Addition: da_DK m/s CONFIRMED (http://www.dmi.dk/)
no_NO m/s CONFIRMED (http://www.dnmi.no/)
ko_KR m/s CONFIRMED (http://www.kma.go.kr/kma_syn/sfc_now.html)
Addition: pt km/h ?
Couldn't the po file have a default (Km/h) and a conversion factor (1) and if you want m/s you just translate default measure to "m/s" and conversion factor to "0,277" and in the code you make like: 60Km/h ---> 1 x ---> 0,277 x = (60km/h * 0,277) / 1 = 16,62 m/s This way you can show correct velocity for given locale spec. for pt... msgid "put country velocity measure here" msgstr "Km/h" msgid "put conversion factor from Km/h to your velocity" msgstr "1" for no_NO it would be... msgid "put country velocity measure here" msgstr "m/s" msgid "put conversion factor from Km/h to your velocity" msgstr "0,277" To show a 60Km/h wind speed on correct locale format, you print the result of: pt: (60 * 1) Km/h no_NO: (60 * 0,277) m/s This way, no hardcode needed for default locale measure.
Addition from Carlos Perelló Marín <carlos@gnome-db.org>: es_ES km/h CONFIRMED (The weather man at TV said that :-)
Addition from Francesco Marletta <francesco.marletta@tiscali.it>: it_IT km/h
Also for Turkish we can supply this information: tr_TR km/h CONFIRMED (we got it also from weather reports :-))
christian Rose:any idea, when can this updatation gets over? so that I can work for this bug to fix at the earliest?
I think it's safe to start working on this now. If there are any additional updates from now on, they can be filed as seperate bugs.
Did anything happen here? I'll gladly take the patch for 1.4.x. Probably should be fixed in 2.x too.
It should, yeah. And the 2.2 string freeze is not yet upon us... Anyone on the Cc list feel like fixing, or shall I throw the bug number at gnome-love or similar lists?
> Anyone on the Cc list feel like fixing, or shall I throw the bug > number at gnome-love or similar lists? Please go ahead and throw it at those lists. If someone is working at this already, they would have said so, I think. :)
*** Bug 97592 has been marked as a duplicate of this bug. ***
Removing myself from Cc: since I'm monitoring gnome-applets through bugzilla anyway.
Yogeesh, any progress on this patch?
*** Bug 104812 has been marked as a duplicate of this bug. ***
*** Bug 127130 has been marked as a duplicate of this bug. ***
So, here's the updated list: locale unit status ------------------------- da_DK m/s CONFIRMED de_DE m/s ? el_GR km/h ? es_ES km/h CONFIRMED et_EE m/s ? fr_FR km/h CONFIRMED it_IT km/h CONFIRMED hu_HU km/h CONFIRMED ko_KR m/s CONFIRMED lt m/s ? no_NO m/s CONFIRMED pl_PL km/h CONFIRMED pt km/h ? sk_SK m/s CONFIRMED sv_FI m/s ? sv_SE m/s CONFIRMED tr_TR km/h CONFIRMED
The URL field has been removed from bugzilla.gnome.org. This URL was in the old URL field, and is being added as a comment so that the data is not lost. Please email bugmaster@gnome.org if you have any questions. URL: http://www.smhi.se/kund_t/vindar.htm
fi_FI m/s
*** Bug 138066 has been marked as a duplicate of this bug. ***
The UK (en_GB) uses a mixture of metric and imperial measurements when it comes to weather, which makes the use of a single "use metric" boolean useless. Temperature - centigrade (metric) Wind speed - miles per hour (non-metric) Pressure - millibars (metric) Visibility - miles (non-metric) So I propose the following: 4 translatable strings to set the units to use for each of the above: temp unit = farenheit | centigrade | kelvin (just cause we can) speed unit = knots | miles per hour | kilometers per hour | meters per second pressure unit = inches Hg | cm Hg | millibars | hPA distance unit = miles | kilometers | meters The defaults are picked up from the translation file via these four strings, but the user can override these from the configuration panel. Which replaces the existing "use metric" option. In addition to this all the unit names will be translatable as well (just so us Brits can use metre instead of meter!) I'll try to know together a patch for this over the weekend/early next week.
Created attachment 27222 [details] [review] First patch Here is my first attempt at a patch for this, the preference dialog now has 4 combo boxes, one for each unit. The translator can select the system default value. The patch probably needs some tidying up, to remove code that is no longer used, but other than that it appears to work.
Created attachment 27223 [details] screenshot Here is a screenshot showing what the preference and forecast dialogs look like with the above patch.
Created attachment 27312 [details] [review] updated patch Here is an updated patch, which removes some unused code and also now handles the case were the gconf keys are not writable.
Kevin could you look over this, i think Gareth has some superB patches here. One comment: + { SPEED_UNIT_KPH, "kph" }, This should be "km/h" Some more work is needed but this is a very good start. Gareth are you planning to fix this issue completely ?
Dennis, That was deliberate, I was under the impression that kph was used in the US and I thought you were supposed to use the en_US locale in the code. But it's not a big deal, I can change it. Yep, I'll finish the patch off - what else needs to be done?
Created attachment 28359 [details] [review] updated patch 2 I've updated the patch, changing kph to km/h as suggested. I also removed some unused variables.
It seems that kph isn't a metric unit, maybe some i18n guy could shine some light on this tho. The patch is big so i need to look through it, but from a first glance it's looking pretty! Could you explain how translaters have to work with it ?
There are four translatable strings that translators can use to select the default value for each unit. Each string can take one of a number of options, this then becomes the default unit to use when the applet is added to the panel. The end-user can still override this by selecting a different value from the drop down lists - as illustrated in the screen shot. Here is the po entries for each of these 4 strings... #. TRANSLATOR: This is the default unit to use for temperature measurements. #. Valid values are: "Fahrenheit", "Centigrade" and "Kelvin" #: gweather/gweather-pref.c:487 gweather/gweather-pref.c:496 msgid "DEFAULT_TEMP_UNIT" msgstr "" #. TRANSLATOR: This is the default unit to use for wind speed. #. Valid values are: "mph" (miles per hour), "knots", #. "km/h" (kilometers per hour) and "m/s" (meters per second) #: gweather/gweather-pref.c:514 gweather/gweather-pref.c:524 msgid "DEFAULT_SPEED_UNIT" msgstr "" #. TRANSLATOR: This is the default unit to use for atmospheric pressure. #. Valid values are: "inHg" (inches of mercury), "mmHg" #. (millimeters of mercury), "hPa" (hecoPascals) and "mb" (millibars) #: gweather/gweather-pref.c:544 gweather/gweather-pref.c:554 msgid "DEFAULT_PRESSURE_UNIT" msgstr "" #. TRANSLATOR: This is the default unit to use for visibility distance. #. Valid values are: "miles", "kilometers" and "meters", #: gweather/gweather-pref.c:572 gweather/gweather-pref.c:581 msgid "DEFAULT_DISTANCE_UNIT" msgstr ""
> It seems that kph isn't a metric unit, maybe some i18n guy could shine some > light on this tho. kph isn't a metric unit? It's kilomet(re|er)s per hour, and is derived from meters per second, so although of not consisting of SI units, the onliest difference is a factor 3.6^-1. regs, Chris
As cneumair already stated, km/h is a metric unit, although not an SI one. The SI-derived one would be m/s, but as most countries use km/h for vehicle speeds, some countries use km/h for wind speeds as well as it is then easier to relate to vehicle speeds. Others use m/s, since it's the properly SI-derived unit. Hence the problem that different countries need different default wind speed units. My comments on comment #53 and the default temperature unit is that I think this would be more failureproof if only the abbreviations were used; otherwise one could mistakenly translate "Centigrade" to "Celsius" (as Centigrade is named in many countries) and the whole thing would break. Also, I took the liberty of reordering the comment to list the SI unit first. My suggestion: #. TRANSLATOR: This is the default unit to use for temperature measurements. #. Valid values are: "K" (Kelvin), "C" (Centigrade), and "F" (Fahrenheit) #: gweather/gweather-pref.c:487 gweather/gweather-pref.c:496 msgid "DEFAULT_TEMP_UNIT" msgstr "" Same thing here with the pressure units, and "hecto" in the comment lacked a "t" aswell: #. TRANSLATOR: This is the default unit to use for atmospheric pressure. #. Valid values are: "hPa" (hectoPascals), "mb" (millibars), #. "mmHg" (millimeters of mercury), and "inHg" (inches of mercury). #: gweather/gweather-pref.c:544 gweather/gweather-pref.c:554 msgid "DEFAULT_PRESSURE_UNIT" msgstr "" Same problem with the distance units. The standardized abbreviations would be preferred as "unit keys", since they are more difficult to translate or enter wrongly. #. TRANSLATOR: This is the default unit to use for visibility distance. #. Valid values are: "m" (meters), "km" (kilometers), and "mi" (miles) #: gweather/gweather-pref.c:572 gweather/gweather-pref.c:581 msgid "DEFAULT_DISTANCE_UNIT" msgstr ""
Menthos, as an i18n guy, how do you like the solution generally ? Kevin is on vacation, but i think i'd like him to look at this first before i'll be putting it into CVS, it's quite a change! :)
Created attachment 28485 [details] [review] updated p
I've updated the patch to reflect Menthos's comments: - translator now enters abbreviations to select distance and temperature units - re-ordered the drop-down lists (and comments), so that the SI units come first Sorry about the spam.
Menthos could you have a look at it and tell us if it's good for the translaters this way ? If no issues arise i'm going to merge it.
My answer to comment #56: Well, in an ideal world this information would belong in the locale data of glibc et al, and not be triggered by translations. But unfortunately the world is not ideal, and the locale data doesn't contain this type of information, so we need to key off translations and LC_MESSAGES to get the proper default units. This has several drawbacks. The most obvious one is that if, by example, the user wants the application messages in English, but otherwise all other locale-specific settings according to his usual locale, it won't work as expected with these settings since they will be tied to the message translations. But it will work most of the time when a user wants all locale-specific settings, including translations, from the same locale. Another drawback is that it's not clear what the default value should be, in case there's no suitable translation. With a locale data based system it would be clear what the default would be: the C locale with whatever settings it uses for a default (usually metric/SI units). US-suitable settings would be provided by the en_US locale. With a translation-based system, it's up to the GNOME code to decide what the default should be. Since we usually don't have en_US "translations", this could mean that the code (the C locale "translation") should by default use US-specific settings and hence US-specific units. But defaulting to US-specific units will be a drawback for all other locales in the world where these GNOME messages may not have been translated yet. Hence, my opinion is that the code default should be whatever is as close to the SI units as possible (possibly with the exception of Kelvin since it's not used outside science AFAIK), since that will be the most common denominator for most locales of the world, and that we should introduce an en_US.po in gnome-applets that just makes these default settings more friendly to en_US locale users. But this is not without controversy -- other maintainers have argued that they will use en_US settings as the code default, since they see the US as their biggest market, and a seperate en_US.po as an unnecessarily complex solution.
In reply to comment #60: I'm not sure defaulting to SI units is the best way to go, as we would be changing the way the applet currently works. Even if a en_US.po file was introduced, I very much doubt that it will be picked up by any user in the US, simply because hardly anyone in the US changes the locale to anything but C. Therefore it would be more or less worthless. I suppose we could do some sort of hack, where if the locale is C the code default is imperial units, else the code default will be SI units (with Centigrade instead of Kelvin). The translated defaults, would obviously over-ride these defaults. Does that sound a sensible?
*** Bug 103079 has been marked as a duplicate of this bug. ***
Created attachment 28847 [details] [review] updated patch I've changed the patch, so that if the DEFAULT_*_UNIT strings have not been translated, then the defaults chosen depend on the LC_MEASUREMENT setting in the locale (as suggested in bug #13079) If this is set to metric then the defaults are: DEFAULT_TEMP_UNIT C DEFAULT_SPEED_UNIT m/s DEFAULT_PRESSURE_UNIT hPa DEFAULT_DISTANCE_UNIT m else they are DEFAULT_TEMP_UNIT F DEFAULT_SPEED_UNIT knots DEFAULT_PRESSURE_UNIT inHg DEFAULT_DISTANCE_UNIT miles
Sorry, the locale suggestion actually came from bug #103079
Most sane distributions default to use the en_US locale rather than the C locale if the user selects US English as the language. Defaulting to C locale would be broken in many ways, and probably not what the user expects (since it has many oddities, such as specifying use of metric units while on the same time specifying 7-bit ASCII as the charset), so it's probably not what the typical en_US user wants at all. Thus I don't think we should need to take into account such broken distributions that set the user up with C locale. If the user opted for US English during the install of a sane, modern distro, he's probably already set up with an en_US or en_US.UTF-8 locale, and would use en_US.po translations when available without even knowing about it. That being said, I very much like the way you handle the cases where the DEFAULT_*_UNITs haven't been translated. If I understand it correctly, if they haven't been set in the translation, the code tries to make a reasonable best assumption based on the LC_MEASUREMENT setting. That should make this "just work" for most users. Excellent work!
Yes, the defaults are handled as described by Christian. This is true for the default C locale as well, so that with a locale of C you get metric units.
Gareth is this patch ready to go in ?
Well I think it is ready.
Ok tested, looks great I've got no comments! I've submitted in to CVS, thanks a lot Gareth, this is really outstanding! So after 3 years, we can finally close this bug :)) Cheers!