Globalize.js failing with E_MISSING_BUNDLE even though CLDR is loaded

I am using Globalize.js loading the CLDR for the de-CH in the following manner:

$.when(
    $.get('/json/cldr/likelySubtags.json'),
    $.get('/json/cldr/timeData.json'),
    $.get('/json/cldr/de-ch/numbers.json'),
    $.get('/json/cldr/de-ch/ca-gregorian.json')
)
.fail(function (xhr, status, error) {
    console.log("Problem loading globalization data: status: " + status + ", error: " + error);
})
.then(function () {
    // Normalize $.get results, we only need the JSON, not the request statuses.
    return [].slice.apply(arguments, [0]).map(function (result) {
        return result[0];
    });
})
.then(Globalize.load)
.then(function () {
    try {
        // Globalization is loaded
        Globalize.locale('de-ch');
        console.log("after locale");
        console.log(Globalize.parseDate("5/20/2018"));
        console.log(Globalize.parseDate("20.05.2018"));
    } catch (ex3) {
        console.log(ex3);
    }
});

The browser shows that the four .json files were correctly loaded. I can also confirm that by adding a breakpoint in the first .then call. However, I still get this exception when parseDate is called:

Error: E_MISSING_BUNDLE: {"locale":"de-ch"}
    at createError (cldr.js:328)
    at validate (cldr.js:344)
    at Cldr.main (cldr.js:654)
    at dateExpandPattern (date.js:109)
    at Function.Globalize.dateParser.Globalize.dateParser (date.js:1788)
    at Function.Globalize.parseDate.Globalize.parseDate (date.js:1837)
    at my.js:210

When I check the error at date.js:109 it calls:

result = cldr.main([
    "dates/calendars/gregorian/dateTimeFormats/availableFormats",
    skeleton
]);

So it is looking for main -> "dates/calendars/gregorian/dateTimeFormats/availableFormats" which I can find in the .json file for de-CH.

The above example (and hence functions and line numbers) use globalize 1.0.0. I updated the package to 1.4.0 and the .json files to the most current ones and only the function names and line numbers in the stack trace changed, the effect is exactly the same.

Any ideas what the problem is?

I found the problem: Globalize.locale('de-ch') fails while Globalize.locale('de-CH') works, so the case of the locale name is important.