Bugs of new Calendar Features in 1.x

[orchardbot]

@mehranrezaei created: https://orchard.codeplex.com/workitem/20562

I tried new calendar features in 1.x branch. There are several bugs. For example about Persian calendar:

I tried to create new page. The format of Persian date is in wrong order such as "25/12/1392". It must be "1392/12/25"

In front-end, Month name is not correct. It shows translation of Georgian month name instead of Persian month name because the following line of code: return localDate.Value.ToString(format, cultureInfo);

For example i see "دسامبر" that is translation of "December". But in Persian, last month of year is "اسفند".

Also popup calendar has very bad localization.

[orchardbot]

@DanielStolt commented:

Thanks for reporting this.

There is a bit of an oddity in .NET Framework when it comes to the PersianCalendar specifically - it is NOT considered the default calendar of the fa-IR culture.

So first thing to make sure: have you specifically selected PersianCalendar as the configured site calendar in settings? "Use culture calendar" is not enough, because of the above peculiarity.

[orchardbot]

@mehranrezaei commented:

Yes, I selected PersianCalendar as the configured site calendar in settings. Calendar feature has some bugs now. But, Thanks a lot for implementing this feature. I hope that see bug free calendar features in future. Calendar features is very very very important feature.

[orchardbot]

@DanielStolt commented:

OK, good, just wanted to check that.

As to your feedback then:

1. If you think this formatting is incorrect, you should take it up with Microsoft. :) This is how the dates are formatted in the fa-IR culture, and I have never heard anyone say it's incorrect. See the attached screen shot for proof.
2. Yes, this is a problem when formatting dates based on a non-gregorian calendar with a format string containing names. In the calendar picker this is handled - it has a dedicated localization package per calendar. But when rendering dates for viewing in the front end this is not handled. Can you give an example of where this happens?
3. This localization is provided by the calendar picker as shown here: http://keith-wood.name/calendars.html#l10n You should consider contributing a better localization if you think there are problems with the supplied one. I really can't tell the difference as I don't know a word of Persian (except "moosh bokhoratet").

[orchardbot]

@mehranrezaei commented:

Persian date has only one correct short format. "yyyy/MM/dd". ex. "1392/12/27". Persian Calendar is one of the best (or the best) calendar that has multiple precision, Therefore i can suggest you reading more about it and its correct format. I said you about correct format and you said "I have never heard anyone say it's incorrect." I will not say to Microsoft because I will heard same as your reply.

Anyway, Thank you so much for your reply.

[orchardbot]

@DanielStolt commented:

I'm afraid it won't help if I read up on it. :) I can do all the reading in the world, and you can convince me that your preferred format is the correct one, but it's not up to me. All formatting is done my the .NET Framework - if MS implemented it wrong, there's no much I can do.

I should not have said "I have never heard anyone say it's incorrect" though, I admit. It's hardly relevant, since I haven't really spoken to many that would have an opinion. But I did ask a Persion friend of mine now, and she agrees with you.

So you should make a Facebook protest action against the .NET Framework team's decisions. :)

Did you have any additional information regarding #2?

[orchardbot]

@mehranrezaei commented:

I don't speak about preferred format, I said about the usable format for Persian Calendar. Persian Calendar has only one format. This is preferred for all Persian people. Your talk is not correct. If Microsoft implements wrong, you must implement your own or using other method. Using wrong implementation is not useful if usability is important for you.

About #2: I think we can use another way to format for Persian culture until .NET corrects its implementation. The ToString() method is not localization now. It is translation only in current implementation.

You can read more about Persian (Jalali) Calendar here: http://en.wikipedia.org/wiki/Iranian_calendars

[orchardbot]

@jasper-d commented:

I doubt that Decorum has to do anything. Why don't you submit your own pull request, if you care that much.

[orchardbot]

@DanielStolt commented:

Mehran,

Usability is important, but a clean implementation is also important. Adding code to do special formatting for specific hard-coded cultures would make the implementation significantly more messy.

But like Jasper says, if you think you can address this in an elegant and generic way, feel free to submit your own pull request.

[orchardbot]

@sebastienros commented:

@Decorum, this is why we had the format in the .po files.

[orchardbot]

@sebastienros commented:

But isn't there an interface so anyone can override the default behavior, I think I remember something like this ...

[orchardbot]

@jasper-d commented:

The old LocalizationDatetimeFormatProvider (enabling localization of dates through .po files) is still there, but now part of the localization module (see 9f2a9b0). And there is the IDateTimeFormatProvider interface allowing completely custom localization logic.

[orchardbot]

@DanielStolt commented:

Yeah, don't know why that didn't occur to me!

@Mehran: To elaborate on what Sebastien and Jasper say, you have some options:

1. Enable the Orchard.Localization.DateTimeFormat feature and provide any date formats you want through .po files.
2. Provide your own implementation of IDateTimeFormatProvider, providing any date formats you want.
3. Provide your own implementation of IDateServices (possibly inheriting from the default implementation DefaultDateServices and just overriding what you want to change) if you want to take complete control over the date/time localization process.

@Sebastien: IIRC before my PR the old .po-based localization of formats was actually only employed for localizing the client side formats used for the jQuery UI Datepicker but not for server-side localization. Now the abstraction of this (IDateTimeFormatProvider) is used for everything.

[orchardbot]

@mehranrezaei commented:

Thank you for your solution. But i have no problem my self because i can convert date in theme simply or writing my own implementation or .... I become happy when i saw new calendar feature. Integrated features are better than private implementation because those have lower cost for maintenance. Also i think calendar is very important core feature that must be usable out of the box. I reported this issue because i think all lovers of Orchard are not developer. They cannot solve these problems themselves. I tried to make better internal functionality. I think Sebastien said correct approach about using .po files. Also i tried several times to contribute for Persian Orchard localization but after creating account, cannot log in and use it.

[orchardbot]

@mehranrezaei commented:

Another bug:

I select "28/12/1392" for Created On and save page content item. After save date has been changed automatically to "12/28/1392". an if you try to save again you can see the following error message:

'12/28/1392 07:14 AM' could not be parsed as a valid date and time.

[orchardbot]

@DanielStolt commented:

@Mehran: I will try to reproduce this, but can I please ask that you move it to a separate issue? I am closing this one as "be design" now. Open the additional issue separately and I will take a look at it.

[orchardbot]

@DanielStolt commented:

\ Closed by Decorum 05/17/2014 11:09AM

[orchardbot]

@DanielStolt commented:

This has now been fixed for the upcoming 1.9 release. More information here: https://orchard.codeplex.com/discussions/560347