GNOME Bugzilla – Bug 330588
Use Seconds instead of Milliseconds
Last modified: 2010-11-18 16:24:54 UTC
In the mouse property screen, where it talks about the "Double-click timeout" is says "500 microseconds". There is no way that it means microseconds, it should say milliseconds, or preferably give the time in a fraction of a second, e.g. 0.1 seconds, 0.2.
The code that displays this should use ngettext() for proper translation.
Created attachment 59059 [details] [review] Patch fixes the bug I apologise for the mistake. Made the changes accordingly so that the label is in milliseconds.
Why use milliseconds ? fractions of a second makes much more sense. In any case, this needs to use ngettext()
Created attachment 59326 [details] [review] Patch fixes the bug. Issue 1: Why not use fraction of seconds... To show the slider value in fraction of seconds, the range of the slider should be changed to have a range of <0.1-1> in the glade file. Changing this requires a change in the gconf key which stores the value as an integer<100-1000>. Hence opted to change the label instead of changing the gconf key. Issue 2: Use of ngettext(). Modified the patch so that ngettext() is used to get thecorrect plural form of the messages.
(In reply to comment #4) > To show the slider value in fraction of seconds, the range of the slider should > be changed to have a range of <0.1-1> in the glade file. Changing this > requires a change in the gconf key which stores the value as an > integer<100-1000>. So why not just mutiply the value in the slider by 1000 when storing in gconf, and divide by 1000 when reading from gconf? We used to display the value in seconds, and it is much saner than showing milliseconds
Updation of the slider value from GConf and vice-versa is done in capplets/common/gconf-property-editor.c which is common for the sliders of other capplets too (network, sound preferences). So, opted to change the units to milliseconds.
Patch committed to CVS HEAD, thanks
This latest patch (that has been committed) is incorrect - the correct use of ngettext() is: ngettext ("%d millisecond","%d milliseconds", ...) Note that the first string is not in the plural form - although as you can never have '1 millisecond' in this dialogue, so it is not worth changing now. BTW, I'm still not convinced about the use of millisecond - it is an unncessary technical term, and the reason for not leaving it at seconds is not at all convincing
Reopening: + ngettext() is not properly used, as Crispin pointed out + there was no approval from translators and no notice sent to the release-team and documentation people + fraction of a second is better for the user than milliseconds (Crispin, again :-))
Just noticed this issue, too. Luckily I searched bugzilla before filing it, though I still don't believe this already was known... ;-) Since I'm here, confirming. I'd strongly suggest to get this simple fix in, in whatever form. Milliseconds, fractions of seconds... as long as the unit is *correct*. Whatever will be approved. Even ngettext() is a minor issue when simply renaming the label.
2006-07-24 Sven Herzberg <herzi@gnome-de.org> * gnome-mouse-properties.c: use ngettext() correctly
That fixed the ngettext usage, but it still uses *millisecond* instead of %.1f second.
Updating summary for the last remaining piece...
Created attachment 69870 [details] [review] Patch that updates the GConf schema This patch will update the GConf schema which is located in libgnome. Now I just need to create a proper patch for the mouse capplet.
if the patch is for libgnome maybe the bug should be reassigned to it?
No, because this patch just fixes the schema for the mouse capplet. I'm still working on a patch for the mouse capplet (because it needs to get proper migration code for older settings). This patch will be the really large one.
Resetting to default assignee, hasn't been touched in 3 years. What's the status on this bug?
I don't think that storing the setting in a different format helps at all, and it would break the GConf -> GSettings conversion. Finally, the mouse panel doesn't show the actual value of the setting anymore. So problem solved.