Dear Atilla,

Welcome back from holiday, hope you had a good time.

You want the date order to change?

Please give an example of how it is at the moment, and how you want it to be.

I think we agreed not to make these translatable because this would then leave a lot for the translators. Instead we provide diffrent formats and the user can choose between them.

As you can see from comment 9 for 621535, we already need a new date format string, Some users may prefer to have the month before the day of month. Is this what you want or is it something else.

Thank you.

Hy Jon,

Yes, relative good time in Balaton the holiday. The second week have more raining time, but we sleep more time, and go to walk longer distances with my wife and we little dog when the raining is stop. So, the holiday is very perfect. :-):-)

I not want change general the date shorter and longer word format output order (not want risk another languages output), but now this settings using following formats, with not good for hungarian language if the settings are not mark translation and not possible change the order only the hungarian Orca translation:
DATE_FORMAT_WITH_LONG_NAMES = "%A, %d, %B, %Y."
This longer date format resulting following date with not hungarian language right:
Kedd, 29 június 2010.
What means this:
This format resulting following order:
Week day name, month day number, month name, year.
In hungarian language, we first wrote the year, the month name, the week day number, and the week day name. So, need hungarian language this full different order with textual date format output.
For example, in hungarian language following date format resulting full right longer date format output, and cutting unneed zero values if the month day value is smallest with 10:
DATE_FORMAT_WITH_LONG_NAMES = "%Y. %B %-d, %A."
This format result following output:
2010. június 29, kedd.
Hungarian users usual not prefer the number style date formats (2010. 06. 29, 2010-06-29), but full right this format is awailable, because another languages use this format.

See the shorter word date format:
DATE_FORMAT_WITH_SHORT_NAMES = "%a, %d, %b, %Y."
This format order resulting following output:
K, 29, jun, 2010.
Similar with prewious longer format, following order is better with hungarian users:
%Y. %b %-d, %a.
The resulted output is following when this change is happened:
2010. jún 29, k.

I choose now this marking translation way, because the date order requirements is possible depending language to language. I not see another good choice to prowide absolute flexible date format localization way with text format date outputs and handle this situation. If we add more not marked translatable date format order type settings, possible difficultest longer time the maintenance. Marking translation is a better choice in this situation I think, but I absolute understand your comment this string translations is possible difficulter the beginner translators. But, for example if the translator not sure what the proper order, simple enough copy the original english type string and see the this resulted output good the proper localization or not. If the translator using for example the gedit editor to translation editing, and installing gedit-pomode plugin, Alt+C combination copy original english message to translated msgstr message part automaticaly.

So, if possible, please we use this translation way, or if this is impossible or not agreed, please add the date format settings this two wroted type setting and insert this settings with the future awailable date format combo box. Only one need important think, need use the - character with I wroted places in hungarian format.
Another adwantage result with the date word formats marking translation:
In future awailable date format combo box full language right wisible the sample date formats with word formats (longer and shorter formats), I tested this after I apply my patch and the combo boxes related patch.

What your openion, what we choose to handle this problem?

Attila

I think it might be best to simply add them as two new date formatting strings, along with the one that Joanie mensions in comment 9 to bug 621535.

so the work that is required is:

0. wait until 621535 is finished.

1-3 in settings.py:

1. correct:
"%A, %d, %B, %Y."
should be:
"%A, %d %B, %Y."

2. change the names of the constants so they are descriptive of the format:
instead of
DATE_FORMAT_WITH_LONG_NAMES = "%A, %d, %B, %Y."
maybe:
DATE_FORMAT_AdBY = "%A, %d, %B, %Y."
and:
DATE_FORMAT_WITH_SHORT_NAMES = "%a, %d, %b, %Y."
becomes:
DATE_FORMAT_adbY = "%a, %d, %b, %Y."

2. add american style short and long of:
"%A, %B %d, %Y."

3. add Hungarian style short and long of:
"%Y. %B %d, %A."
and 
"%Y. %b %d, %a."

4. in orca_gui_prefs.py:dateFormatComboChanged and
orca-prefs.py:update _getPresentDateString 
modify to reflect the changes done in the previous steps.

Hopefully Deepak is willing to take this one on when he is finished with the other one.

Jon, I agree this method. I have one question, you wroted:
3. add Hungarian style short and long of:
"%Y. %B %d, %A."
and 
"%Y. %b %d, %a."
Why not good replace your wroted value the %d part with %-d value? %-d producing problems? For example, with my Ubuntu systems this Python date format is working right, correct cuts the unneed 0 numbers if the month day is smallest with 10. So, the only difference with your wroted hungarian date format settings and me suggest setting with replace %d to %-d.
In Opensolaris, this format part producing problems?
If possible, the hungarian date format strings very need the %-d format part.

I have only one question in future, possible not need worry this, I don't no.
What can we do later if for example the Spanish, Poland, Chinese etc users would like different date format orders or different format settings? You always add the setting values, update the combo boxes, etc? This is possible not happening of course, but what happening if happen this? :-):-)
Or, in future awailable date formats possible enough more languages? I known only hungarian and english date schemas.

(In reply to comment #4)
> Jon, I agree this method. I have one question, you wroted:
> 3. add Hungarian style short and long of:
> "%Y. %B %d, %A."
> and 
> "%Y. %b %d, %a."
> Why not good replace your wroted value the %d part with %-d value? %-d
> producing problems? For example, with my Ubuntu systems this Python date format
> is working right, correct cuts the unneed 0 numbers if the month day is
> smallest with 10. So, the only difference with your wroted hungarian date
> format settings and me suggest setting with replace %d to %-d.
> In Opensolaris, this format part producing problems?

Yes it seems so, please see bug 611576, and particularly comment 45.
Because we try to keep everything as cross compatible as possible, it will be very dificult to accept '-' in format strings.

> I have only one question in future, possible not need worry this, I don't no.
> What can we do later if for example the Spanish, Poland, Chinese etc users
> would like different date format orders or different format settings? You
> always add the setting values, update the combo boxes, etc? This is possible
> not happening of course, but what happening if happen this? :-):-)
> Or, in future awailable date formats possible enough more languages? I known
> only hungarian and english date schemas.

Yes you are right, we would have an explosion of possible variations.
But the hope is that most people will find one of the included formats suitable for their needs.
Most of Europe I believe has the same prefered way of presenting the date.

Also dont forget, we are including the formally defined locale as an option too, so it shouldnt be such a problem.

Yes, cross compatible is important, I agree, but I very surprise the %-d type parts is not standard declared Python date format type? In Opensolaris, why producing this format problems? What Python version have in Opensolaris? In Ubuntu Lucid for example Python 2.6 have.
If we not mark translation with one date format with possible enable this flexibility with special localizations with this is need, we not have another choice, don't possible to use the %-d use, because in world more people using possible Opensolaris. What happen if we add a "custom" or "Translator determined" possibility in date format combo box?
For example, in Hungary blind users not using Opensolaris, using another Linux distributions with this change not producing problem, more users using Ubuntu based distributions.
For example, we marked translation correct the time word format strings, and I have possibility to use the %-H, %-M and %-S type value only with hungarian language translation with time format word strings without risk another languages and croscompatibility with Opensolaris with word wide with another languages.

Sure
Please just let mw know when the code is added to the settings.py file and i can deal with the Gui bit.
(In reply to comment #3)
> I think it might be best to simply add them as two new date formatting strings,
> along with the one that Joanie mensions in comment 9 to bug 621535.
> 
> so the work that is required is:
> 
> 0. wait until 621535 is finished.
> 
> 1-3 in settings.py:
> 
> 1. correct:
> "%A, %d, %B, %Y."
> should be:
> "%A, %d %B, %Y."
> 
> 2. change the names of the constants so they are descriptive of the format:
> instead of
> DATE_FORMAT_WITH_LONG_NAMES = "%A, %d, %B, %Y."
> maybe:
> DATE_FORMAT_AdBY = "%A, %d, %B, %Y."
> and:
> DATE_FORMAT_WITH_SHORT_NAMES = "%a, %d, %b, %Y."
> becomes:
> DATE_FORMAT_adbY = "%a, %d, %b, %Y."
> 
> 2. add american style short and long of:
> "%A, %B %d, %Y."
> 
> 3. add Hungarian style short and long of:
> "%Y. %B %d, %A."
> and 
> "%Y. %b %d, %a."
> 
> 4. in orca_gui_prefs.py:dateFormatComboChanged and
> orca-prefs.py:update _getPresentDateString 
> modify to reflect the changes done in the previous steps.
> 
> Hopefully Deepak is willing to take this one on when he is finished with the
> other one.

Since I am DayJobbing today, I'm afraid I'm going to have to be brief:

1. OpenSolaris uses Python 2.6.

2. I really do not think it is a good idea to mark these strings for translation.

3. If there is a way to give Attila the string he wants by adding it to the new options, please do so.

Thanks!

Jon, because Joanie not would like mark date word format strings for translation, I have got an ydea, but I don't no possible easyest implementing or not for hungarian or another date word format settings related:
Not possible to add a setting value with toggling %d or %-d format values for date word format strings, and the user possible choice what want with unneed 0 numbers? For example, the setting name is possible "cuttingunneed0numbers", and the default value is of course false, because we would like prowide default cross compatibility with Opensolaris if we not possible found why not working in Opensolaris the %-d and %-D format part.
If this setting is false, Orca need sending your wroted date format string for example the new add hungarian date formats, but if this setting is true, need sending my suggested values. This is little difficulter to do, but not producing incompatibility possible with Opensolaris, because more language users possible not toggling this setting with true, only need toggling this setting with true for hungarian users if not want hear and see the braille display with unneed 0 number for example the following textual generated date:
2010. július 1, csütörtök
If this setting is false, the sent date is following:
2010. július 01, csütörtök.
If this setting is true, the sent final output is following:
2010. július 1, csütörtök.

Created attachment 165075 [details] [review]
This patch add Jon suggested date formats

Jon, Deepak, please look this patch!

I do setting name changes and need date format editing with Jon suggested, add american date format svariants, add try do following change with hungarian date format related:
I do a new setting in src/orca/settings.py file:
"leading_unneed_zero_with_month_day"
This setting default value is of course False, because need provide default crosscompatibility with Opensolaris. This setting use only hungarian date formats string now, if this setting is true, I do a following if case in src/orca/settings.py file:
if leading_unneed_zero_with_month_day == False:
    hungarian_DATE_FORMAT_AdBY = "%Y. %B %d, %A."
    hungarian_DATE_FORMAT_adbY = "%Y. %b %d, %a."
else:
    hungarian_DATE_FORMAT_AdBY = "%Y. %B %-d, %A."
    hungarian_DATE_FORMAT_adbY = "%Y. %b %-d, %a."
So, if this setting is false, the hungarian date format using %d value and not cutting unneed 0 number with month day if the value smallest with 10, this is croscompatible with Opensolaris. If this setting is true, the hungarian date format using %-d value, not %d, and removed unneed 0 number if the month day smallest with 10.
I do required modifications with another part of codes to known the date format combo box the new or renamed settings, and store right the new preferences.
But, I have a problem, please give hints, possible I forgot a step if we absolute not want mark translation a date word format string:
When I manual change the "leading_unneed_zero_with_month_day" setting value with True in src/orca/settings.py file, hungarian date format month day part is proper changed %d to %-d, but when I change this setting value only with .orca/user-settings.py file, the change is not happened. Possible I forgot a step?

Have an another alternative:
Because the code begin little big, we keep the five builtin added date format, and do one translatable date format with last format. If you accept this, not need do extra difficult setting handles (want unneed 0 values or not), because the last date format is translatable, I possible do the %-d change only the hungarian translation file and not need risk crosscompatibility with another languages in Opensolaris. I ask one enable translatable date format if this is possible, because in present time part the word formats is default enabled translatable. In hungarian users only need the longer date format string, and translators need translate one date format if not good the builtin formats with a special language.

Just a moment, I show a next patch what can I would like.
If the date format translation with only one date format is not acceptable, we need found why not working the leading unneed 0 preference.

Attila

Created attachment 165076 [details] [review]
This patch add american date formats, but provide one translatable date format

Alternative version of prewious patch.
This patch containing prewious doed setting related changes, containing new american related date format, and prowide one translatable date format with year. month month day, week day name format. The english translatable message not using %-d format type, so, this is Opensolaris compatible if the translator not want use the %-d flag.
I have'nt got another ydea what date format type containing the original translatable english message. Have a missing date format with possible replace the original english message with I added?

I removed this alternative version the unneed0 related setting, because if have a translatable date format, not need do this extra working mehanishm.

You are accept this method?

Attila

Created attachment 165078 [details] [review]
This is the right version of second alternative patch

Soffy, when I do git diff operation, I forgot remove after operation the hu.po file changes in second patch.
This is the right version, code parts is not changed.
Please look if you have a little time.

Attila

DONE

Deepak, Please be careful about closing things unnecessarily. The work for this bug has not been done and has not been accepted, so should not be closed.

Please look through the work that Atilla has done and we can discuss on how to proceed.

Jon, I not remember now, my last patch not owerwrite with Joanmarie already doed date format fix with extra comma's?
I see now morning following fix:
commit 2bdad9e9f5005ad8d4d5bef51355d90072499b18
Author: Joanmarie Diggs <joanmarie.diggs@gmail.com>
Date:   Fri Jul 2 12:20:58 2010 -0400

    Fix for bgo#623414 - Orca's date format strings contain an extraneous comma

I think you wroted this need do work in this bugreport, but this is already fixed now with Joanie.

Hi Attila, yes Joanie fixed that for us, so that we could commit bug 621535.

Yes, I see yesterday, thanks the commit, this is easyest now the remaining works.
Can you write me a list what can need do now with this related bugreport with next patch?
Absolute clean need remove my last patch next week monday or tuesday the orca-setup.ui part, but what can need keep with settings.py related my patch without destroying Joanie fix?
My setted english and American date format strings compatible with Joanie doed string format with comma related fix?

Attila

Created attachment 165231 [details] [review]
Proposed patch

While I really, really love all the contributions from the community, I'm looking at the release schedule.... The Orca team has always done it's best to get UI and string changes in prior to the "announcement" period. I think we should continue that practice. And we've got a week until the announcement period for this cycle. :-/

So....

The attached adds thirteen additional date formats, including three with the year first, then the month, then the day as described by Attila.

It is pylinted, tested in both the current dev release of OpenSolaris and the current Ubuntu Maverick.

Created attachment 165255 [details] [review]
Little modifyed patch

This patch absolute based of Joanie sent patch, but I little modifyed following date settings the punctuation characters with proper hungarian language grammatical rules:
Original defined settings is following:
DATE_FORMAT_FULL_YMD = "%Y, %B %d, %A"
DATE_FORMAT_ABBREVIATED_YMD = "%Y, %b %d, %a"
New, hungarian language right settings is following:
DATE_FORMAT_FULL_YMD = "%Y. %B %d, %A."
DATE_FORMAT_ABBREVIATED_YMD = "%Y. %b %d, %a."

I hope accept you this change and this punctuation sintax change is not conflicting another european language sintax with using this two date format. If we this is not sure, and if this is possible happening because Joanie you sure not want use dot after year when you doed this two setting I think, need mark translation with this two date format (paste an _( markup of this two setting only), because hungarian language absolute sure need this sintax with language right speech output and braille message output, but I don't known another european language with using this type date format good this settings with hungarian grammatical markup sintax or not.
How can we handle the %d and %-d problem for this two setting only or entire date formats? If we want proper hungarian or possible another language right textual date output, need handle this problem anyway (number date formats unneed 0 values is not problem), only need handle this problem with textual date formats.

Attila

Comment on attachment 165231 [details] [review]
Proposed patch

I committed this patch, modified to add the two periods to each string specified by Attila in comment 19.

http://git.gnome.org/browse/orca/commit/?id=2f491b93606e7b1b82efde480b10c95c60f907ce

Review of attachment 165255 [details] [review]:

To be honest, my initial reaction was "Surely Hungarians are not that precise with their punctuation." But then I googled a bunch of Hungarian newspapers, and I'll be darned if they didn't all have those periods. So, alright, alright. Attila is correct; I am incorrect. <huge, silly grin> If other Europeans have a problem with it, then we'll deal with it. Or they can manually customize their string.

On a reviewish note:

If you're making a minor, proposed change to a patch, it's easier to spot the changes and review if you provide a patch for the patch. Then, if your changes are accepted, I can just apply the first patch, apply yours on top of it, and then push both. In other words, in the future -- at least for stuff you and I are working on together -- I'd prefer something like this:

diff --git a/src/orca/settings.py b/src/orca/settings.py
index f556250..88d3206 100644
--- a/src/orca/settings.py
+++ b/src/orca/settings.py
@@ -1531,12 +1531,12 @@ DATE_FORMAT_FULL_DM = "%A, %d %B"
 DATE_FORMAT_FULL_MD = "%A, %B %d"
 DATE_FORMAT_FULL_DMY = "%A, %d %B, %Y"
 DATE_FORMAT_FULL_MDY = "%A, %B %d, %Y"
-DATE_FORMAT_FULL_YMD = "%Y, %B %d, %A"
+DATE_FORMAT_FULL_YMD = "%Y. %B %d, %A."
 DATE_FORMAT_ABBREVIATED_DM = "%a, %d %b"
 DATE_FORMAT_ABBREVIATED_MD = "%a, %b %d"
 DATE_FORMAT_ABBREVIATED_DMY = "%a, %d %b, %Y"
 DATE_FORMAT_ABBREVIATED_MDY = "%a, %b %d, %Y"
-DATE_FORMAT_ABBREVIATED_YMD = "%Y, %b %d, %a"
+DATE_FORMAT_ABBREVIATED_YMD = "%Y. %b %d, %a."

Make sense?

(In reply to comment #19)

> How can we handle the %d and %-d problem for this two setting only or entire
> date formats? If we want proper hungarian or possible another language right
> textual date output, need handle this problem anyway (number date formats
> unneed 0 values is not problem), only need handle this problem with textual
> date formats.

Please open a new bug for it. Because the issue there is that different operating systems treat that string differently. So I'll need to dig deeper into it. Thanks!

I'm closing this bug as FIXED because we now have a BUNCH of options for Present date.

Created attachment 165257 [details] [review]
Keep Joanie doed two prewious modifyed setting, but mark translation this twosetting

This patch keeps Joanie doed two prewious described modifyed settings, but marked translation this two settings. Because not possible sure guarantee the prewious hungarian specific modification modifyed settings is compatible with another languages with using this date format sintax, but hungarian language absolute must need using this modifyed sintax, I choose this way and another european translators possible write proper grammatical sintax with own languages without destroiing another languages and possible do full grammatical right textual date string with own language. If have a language with need using for example the %-d format directive and not good the %d value, have translator are free to use this directive, but we need do a warning in translator comment with this setting are possible resulting not crosscompatible with Opensolaris and this is the translator risk.

If you accept this change, not need do another tasks, and we done this bug. For example not need do extra toggles to handle %d and %-d date type toggle.
Because in time formats have two translatable formats, I think not disturb translators this two translatable date formats. See following time related translatable messages with already awailable correct:
#. 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:1507
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:1514
msgid "%H hours and %M minutes."
msgstr ""

If you not agree the translation markup ydea, I full understand, but if this is possible please do a toggle with the user possible choose want %d or %-d type output, because for example hungarian users absolute sure need the %-d type format text output. For example, I developing only hungarian blind users an accessible Ubuntu based distribution with similar the Vinux distribution. If not possible fix this problem, I need do extra method with a special orca-customizations.py file or another way to fix this problem only this special distribution, if possible, I not would like this method to hide this problem. :-):-)

Joanie, thanks the commit.
I doed %d and %-d related bugreport in bug 623571.

Attila