GNOME Bugzilla – Bug 611576
Present date/time.
Last modified: 2010-09-20 10:54:43 UTC
Orca keys to read date, time and battery are most common feature requests from my orca users, can we add these as part of core orca code base.
Hi, In my opinion at least keys to read date/time is something novice users expect from the screen reader. So... +1 If agreed I can write the patch, it seems not that hard.
Rui, I've just assigned this one to you. And I'm removing the Andalucia metabug blockage. (I had identified this bug as being a potential task for the developers which will be awarded a grant from Junta de Andalucia in Spain.) I do not want work to be held up simply because we're waiting on that. Please proceed on this one. Thanks!
Hi Joanmarie, Sorry for having these dobts but... 1. May I implement this features on default.py? It seems the best place but the file is becoming so big that I'm not sure. 2. When reporting the date and time , should I leave the date and time format for translators? Don't know if translators are aware of strftime format strings or so... It seems python have a format to print date or time representation based on localization but trying this on the python shell it gives the english representation. Don't know what are the i18n policies about date and time formating... 3. Regarding battery status... In my orca-customizations.py file I use the acpi command to get the status but this aproach as some drwbacks: no i18n out of the box and it seems not all hardware uses acpi. On the other hand I could get the information from /sys but it might be not so portable. Maybe solaris uses different convections, don't really know. And it may differ on hardware configurations, distros, kernel versions, etc... So I thought for myself... If gnome-power-manager knows it we shall know it too. The answer is DeviceKit-power that has a dbus interface to get all this power-management things. Question is: is it ok to use dbus calls? If needed on an assynchronous way so the pyatspi loop doesn't get blocked (calling acpi comand blocks it tough). Is it ok to depend on dbus and devicekit-power? From what I read it seems present on all modern distros but... With this I think i18n and portability are saved. Sorry for the long speech :)
Created attachment 158046 [details] [review] Patch to implement reading of current time and date. orca-F12 present current time, orca+f12 (double click) read current date.
Created attachment 159788 [details] [review] Another way do this function Rui, unfortunately you owerwrite your patch the default Orca+f12 Firefox keybinding (switch between gecko and Orca caret navigation). Please look my attached this day morning doed patch, because I followed another way to handle date and time output spokening and braille display writing format, and need this method testing with non english language environment. For example I not numerical values to sending date and time values, and marked translation the hour and minute suffix word with time spokening and braille display writing function, see detailed my test results: When I tested my patch with english language, date spokening string is following: 2010. April 28, Wednesday. If I using hungarian language, the sent output is following: 2010. április 28, szerda. April mean in hungarian language the április month, and wednesday mean in hungarian language the szerda week day word. Not need marking translation with queryed date fields, if we not need do translator determining year/month/monthday/weekday order. If I request current time and using english language, the current time spokening and braille display present message is following, because i marked translation the hour and minute suffix words: 14 hour 11 minute. If I using hungarian language, the spokened and braille display wroted output is following: 14 óra 11 perc. In hungarian language, hour means óra word, and minute means perc word). This method is good you if you not using english language? I marked translation the learning mode shortcut keys description texts. Now I mapped the current date spokening and braille display writing key with Orca+d, current time spokening and braille display writing key with Orca+t key combination. But if you have an universal key ydea with not conflicting another application Orca key binding, I welcome do modification. Hope my patch help you, Unfortunately battery querying I not have ydea how can possible do this with distribution undependent, both you I use acpy to query and process this information with my custom script. Attila
*** Bug 617064 has been marked as a duplicate of this bug. ***
Created attachment 159790 [details] [review] BTV, I forgot remove prewious patch the hu.po translation file difference. This is the right patch. This is the right patch, prewious when I do git diff operation, I forgot remove the hu.po translation file difference. Sorry! Attila
Review of attachment 158046 [details] [review]: Rui, thank you for looking into this. I am almost happy with your patch. I managed to find the following, that should handle the localization correctly. http://www.doughellmann.com/PyMOTW/locale/index.html#dates-and-times please take into account bug #616848 when outputting to braille, and maybe use script.displayBrailleMessage(message, flashTime=settings.brailleFlashTime) or read Joanie's comment number 15 on bug #616820. As for the issue that Attila brings up, that the short cut is already defined for firefox, I think that the firefox binding should be changed, so that the user gets a consistent experience of keymappings from screenreader to screenreader. As for power I am not so sure. Thanks
Review of attachment 159790 [details] [review]: Hi Attilla, Thanks for this alternative patch. I think if Rui modifies his patch with my suggestions it might be a bit cleaner. That way we also dont have to translate more messages, but we can use the defaults as already known by the system. Thank you for having a go.
Hy John, Ok, I agree my patch rejection, because I use possible little complicated or not cleaner way. When Rui apply your suggestions, how can possible working for example the time spokening? What spokened output are resulted this modification? If I understand right, we will be not using hour and minute suffix words, because the systems python locale time routines this is not known by default. I understand correct? Attila
(In reply to comment #8) Review of attachment 158046 [details] [review]: > > Rui, thank you for looking into this. > > I am almost happy with your patch. > > I managed to find the following, that should handle the localization correctly. > > http://www.doughellmann.com/PyMOTW/locale/index.html#dates-and-times > The script presented there doesn't even run in my box, locale.setlocale says that the locales are not known... strange. Anyway the output presented there, at least for portuguese, doesn't provide correct output. In my patch I used the %X and %x switches for strftime, that, according to strftime docs, provide date for current locale. It is giving good results for portuguese, does it give for hungarian too? > please take into account bug #616848 when outputting to braille, > and maybe use > > script.displayBrailleMessage(message, flashTime=settings.brailleFlashTime) > > or read Joanie's comment number 15 on bug #616820. > Yes, will do. Sorry, didn't notice that function, thanks for pointing out. > As for the issue that Attila brings up, that the short cut is already defined > for firefox, > I think that the firefox binding should be changed, so that the user gets a > consistent experience of keymappings from screenreader to screenreader. > Agreed. > As for power I am not so sure. > > Thanks I suggested calling the power manager via dbus (was formerly devicequit-power now is upower or something like that)... But It's not that trivial, and I need suggestions about what output we need. Like just battery percentage, status, or what... Rui
Rui, unfortunately I think not, with your setting sends numerical values, and hungarian users don't like this form with date. Very nice you do a setting value. When I change following setting with src/orca/settings.py file, Orca correct hungarian locale the date (year, month name, month day and week day), my used value is following: sayDateFormat = "%Y. %B %d, %A." This is not good with portoguese users if we do an UI combobox to possible replace the field orders?
Created attachment 159866 [details] [review] This patch containing some translation specific modification. Hy Rui and Jon, Please look this patch, I do following modifications, I hope this modifications is not rejected :-):-) in src/orca/default.py file: 1. I owerwrite original Rui doed Orca+F12 based shortcuts with Orca+d (date) and Orca+t (time keybinding combinations. 2. In saydate function, I put correct braille display writing command. 3. In saytime function, I do official translation method with translate the sending final current time message. I do this way, because I read entire python.strftime documentation formats, but I not found a format with full correct with hungarian language pronunciation. This is a more better way with my prewious doed and rejected patch, because now the code is cleaner. 4. I put correct braille writing message method in saitime function. I do an optional modification with src/orca/settings.py file: 1. I remove the sayTimeFormat setting, because optional better to handle translation way with current time message translation I think. 2. Temporary, I change the sayDateFormat setting with "%Y. %B %d, %A." format string. Rui, Jon, if my doed official translation way is good with you, possible need doing following final works: 1. Need do a cosmetic work in saytime function: Need cut first 0 numbers with hour, minute and second variables if the hour, minute and second are smallest with 10. For example the 08 hour 08 minute 08 second output is not beautiful, but 8 hour 8 minute 8 second output is yes I think. For example, in hungary, we newer spokening 08 hour 08 minute, spokening 8 hour 8 minute. If any value is 00, need cut the first 0 character. 2. A possible enhancement with saydate function customization with graphical way: With Rui doed in src/orca/settings.py the sayDateFormat setting is a very good way in date spokening, because in saydate function not need do any translation work, because general awailable date formats is good. But, if we would like variable with "%Y. %B %d, %A." format order, simplest the users if have for example a radio button in Orca preferences GUI window, with possible have following variations: The radiobutton label possible is following: date spokening format (need mark translation the label) Values are: year, month, month day, week day ("%Y. %B %d, %A." setting), need marking translation this item. Week day, month day, month, year ("%A, %d %B %Y." setting), need marking translation this item. Or another variables with you would like. Of course, end users possible edit hand this setting, but what happen if you not known time.strftime formats? :-):-) Attila 2.
With battery status message suggestion: Rui, when I process acpi status messages with hungarian Orca users with Orca-customizations.py file, I sent final following style processed messages when all informations are processed: If the battery is not charging, I look how many hour, minute remaining, and how many percentage are remaining. I send following style output, now I translated with english language: 2 hour, 34 minute are remaining (52%). If the hour and minute numbers is 02 for example, I cut the first 0 number, because this is unneed spokening. If the hour is 00, I spokening only following output for example: 59 minute are remaining (30%). If the minute is smaller with 10, I cut of course the first 0 number, because this is unneed spokening. If the battery is actual charging but not full charged, I sending following final output message: 50% are awailable (attached, charging). If the battery is full charged, but the charger is not discommected, I sending following final message: full charged (100%). I don't no this style status messages are possible request with your would like method, I not known detailed this. Absolute sure acpi is not a good way if you would like do distribution undependent battery spokening feature, you are absolute right with first comment. But, if possible do this style indicator messages, and the messages are translatable, resulting very good battery status feature with full localizable with non english languages. Attila
(In reply to comment #12) > Rui, unfortunately I think not, with your setting sends numerical values, and > hungarian users don't like this form with date. Very nice you do a setting > value. When I change following setting with src/orca/settings.py file, Orca > correct hungarian locale the date (year, month name, month day and week day), > my used value is following: > sayDateFormat = "%Y. %B %d, %A." > This is not good with portoguese users if we do an UI combobox to possible > replace the field orders? Guess creating interfaces to this complicates things. Date/time saying should be almost hidden for most users, just advanced people care changing the format, and usually that people can edit settings by hand... Anyway we have 2 options, use the localized date returned from python or make translators provide the format.... Don't really know what is better...
Review of attachment 159866 [details] [review]: Hi, In my opinion we shall not put String formating logic in scripts, guess that translators or users know how they want it on their messages. On another issue: you set the default setting for sayDateFormat to something specific for your locale, obviously it can't be commited that way.... I don't agree creating combo boxes to define time format or whatever format, think that it will just complicate user expirience like I said in my prev comment.
Created attachment 159950 [details] [review] This is similar to my first patch but uses the displayBrailleMessage call that was pointed by John. It applies without conflicts to current master, the first one doesn't apply anymore. This doesn't address the localization issue that was pointed out. It uses the %X and %x switches the, according to strftime, are the correct representation for date/time on the current locale. We must decide what to do: leave this for translators (explainning it in the comments, pointing to strftime docs), or another solution... I myself don't agree with complicating the code with removal of zeros and so on, it differs from language to language and it can be done with datetime formatting, I guess.
Unfortunately I have'nt got another ydea. I think impossible to do this feature with result proper all language outputs. When I change the time format setting with "%H óra %P perc %S másodperc" format ("%H hour %P minute %S second) in settings.py file, result correct hungarian output with hungarian Orca users like, but if any value is smallest with 10, very disturb the first 0 value with output message. Of course this is not your mistake. When I modify storm date and time spokening script with hungarian specific, I need handle this situations. Need handle the 0 problem if monthday first character is 0 with date spokening, and need handle the 0 problem if time values first character is 0. For example, when you would like hear normal speak the 08:24 morning time value, you spokening 08 or 8 number with first number? I am interesting only how works this with another languages. I think for example in english language the first 0 number is not spokened, english users spokening only 8:24 AM, but I am not full sure this. If you prefer %x and %X format because this format using current locale, have any ydea how can possible setting in locale setting if I not would like two digit format if the time value is smallest with 10? Unfortunately very important, hungarian time zone is 24 hour format, not 12 hour format. Or this is impossible to do without we handle this situation in this feature code? Please give hint, what we choice. Attila
What they do on the gnome clock applet is leaving strings for translation. In my modest oppinion this is the better way, at least we come with a solution for a problem that is more cosmetic then anything else. See for example: http://git.gnome.org/browse/gnome-panel/tree/applets/clock/clock.c?id=0d5840c1d7893100ac854738df1a7ff8d9d6cfb2 Around line 445. John, what do you thing of this? Atilla, from what I understood from your comments on the list you are happy with that but please confirm...
I', thinking about sepaparating the battery status feature from datetime announcing... Like I commented above It may impose more work and it is a different issue anyway. Shall I do it? I.G. create another RFE?
Rui, I not familiar for C code. What do this lines around with 445. line in clockapplet.c file with you linked? <a class='no' id='n333' name='n333' href='#n333'>333</a> <a class='no' id='n334' name='n334' href='#n334'>334</a> <a class='no' id='n335' name='n335' href='#n335'>335</a> I have got an ydea with resolving only the hungarian language the unneed 0 problem without absolute sure risk another language output, but I not full coded now, only the code my head now, need implementing my algorithm with monday: All two function need importing the os module, and need add following lines: #following code is important with only hungarian language right output sending. problematic0numbersstrings=["00", "01", "02", "03", "04", "05", "06", "07", "08", "09"] rightnumbers=["0", "1", "2", "3", "4", "5", "6", "7", "8", "9"] #if the locale is hungarian, need replace all problematic 0 numbers with normal numbers, othervise not need do anything now. if os.getenv('LANG')=='hu_HU.UTF-8': This part will be happen replace all problematic number characters with not problematical characters, but I now not coded this line. If we mark translation the two format related setting, and implementing my ydea, we do not risk another language output, do full translators customizable feature, and the feature give right result with all languages. Need this modification because hungarian users prefer textual format date strings, and one digit time values if the digits is smallest with 10. If this modification is coded, and for example in Orca translation I setting "%Y. %B %d, %A" setting with date format, I will be hear full right output in hungarian language: 2010. május 1, hétfő. You and Jon accept this modification? If yes, I begin coding monday if anybody not faster me. Tomorrow I not in home. Attila
Rui, yes, I agree this. Keep this bug with datetime feature, and create new RFE for battery status feature. Please subscrime me to new battery feature related RFE if this is possible. Attila
Hi, (In reply to comment #21) > Rui, I not familiar for C code. What do this lines around with 445. line in > clockapplet.c file with you linked? > <a class='no' id='n333' name='n333' href='#n333'>333</a> > <a class='no' id='n334' name='n334' href='#n334'>334</a> > <a class='no' id='n335' name='n335' href='#n335'>335</a> > Maybe I told the wrong line... I'm talking about this code: /* Translators: This is a strftime format string. * It is used to display the time in 12-hours format (eg, like * in the US: 8:10 am). The %p expands to am/pm. */ time_format = cd->showseconds ? _("%l:%M:%S %p") : _("%l:%M %p"); else /* Translators: This is a strftime format string. * It is used to display the time in 24-hours format (eg, like * in France: 20:10). */ time_format = cd->showseconds ? _("%H:%M:%S") : _("%H:%M"); > I have got an ydea with resolving only the hungarian language the unneed 0 > problem without absolute sure risk another language output, but I not full > coded now, only the code my head now, need implementing my algorithm with > monday: > All two function need importing the os module, and need add following lines: > #following code is important with only hungarian language right output sending. > problematic0numbersstrings=["00", "01", "02", "03", "04", "05", "06", "07", > "08", "09"] > rightnumbers=["0", "1", "2", "3", "4", "5", "6", "7", "8", "9"] > #if the locale is hungarian, need replace all problematic 0 numbers with normal > numbers, othervise not need do anything now. > if os.getenv('LANG')=='hu_HU.UTF-8': > This part will be happen replace all problematic number characters with not > problematical characters, but I now not coded this line. > I don't know if it is fair to put locale specific code in Orca... I don't agree with your aproach, sorry... Anyway I guess the locale module should have better functions to get the current locale. > If we mark translation the two format related setting, and implementing my > ydea, we do not risk another language output, do full translators customizable > feature, and the feature give right result with all languages. Need this > modification because hungarian users prefer textual format date strings, and > one digit time values if the digits is smallest with 10. If this modification > is coded, and for example in Orca translation I setting "%Y. %B %d, %A" setting > with date format, I will be hear full right output in hungarian language: > 2010. május 1, hétfő. Sure, but you are putting specific locale code in Orca code base... If we do that for every locale.... There must be a better way, I hope. > > You and Jon accept this modification? If yes, I begin coding monday if anybody > not faster me. Tomorrow I not in home. > I don't agree with your modification. I'm more inclined to leave the date/time formatting for translators.... John's aproach to padding zeros (%-h, %-m) does work for you? Rui > Attila
Separated battery status feature fomr this report. Key command to read battery status is now tracked at bug #617406
Rui, you are absolute right, thank you you not agree my ydea, because you and Jon ydea is better. Prewious time I not hear the - character with John suggested date and time format, because my Speech-dispatcher punctuation setting is setted with none punctuation setting. Following settings result full right hungarian time and date output and cut unneed 0 values: sayTimeFormat = "%-H óra %-M perc %-S másodperc." sayDateFormat = "%Y. %B %-d, %A." For example now the time output my machine is 7 óra 42 perc :4 másodperc. So, thank you the suggestion, works for me right. Only need mark translation the two date format setting, and need add an accepted shortcut with this feature. If this is happening, we ready this feature, I haven't got another problem with need fixing.
Created attachment 160123 [details] [review] Possible final patch with this feature. Rui, Jon, please look this possible final patch. I do following works: 1. Change the date and time script keybinding, date spokening is now Orca+d, time spokening now is Orca+t. Now I not see clean what keybinding would like more Orca users, if you want, feel free owerwrite the shortcuts. For example have an ydea to associate the date and time presenting function with one keystroke, for example Orca+t, first Orca+t press spokening current time, two quick press Orca+t presenting current date. 2. Marked translation with date format and time format settings with src/orca/settings.py file, but keep default Rui used %x and %X values. I add more description and examples for translators with format variables, but because my english is not full good, please to look this comments and feel free to edit or shortest if need. I haven't got another request to need fixing. If this patch is good, please commit. Now, when I insert translation file the we found right hungarian language correct time and date format strings, this feature absolute sure work right with hungarian language. I would like thank you your big patient. We doed a very nice feature. Attila
Created attachment 160148 [details] [review] Possible final implementation for time and date (another one) This is almost similar to attila's patch. Just changed the sayDate kyebing to orca+t (double click) wich seemed good for mailling-lists folks and we safe one orca+[key] combination for future use. Also clarified some stuff on the messages for translators. %x and %x are the defaults, even if translators don't butter we have good results for most languages. It seems with this everyone is almost happy so lets move along =)
*** Bug 617458 has been marked as a duplicate of this bug. ***
Rui, this patch is perfect. Attila
From comments I received on the mailling-list and privately it seems my last patch assigned keybindgs are good for the community. So, John, I guess it's ready to commit. It tested it already and works for me. Don't know what the process is, maybe I should tag this bug someway for review... :)... Regards, Rui Batista
<giving Rui a high-five> Way to implement a feature in the midst of some, uh, interesting discussions. Nice job! I just tried it in OpenSolaris and it works for me. So mostly what I've got are nits: 1. In Orca, we need to keep lines at less than 80 characters. You've got a couple of really long lines in default.py and a bunch more in settings.py. 2. The keybinding description for date begins with the word "present," but for time it's "presents". Like I said, silly nits. Nonetheless, please fix them. :-) The other thing that is kinda running through the back of my mind is: Do we want to find a way to make it easier for users to configure different formats themselves. For instance, you could do something in settings.py like: TIME_FORMAT_DIGITS = "%x" TIME_FORMAT_24_HOURS = "%-H:%-M:%-S" # Translators: Orca has a feature to speak the time.... # TIME_FORMAT_WITH_WORDS = _("%H hour %M minute %-S second.") <maybe a few other options here> sayTimeFormat = TIME_FORMAT_DIGITS Ditto for date formats. There are a bunch of examples you can draw from from within settings.py where we've done this sort of thing. As a general rule, we want the translators to translate English strings. This usually results in everyone getting the same thing, but in their language. What you've done here gives the translators a lot more freedom which might lead to some pretty different experiences from language to language depending upon what the translator did (or did not) decide to do. In addition, what *might* be the next logical step (as a new RFE, once your feature is committed to master) is consider how we can add this to the Preferences dialog. I think it would be cool to have a combo box which allowed the user to select the desired format from a list containing the sample date and the sample time as it would be spoken and brailled (i.e. in the local language of the user). In order to do that, we need a set of already-determined options; not a single translator-determined format. (Does this make sense?)
Joanmarie, this is a good ydea because do more flexibility, but I not understand a think with translator perspective: Now, you use following settings: TIME_FORMAT_DIGITS = "%x" TIME_FORMAT_WITH_WORDS = _("%H hour %M minute %-S second.") sayTimeFormat = TIME_FORMAT_DIGITS Clean, you marked translation the TIME_FORMAT_WITH_WORDS setting, but the sayTimeFormat setting factory value is the %x value with pass the TIME_FORMAT_DIGITS setting. For example if I translate the TIME_FORMAT_WITH_WORDS setting with hungarian correct "%-H óra %-M perc, %-S másodperc" format (need padding unneed zero numbers in hungarian language), the hungarian users hear this correct output if edit he's or she's user-settings.py file the sayTimeFormat setting and change the TIME_FORMAT_DIGITS value to TIME_FORMAT_WITH_WORDS value with hand. I see clean? Absolute to sure next step need do a combo box with choosing user want date and time format, for example if we put an example date format with date and time combo box with two items (TIME_FORMAT_DIGITS result output with first item, TIME_FORMAT_WITH_WORDS result output with second item), the users easy to toggle what output he or she want to hear and see the braille display. The combo box label value possible are: time format, date format. For example, when the user land the time format combo box, he hear following items if he or she press arrow keys for example in hungarian language: Time format: 14.25.25 User press down arrow key, he hear following change: 14 óra 25 perc, 25 másodperc. Thougs, Attila
Hi Rui, Just another small niggly thing maybe the functions should not be called sayTime, sayDate, but presentTime, presentDate, because say implies that it is spoken. If you fix this with the small nits that Joanie mensioned then we might be good to go. I get scared of 'fetch me a rock' exercises, so if you just fix these things, we can commit this as the first fix for this bug, and you can think about how to best present it in the graphical interface as a second part. Once you attach the new patch with the small corrections, i will test it on my machine and commit it for you. Thanks again for your time. -Jon
Just to be clear: I see these as three separate things: 1. Nits 2. The string to be used (e.g. the "%x") should not be left up to translators to decide what belongs there. Instead we should add several different string options. Anything that does not have English words in it should not be marked for translation. 3. We should add a combo box so that users don't have to edit items in user-settings.py or orca-customizations.py. Addressing item 1 before committing goes without saying. Unless you can provide me with what I'm failing to understand about why item 2 is flat-out wrong or a really bad idea, then I would very strongly suggest that item 2 be addressed prior to committing this patch. We'll deal with item 3 (as I indicated in my previous comment) as a separate RFE.
Ok, now full clear me. If Rui do your suggested changes, I do a separate enhancement RFE with combobox issue problem (issue 3). For example the second issue (free translatable time and date format strings is good for hungarian users. Attila
Created attachment 160269 [details] [review] Possible final patch, with containing last suggestions Joanmarie, I doed you and Jon requested modifications. 1. I do line wordwrapping, so now not have 80 character longer lines the code. I doed jon request to replace sayDate and saytime code parts with presentdate and presentTime parts. 2. I add you requested new settings. Before commit, in Date_FORMAT_WITH_WORDS setting need to change the wished format with english language sintax, now I add following format string: Date_FORMAT_WITH_WORDS = _("%Y. %B %d, %A.") With Time_Format_Words setting value is equals with you prewious wroted: TIME_FORMAT_WITH_WORDS = _("%H hour %M minute %-S second.") I hope only this work need you or Jon do. 3. presentDateFormat and presentTimeFormat settings is following: presentTimeFormat = TIME_FORMAT_DIGITS (%X value) presentDateFormat = DATE_FORMAT_DIGITS (%x value) I very hope I not forgot do a suggestion. Attila
I always forgot ask the following question: Now, normal working method with I not see the date and time script related settings in my user-settings.py file? When any final patch is committed, this is change? I very old time working with settings.py file and forgot how can working this if developers do a new not existing prewious setting. Attila
Jon, Joanie, need another work to do with related this feature? If yes, I welcome try solving suggestions if Rui not have enough time. Attila
Comment on attachment 160269 [details] [review] Possible final patch, with containing last suggestions Given some of the changes made in Orca (i.e. w.r.t. keybindings, message presentation, and the like) this patch is going to need to be updated.
Jon, I think this would be nice to have for 2.31.4. Therefore, I hope you don't mind that I'm assigning this one to you. Can you and Attila work on this to get something which is consistent with our new world order? Thanks!
Dear Joanie, This day I go to trawel my wife with the Balaton like with a little holiday with two week, and unfortunately I not have internet near with this time period. I awailable again after with june 28th. If Jon possible do your would like updates earlier, feel free to commit the finalized patch. Attila
Created attachment 163570 [details] [review] Fix for bgo#611576 - Present date/time. Thanks to Rui Batista and Hammer Attila. Hi Joanie, Does this look reasonable? Pylints to 10. Thank you.
Review of attachment 163570 [details] [review]: > Pylints to 10. Awesome. Did you test it thoroughly? In particular, the time formats? In addition, 'Date' should be in all caps here: +Date_FORMAT_WITH_LONG_NAMES = "%A, %d, %B, %Y." +Date_FORMAT_WITH_SHORT_NAMES = "%a, %d, %b, %Y." Also, a nit in this line (Trailing space being returned): + return "orca.settings.TIME_FORMAT_LOCALE "
Created attachment 163610 [details] [review] Fix for bgo#611576 - Present date/time. Thanks to Rui Batista and Hammer Attila. Thanks Joanie! <kicks>self once more for waisting Joanies time on these trivial corrections</kick>
Review of attachment 163610 [details] [review]: Aha. I see why you didn't change the time formats now. If I try it in Ubuntu things work as expected; this is not the case in OpenSolaris. In particular, the presence of the '-' flag in the format strings cause things to fail. :-( When I remove them things work as expected in OpenSolaris and seem to continue to work in Ubuntu. Is there a case where that flag is truly needed? If not, and we can nuke it, I think that would be the simplest solution.
Yes, I have no problem removing them. The way I understood the '-' was that it removed the leading 0. so if the time was 08:15, it would be 8:15. (It was Atilla that needed the leading zero to be removed, but since it doesnt seem to be cross compatible, then we dont have much of a choice). If i remove the dashes, should it be commited to master? Thanks.
(In reply to comment #46) > If i remove the dashes, should it be commited to master? Sure. Thanks!
Thanks, done :)