Feature Request: Do not translate RegexPatterns or provide a fallback system for English

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use any translation
2. Your code gets invalid if the translated RegexPatterns does not match the 
ones you used when you were coding, so it delivers null

ex. Date.parse("sunday") will work in English, but with Spanish becomes invalid 
and delivers null.

What is the expected output? What do you see instead?
Expected output: a valid date
Instead: null

What version of the product are you using? On what operating system?
Alpha-1 / WinXP

Please provide any additional information below.
Regex Patterns should work the following way:

1.- use English Patterns
2.- if null then use the current language patterns

Original issue reported on code.google.com by cor...@aldomx.com on 13 Dec 2010 at 6:34

[GoogleCodeExporter]

This is basically a multi-language design mistake, more variables than the 
needed ones were translated, more examples:

English: Date.parse("2010-09-08") = 8 September 2010 = OK
Spanish: Date.parse("2010-09-08") = 9 August 2010 = NO

English: Date.parse("today") = 13 Dec 2010 = OK
Spanish: Date.parse("today") = 13 Dec 2010 = OK
Spanish: Date.parse("hoy") = null = OK, expected

English: Date.parse("next sunday") = 18 Dec 2010 = OK
Spanish: Date.parse("next sunday") = null = NO
Spanish: Date.parse("next domingo") = 18 Dec 2010 = :/

Original comment by cor...@aldomx.com on 13 Dec 2010 at 6:57

[GoogleCodeExporter]

The new language system I've implemented *should* do this (it defaults to 
English if there is no key present). That said - it will still use a translated 
one if it is there... and won't try to go to English if a translated one 
exists. It will only use English if no regex exists - which it does AFAIK in 
all the files.

It isn't particularly practical to always include English, though I could make 
that an option I suppose but it would double the running time of all the 
parsing functions which is less than desirable for an edge case (the library 
makes the assumption that the language you load is the one you are using 
internally too).

Here's the github issue on my fork for this. Please update me there if you feel 
the new builds don't solve this issue for you. 
https://github.com/abritinthebay/datejs/issues/114

Original comment by darkcr...@gmail.com on 15 Sep 2013 at 7:36