I've added R18n support to use locale date formats. This includes a _locale/ folder that can be used to define the date_format and long_date_format. In the future this could also be used for other translations.
Two new configuration parameters have became available:
Last: the default format used in tests (27 Jan 2011) is changed into 10/01/2010. It might be useful to include a _locale/en.yml by default?
Added locale date support using R18n
Added ability to define date_format and long_date_format in _locale/<…
Is there a reason why this changes the current default date formats? I'd prefer if it kept the current behavior and made other formats possible with additional configuration.
No... the format used is now system default. I can imagine it could include a default _locale/en.yml with a prefixed date format. Shall I create one and add it to this pull request?
Any news on this guys? I translated my blog into German and hoped to find some kind of "Locale-Setting" - the only thing I found was something for Octopress here.
The ability to generate dates in a language other than English seems rather useful to me. Is there any actual argument against this?
I'd be happy to review this again. We cannot change the output for the default locale for each of those filters (backwards-compatibility is key), but there's no apparent reason we can't offer them in other locales. As long as reading the locale YAML is safe, then we should be good to go.
To be honest, I don't understand why it doesn't do this already. The code that's changed in this pull request includes a call to strftime(), which ought to do the right thing ... but doesn't. A bit of googling tells me that someone decided that Ruby's strftime() should be locale-independent, though I'm unable to find why on Earth that is.
@mattr-, what do you think of this? It's a great idea, but adds a lot of complexity that the user has to manage.
I'd love to support different languages on GH Pages without pre-generating locally, but I still need to thing more on the way it should be done. For one thing, the format of the current output cannot change, so that will have to be reverted here.
As mentioned awhile ago, I don't like the change in the default date formats either. I'm sure I'm just being shortsighted here, but I'm struggling to find cases where this added complexity (by default) is something that we'd want.
That being said, there are a couple of things that could be done to improve this pull request:
This should be enough to keep the easy things easy and make the hard things possible. 😃
@rvanlieshout, do you agree to @mattr- above comment? It would be nice to have this in jekyll 😄
I do agree with @mattr-. It would be wrong to mess up things for 99% of the users only to satisfy that other 1%. I'll try to make those adjustments soon if nobody else already made them by that time :)
This can be closed for the same reason of #1652. 😃