Calendar localization while using custom language

[trendspotter]

The jQueryUI timepicker and datepicker modules are lacking localization for languages not officially supported by SE, even though the proper i18n JavaScript files exist.

The cause seems to be in s3widgets.py on lines 2030 and 2398 as they are trying to look up a value from date_formats dictionary and if the current language is not present there, the internationalization is simply ignored even though settings.L10n.date_format may be set properly.

I see two ways out

1. Add all remaining languages for which there is an i18n JavaScript file to date_formats dictionary.
2. Make date_formats dictionary configurable in similar fashion like the languages are.

I'd be happy to provide a PR for the first one, however the second one might be more systematic (and tricker), so that's why I'm opening it as an issue first.

[nursix]

Ahm...

current.deployment_settings.date_formats is customizable - you can override the class property with an instance property in your template's config.py:

settings.date_formats = {"cs": "%d.%m.%Y"}

...or, if you just want to extend it:

date_formats = dict(settings.date_formats)
date_formats["cs"] = "%d.%m.%Y"
settings.date_formats = date_formats

But of course you can also extend the default set with more languages if you like - although as I see it, you only need one particular language, right?

[nursix]

Btw - the language file for Czech is also still missing. Why not put that in a PR too?

[trendspotter]

override the class property with an instance property

Well yes, but it generally didn't seem as a good idea. Or maybe I just don't understand why this particular dictionary is separated from the others (eg. languages) and put up high in the config files where it feels like it's something too important to be touched.

you only need one particular language

True, but when I'm already in it, I can also be nice to other geographical minorities.

the language file for Czech is also still missing. Why not put that in a PR too?

We're not there yet. Lot of translations need polishing and checking (or czeching? :) ) and some are still missing. Mainly from places where the T() function is not used explicitly and the strings are not returned using the translation interface. But yes, eventually, one day, you'll see the glorious 10K lines PR for this.

[trendspotter]

Neither

settings.date_formats = {"cs": "%d.%m.%Y"}

nor

date_formats = dict(settings.date_formats.items())
date_formats["cs"] = "%d.%m.%Y"
settings.date_formats = date_formats

worked for me in my template's config.py, so I'm gonna go ahead with creating the PR adding into s3cfg.py dict.

[nursix]

Yeah, you're right - it's not really meant to be "customized". You can not add just any arbitrary format here, but can only "translate" into Python the ones that are already there in the calendar locale-specification files.

And to that end, indeed, it's incomplete - we have always only added the ones we needed, and as we needed them, which was good enough for our purposes. My apologies that we didn't take your locale into account.

But adding it seems easy enough, and if you want to complete it for other locales too, then great - make sure the "translations" match the JS specifications, so that they don't clash.

[nursix]

Indeed, you need to

object.__setattr__(settings, "date_formats", {"cs": "%d.%m.%Y"})

...in order to override the date_formats property, which is, like I said, because it's not really meant to be customized. It is "possible" to override it, but not really the idea here as it needs to match the calendarPicker specifications.

So, I think adding cs to the S3Config specs is the right way forward.