User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33 Build ID: 20150308222025 Actual results: Calendar header in the "week" or "several weeks" view states: Failed to read 'dayIntervalInMonth' from chrome://calendar/locale/calendar.properties Shoud display the date (range) instead. Error console output: Zeitstempel: 13.03.2015 11:38:19 Fehler: Failed to read 'dayIntervalInMonth' from chrome://calendar/locale/calendar.properties. Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.formatStringFromName]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://calendar/modules/calUtils.jsm -> file:///C:/Users/sam/AppData/Roaming/Mozilla/SeaMonkey/Profiles/qj73qw1n.sam/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calUtils.js :: calGetString :: line 667" data: no] Quelldatei: resource://calendar/modules/calUtils.jsm -> file:///C:/Users/sam/AppData/Roaming/Mozilla/SeaMonkey/Profiles/qj73qw1n.sam/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calUtils.js Zeile: 673 Ligtning 3.8b2 / Seamonkey 2.33

I've took a look on l10-central and it seems there are a lot of locales that missed the new strings from the patch for bug 1073922. These are the locales that still have old strings in calendar.properties such as: dayIntervalBetweenYears -> http://tinyurl.com/mlnp4ad dayIntervalBetweenMonths -> http://tinyurl.com/od6ba9d dayIntervalInMonth -> http://tinyurl.com/nvhfzc2 more or less, based on the presence of old strings, there are: bg, bn-IN, ca, cy, da, en-GB, et, eu, fi, fr, fy-NL, ga-IE, gd, he, hr, hu, is, ja-JP, ja, ka, ko, lt, nb-NO, nn-NO, pa-IN, pt-BR, pt-PT, ru, si, sl, sq, sv-SE, ta-LK, tr, uk, vi

l10n-central is not used by many localizations. Some localization teams work on l10n-mozilla-aurora but most teams work only on l10n-mozilla-beta. We do have known problems with broken localizations in Lightning 3.8 Beta 1, see Bug 1133663. Maybe Beta 2 did not removed all broken localizations. Stefan, what localization do you use?

Ok, I was able to reproduce the problem with 3.8b2 and a German Thunderbird build. Failed to read 'dayIntervalInMonth' and 'dayIntervalBetweenMonths'.

I've taken a look in the 3.8b2 and it seems there is only the German locale with wrong strings in the calendar.properties file i.e. the strings introduced by the patch for bug 1073922 that instead is not yet included in the 3.8b2: daysIntervalBetweenYears daysIntervalBetweenMonths daysIntervalInMonth

(In reply to Decathlon from comment #4) Gnah, how annoying. AFAIR that was one of the bugs I had to wipe out from 3.8b1 because their l10n-patch took the wrong train (too early). I'm sorry these leftovers slipped through. Unfortunately I have no idea how to fix this now / what is worth the effort.

Based on my test above this only affects display of the header of the week and multi-week view. No functionality seems broken. Therefor I would just wait and retest when Lightning 3.9 Beta will be available for Thunderbird 37 / SeaMonkey 2.34.

Its up to you, Robert. If you want I can spin another build with fixed strings, or you do what Stefan suggested. I'd suggest running compare-locales over the localization to make sure all strings are translated.

I second ssitter's comment and would prefer to not spin another build. Days are hectic and I don't want to risk additional accidents. Will start testing 3.9b1 candidates instead. I run compare-locales quite often, but right now my setup just considers default/tip of the various repositories - that's not of much help for this bug. I'll think about a script for other use cases.

Ok, sounds good. I've uploaded 3.9b1 to AMO now, lets hope it worked!

Just FYI: I just stumbled over it in T'bird 38.6.0, Lightning 4.0.5.2. I was in a multiweek view when I noticed the error message in the title bar. I hit the Week tab, then found I couldn't get back to Multiweek. After a moment of panic, I restarted T'bird, and the message went away; I couldn't reproduce it.