Only partial language change with setLanguage()

[atus]

setLanguage now works properly. The problem is that it does not use the whole localisation file. More precisely, everything until line 99 is reflected in the language change, anything beyond that is still English. This is tested with hr-HR and de-AT but is most probably be the same with all languages.

E.g., letzte Woche should return the same as last week, but it does not react to letzte or anything beyond that.

[abritinthebay]

That might be due to my recent refactor. In fact almost certainly is (as now those a strings are loaded in sections so if some sections are loading then it's a failure to correctly load that section).

Should be a quick fix

[atus]

Date.CultureInfo.regexPatterns looks like this:

Object {
add: /^(\+|(da)?nach(er)?|von|daher)/
amThisMorning: /(\d(am)? )(this )(morn(ing)?)/
apr: /apr(il)?/
aug: /aug(ust)?/
day: /^d|t(ag(e)?)?/
dec: /dez(ember)?/
feb: /feb(ruar)?/
fri: /fr(i(day)?)?/
future: /^nächste(r|s)?/
hour: /^h|st(d|unde(n)?)?/
inTheEvening: /( in the )(even(ing)?)\b/
inTheMorning: /( in the )(morn(ing)?)\b/
jan: /jän(ner)?/
jul: /jul(i)?/
jun: /jun(i)?/
longMeridian: /^(a\.?m?\.?|p\.?m?\.?)/
mar: /mär(z)?/
may: /mai/
millisecond: /^ms|milli(sekunde(n)?)?/
minute: /^mn|min(ute(n)?)?/
mon: /^montag/
month: /^m(onat(e)?)?/
nov: /nov(ember)?/
now: /^jetzt|sofort|gleich/
oct: /okt(ober)?/
ordinalSuffix: /^\s*(st|nd|rd|th)/
past: /last|past|prev(ious)?/
pmThisEvening: /(\d(pm)? )(this )(even(ing)?)/
sat: /^samstag/
second: /^sek(unde(n)?)?/
sep: /sep(t(ember)?)?/
shortMeridian: /^(a|p)/
subtract: /^(\-|(be|zu)?vor|früher)/
sun: /^sonntag/
thisEvening: /(this )(even(ing)?)\b/
thisMorning: /(this )(morn(ing)?)\b/
thu: /^donnerstag/
timeContext: /^\s*(\:|a(?!u|p)|p)/
timezone: /^((e(s|d)t|c(s|d)t|m(s|d)t|p(s|d)t)|((gmt)?\s*(\+|\-)\s*\d\d\d\d?)|gmt|utc)/
today: /^heute/
tomorrow: /^morgen/
tue: /^dienstag/
wed: /^mittwoch/
week: /^w(oche(n)?)?/
year: /^y|j(ahr(e)?)?/
yesterday: /^gestern/
__proto__: Object
}

which is mostly OK, I found a key in i18n.js that did not match: past: /last|past|prev(ious)?/ and will commit this now.

I am not sure where to look for the mistake, please take a look.

Also:

inTheMorning: "/( in the )(morn(ing)?)\\b/",
thisMorning: "/(this )(morn(ing)?)\\b/",
amThisMorning: "/(\b\\d(am)? )(this )(morn(ing)?)/",
inTheEvening: "/( in the )(even(ing)?)\\b/",
thisEvening: "/(this )(even(ing)?)\\b/",
pmThisEvening: "/(\b\\d(pm)? )(this )(even(ing)?)/",

is not included in any of the localization files

[abritinthebay]

Ah, yeah, those keys I've added recently - to add new parsing abilities and support for more formats.

You're on the cutting edge! ;)

If you add into the language JSON the correct "key": "translatedKey" format for those it'll pick it up however.

Technically the en-US is out of date due to the en-US format being the default (and the default key/value) now. Before release of 1.0 final I need to full document those changes.

[abritinthebay]

Ok, god.. the whole "last week" think really exposed why I hate the old parser.

Refactoring it now - but basically it bakes in the damn formats right now so that it won't freaking work when you change language. Will refactor it so it rebuilds them when the language is changed.

[atus]

About new keys and the current state of keys. Using the current scheme it is impossible to express the day before yesterday and the day after tomorrow for some languages. I can give you an example for German (all countries) and Croatian that have a single word for these terms: the day after tomorrow übermorgen prekosutra the day before yesterday vorgestern prekjučer You might think about introducing separate keywords for some terms like this. I?m not a language expert, bu I guess this could affect a lot of languages.

And about the default language.. My first thought is to kill the one or the other to avoid code duplication/hardcoding. I think the key groups could be extracted from the localization file for en-US that would be included by default in the package. When we're at that, it would be nice to group things in the localization files as well (for readability and )

yes its quite baked in :)

[atus]

tnx for the fix, will try it tomorrow

[abritinthebay]

Argh, that was fun. Relic of me trying to make the old system more dynamic.

Yeah, there are problems with natural language parsing that I'm not sure will be fixed without writing a full on Universal Translator ;) I may have to go with limiting that functionality for sanity's sake. However some examples like yours could work... will be a balance.

That said - yes, I think I'll pull the en-US + the new keys into a i18n-template.js outside of the core+i18n files folders. That way there is a canonical list of keys that people can base their translations from.

[atus]

Localization still sometimes fails partially even though the localization file was found and loaded in the networks tab and the Date.CultureString is properly loaded.

Go to http://jsfiddle.net/atus/b72Ut/show/ and type gestern or heute which is yesterday and today in German and it is clearly stated in the localization files but does not work. Instead it recognizes the English words. Same thing for Croatian jučer and danas which is yesterday and today.

month also doesn't work in any of the languages, as well as next week and previous week (DE: letzte woche nächste woche HR: prošli tjedan slijedeći tjedan) or month/year/etc. English works even though another language is loaded.

Could there be an error in the localization files? This problem shifts around sometimes, yet I was sure not to touch the key values. Or is it still the same error that you tried to fix here.

Btw, I am using the latest version of date.js that I built using your latest commits and the newest localization files for the demo link I provided. They are available on the fresh-build branch of my fork

[abritinthebay]

I probably missed one of the formats in the grammar parser so it's still baked in a few phrases.

Ugh. Will review.