R18n support for locale date formats #386

wants to merge 2 commits into


None yet

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:

  • locale (default: 'en')
  • translation_path (default: File.join(Dir.pwd, '_locale'))

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?

mojombo commented Sep 1, 2011

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?

pattulus commented Sep 6, 2012

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.

ndrluis commented Nov 7, 2012

+ 1


@parkr parkr closed this Mar 8, 2013

The ability to generate dates in a language other than English seems rather useful to me. Is there any actual argument against this?

parkr commented Jun 1, 2013

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.

@parkr parkr reopened this Jun 1, 2013

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.

parkr commented Jun 30, 2013

@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.

mattr- commented Jul 1, 2013

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:

  • Add additional functionality that does nothing if there is no _locale directory. This means that for 99% of the people that don't use this feature, nothing changes for them.
  • Update the site documentation in site on the master branch.

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. 😃

@mattr- mattr- closed this Oct 28, 2013
@jekyllbot jekyllbot locked and limited conversation to collaborators Feb 27, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.