Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

i18n support and different date formatting #12

Closed
wants to merge 12 commits into from
Closed

i18n support and different date formatting #12

wants to merge 12 commits into from

Conversation

mwidmann
Copy link

Hi,

I added support for international date formats and a dictionary to translate the strings in order to be able to use the timeline on a German portal.

I didn't want to add too much overheat and therefore i extended the VMM.master_config object with the i18n collection.

@mwidmann
Copy link
Author

I found two additional issues regarding IE in conjunction with google docs as datasource.

  1. Cross-Site requests must be targeted to the same schema which means that https xs-requests give an access denied error when called from an http site. See this post on Microsoft blogs. I changed that to a protocol relative url
  2. as there is no built in support XDomainRequest, I added support for it. I need to check this approach which would be far more elegant

@mwidmann
Copy link
Author

mwidmann commented Apr 2, 2012

The problem only surfaced in IE9. The URL needs to be on the same scheme as the calling page, therefore http for a http page, https for an https page. This is why I chose @paulirish's approach of the protocol relative urls.

Sadly I found out later that protocol relative urls seem to either break jQuery.ajax calls or there's some issues in Chrome's handling of it all. that's why I needed to re-add the https scheme to the VMM.getJSON call.

@gregwebs
Copy link

hi guys! I like how this is going with the user modifying a configuration for their own language. I am wondering if it is necessary at all to have date parsing be internal to this library. Rather than expecting the user to give a string, why not expect only a date object? Otherwise the user can register a string -> Date function. Certainly the library could keep a very simple date parser on hand.

@mwidmann
Copy link
Author

Making a free-format string out of the date object would make many tasks performed automatically (generating the helper timeline at the bottom, calculating an interval that makes sense, sort the stuff by date when the editors are too lazy) almost impossible.

This whole setup stuff for a language is a thing that in most cases needs to be done just once and then just copied over when inserting a new timeline.

@gregwebs
Copy link

@mwidmann, I didn't read the code correclty. I am advocating only using a date object internally. Users are expected to give date objects or provide a date parsing function. But your patch is actually for the printing of dates and seems appropriate.

@zachwise
Copy link
Member

Just added language support. Documentation is coming.

@zachwise zachwise closed this Apr 22, 2012
LauraHilliger pushed a commit to LauraHilliger/TimelineJS that referenced this pull request Oct 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants