Page MenuHomePhabricator

UploadWizard: date picker needs to adapt to user locale settings
Closed, ResolvedPublic

Description

It always assumes that weeks start on Sundays, which is not the case in many cultures and therefore will be confusing to many people.

More on the issue: http://en.wikipedia.org/wiki/Monday#Position_in_the_week


Version: unspecified
Severity: normal

Details

Reference
bz24604

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:10 PM
bzimport added a project: UploadWizard.
bzimport set Reference to bz24604.

neilk wrote:

Actually we made sure this calendar widget is properly internationalizable in this way. We just didn't write the bit to make it conform to your MediaWiki user settings yet. Patches welcome, but it's on our TODO anyway.

I added a note in our tasklist to update this bug later.

http://www.kelvinluck.com/assets/jquery/datePicker/v2/demo/datePickerLocalised.html

Maybe for now you could change the date format displayed in the date filed? I think semi-ISO (Y-m-d H:i:s) would be better then something containing words in foreign language. Also I find current format confusing because I was not sure if it is going to be displayed like that later or will it be ISO or whatever.

neilk wrote:

It seems there is a preference in MediaWiki for time format, but there is none for calendar locale. This will have to be added.

Google Calendar does not obviously prefill these... they have independently settable characteristics:

Date format (ISO 8601, MM/DD/YYYY, YYYY/DD/MM). MediaWiki has this already

Time format (irrelevant for us since we're not showing time... yet) MediaWiki has this already.

Week starts on (Sunday, Monday, Saturday). MediaWiki does NOT have this.

In some cases a good guess for start-of-week can be inferred from the interface language, but this is fragile.

neilk wrote:

Pulling this out of UploadWizard 1.0, deferring to 1.1.

The displayed date format has been changed to ISO (yyyy-mm-dd). This addresses Nux's suggestion, but not the original bug.

I think the best solution would be to use datapicker's localization options based on user language.

Actually it looks like this bug was fixed back in November.