GNOME Bugzilla – Bug 623571
Use %-d format directive, not %d, for non-numeric date format strings
Last modified: 2010-09-20 10:57:02 UTC
Dear Developers, In present date feature the time.strftime function now using the %d format directive with generating month day date part with textual dates. General, more languages this is not problem, but if the month day is smallest with 10, this function sends the month day with two digits number (first digit is 0), this is producing language grammatical problems with some languages, for example hungarian language newer using textual dates with this type form if the month day is smallest with 10, we writing one digit number the month day. The main problem, the Python date formats are have a method to handle this problem automaticaly with cut unneed zero values with this situation if have before a format directive a dash character, but this is unfortunately not crosscompatible with Opensolaris now, I don't no why. In Opensolaris and Ubuntu Lucid for example have Python 2.6 version. See for example following now not mark translatable setting in src/orca/settings.py file: DATE_FORMAT_FULL_YMD = "%Y. %B %d, %A." DATE_FORMAT_ABBREVIATED_YMD = "%Y. %b %d, %a." This settings are main compatible with hungarian language date textual output, but for example if the month day between 1 and 9, this format using two digit numbers the month day description. For example, if I choose the full year. month monthday, week day format in Date format combo box, Orca spokening and send following hungarian language grammatical incompatible date output with braille display with this date day: 2010. július 05, hétfő. The full right date text output is following in hungarian language: 2010. július 5, hétfő. Now, I not have possibility any central method to toggle I want %d or %-d format with date text generation output. The alternative fixes are following for example this two date type settings: 1. Mark translation this two date setting, and european translators are absolute need the %-d format, not %d with date textual output, have a translation free, but need known the translators this %-d format way is unfortunately incompatible now with Opensolaris. This is the simplest way fix, and the risk only the translator with using %-d format directive, depending blind users using Opensolaris or not with the country. For example, in Hungary blind users not using Opensolaris, using Ubuntu or Ubuntu based accessible distributions or another Linux distributions with this format directive are not incompatible. For example, in textual time formats are already translatable, and the translators are possible to choose want using the dash characters before the hour, minute and second format directives if want. See following messages: #. Translators: Orca has a feature to speak the time #. when the user presses a shortcut key. #. This is one of the alternative formats that the #. user may wish to be presented with. #. #: ../src/orca/settings.py:1503 msgid "%H hours, %M minutes and %S seconds." msgstr "" #. Translators: Orca has a feature to speak the time #. when the user presses a shortcut key. #. This is one of the alternative formats that the #. user may wish to be presented with. #. #: ../src/orca/settings.py:1510 msgid "%H hours and %M minutes." msgstr "" In Hungary, for visual impaired users I developing an Ubuntu based accessible distribution. If we not found a central way to handle this problem, I need do an orca-customizations.py script to handle this problem and use the %-d format directive to send the date format output if this is possible, but this method only hidden this problem, but not fixed main. I better prefer central way fixes and full integration, not want do and not want see local patched gnome-orca package with my PPA repository for example with owerwrite this two date setting in src/orca/settings.py file, this is unacceptable me, because this way fix is only hidden the problem and do extra work with Orca package maintenance when a new maintenance version is publicated. :-):-) See the Python date format alternatives: http://docs.python.org/library/time.html#time.strftime 2. The second way fix is more difficulter: need do a setting with toggle the %d or %-d date format part use with sent output generation if the developers not want using translation markup fix and not acceptable this translation markup fix way, but the first fix way is simplest.
Created attachment 165258 [details] [review] Demonstrate patch for translation markup way fix This patch marking translation the two described date format setting. I fraid developers is unacceptable this change, but this fix way is working sure and easy handle the problem with translator choice. Attila
Created attachment 165283 [details] [review] I forgot add translator comments with prewious marked translation settings Prewious I forgot add add translator comments with marked translation date settings and forgot add a note to warning translators with Opensolaris incompatibility with %-d value. Attila
Joanie, I have only a question if you have little time: Good me doed second fix with committing, or need your openion more working me with this problem fix because unacceptable the marking translation method with this Opensolaris incompatible warning note with translator comment? Of course, I agree if you don't want accept this translation marking fix way. Attila
Review of attachment 165283 [details] [review]: Thanks for this patch Attila. But I would really prefer not to put these strings in the hands of translators. Instead, I would really prefer to find the right string for all environments, or instead make the string based on detecting the OS. I also do not think that this issue is a big deal. The string should be spoken correctly even with that extra space present (right?). If so, the "bug" is the presence of one, single space character, noticeable only in braille, only if you check the date and only that date happens to item with a single digit. As such I consider it a nit rather than a full-fledged bug. What you propose, on the other hand, could make it an actual bug by breaking the date feature for that string for any OpenSolaris user using a locale in which the translator decided to change the string.
Ok, thank you the answer, I accept we not use translation marking method fix way. I have got an ydea to detect OS type, with possible compatible with Opensolaris: What result shows you in Opensolaris the uname -o command? Have uname command in Opensolaris? I not known Opensolaris base commands. Uname -o shows following information with my Ubuntu system: GNU/Linux But, I don't known, all locale need the %-d format with longer and shorter textual date formats, if the operating system is Linux? Possible no. I have got another ydea, with possible relative easyest to do, but the specification now not full: Easy to get current locale with os.getenv('Lang') command. Need do a list, with stores need locales, with need the %-d variable in date formats. When we process current locale environment, we need only for example the first two character, for example, hu. If the locale is present the exception list, easy to replace the DATE_FORMAT_FULL_YMD and DATE_FORMAT_ABBREVIATED_YMD stored setting values with %-d type format. Now stored this two setting with user preferences? Before I try begin coding another choosed type fix way, your openion what fix method are better (now not full the specification) and full compatible with Opensolaris?
Created attachment 165856 [details] [review] Another fix way to solving the problem Joanie, please test with this last patch, I wroted following commit message: "This bug fix are define in src/orca/settings.py file with date_exception locale list. The added exception languages are automaticaly get %-d type format directive with following Orca date format settings, if the used operating system is GNU/Linux: DATE_FORMAT_FULL_YMD, DATE_FORMAT_ABBREVIATED_YMD For example, hungarian language are typical need this format modification, if the month day is smallest with 10, need cutting unneed first 0 number. Now the list containing only hungarian language." I tested this modification my Ubuntu Lucid system. If I using hungarian language, I automaticaly see right textual date formats with this two setting. Please test this patch your native language under Opensolaris and Ubuntu, and if possible, look what happening if you using Opensolaris, and switched temporary hungarian language. The code possible little complex, not full elegant possible, but working. If you have easyest handle ydea to switch on the fly the %d and %-d formats, please write me and I try coding. Before I examining the used operating system, I set original setting values (not %-d format part use), I think this is not disturb Opensolaris.
Well, Oracle may have solved all this for us. I knew they'd help out eventually. <bitter smile> In particular, they've decided to discontinue OpenSolaris. [1] Even I do not feel the need to ensure compatibility with non-existent distros. I'll take a look at this tomorrow as today has been a rather long day. [1] http://mail.opensolaris.org/pipermail/opensolaris-discuss/2010-August/059310.html
Joanie, I very sorry. What happening future with Orca development? Orca development is still opensource development with future? If I understand right, GNOME and X11 specific development is still opensource development, but my english is not full good. I very surprised this binary distribution modell with Solaris Express distribution. So, because not need look prefer the compatibility with Opensolaris if I understand you right, good method the marking translation fix, or simple we change the %d values the %-d format with required two date format? Attila
(In reply to comment #8) > Joanie, I very sorry. What happening future with Orca development? It's going to continue on, alive and well, just like it has been. Before we had a Sun team plus me (a volunteer). Now we have a team of some guys from Spain (including Ale Leiva) and me (a volunteer). > Orca development is still opensource development with future? Of course it is. > english is not full good. I very surprised this binary distribution modell with > Solaris Express distribution. Well, that is Oracle for you. Fortunately, Oracle does not control Orca. We control Orca. My point was that, up until now, it was my goal to ensure that Orca worked with Linux *and* OpenSolaris. Part of that was due to the fact that Orca exists thanks to Sun, and the "right thing to do" is continue to ensure that Orca is compatible with Sun's operating system (even if Sun no longer existed). The other reason I wanted to do so is that I honestly believe that OpenSolaris is (or was) better than Linux. I was an OpenSolaris user by choice. Not because anyone made me be one. Anyhoo.... The bottom line is that OpenSolaris doesn't exist. Solaris will come out when Oracle sees fit to release it. And external people (i.e. us) have no access. As a result of that, I consider things like the '%-d' issue "not our problem." If for whatever reason '%-d' causes a problem for Solaris users, then Oracle can fix the problem however they would like downstream. Mind you, given that the source of our new team members, the Consorcio Fernando de los Ríos, has provided support to ensure that Orca works well with the Spanish distributions Guadalinex and Guadalinfo, we have a certain obligation to ensure that Orca remains compatible with those distributions. However, that should be really easy to do because Guadalinex and Guadalinfo are based on Ubuntu. So if it works in Ubuntu, it should work in Guadalinx and Guadalinfo. (Though we'll always check to be sure.) > So, because not need look prefer the compatibility with Opensolaris if I > understand you right, good method the marking translation fix, Hehehe. Marking for translation is a bad idea in my opinion, and that has not changed. <smile> Translators should translate; not make decisions on what the user should see. Marking this string for translation puts them in a position of making a decision about what the user should see. > or simple we > change the %d values the %-d format with required two date format? Bingo. Like I said, if that works for Linux, anything else is not our problem. Make sense/is clearer now?
Created attachment 167900 [details] [review] proposed fix Attila, give this patch a try please and let me know. Thanks!
Joanie, yes, now clean. I tested your patch. Works very well, please commit. This patch resolve this bug. Attila
Thanks Attila! Done: http://git.gnome.org/browse/orca/commit/?id=bf1934db4b43b33ce885d6523d8b736656609e17