1="[Exception..." 2="Component" 3="returned" 4="failure" 5="code:" 6="0x80004005" 7="(NS_ERROR_FAILURE)" 8="[nsIStringBundle." 9="<div" id=":sd" 10="class="ArwC7c" 11="ckChnd">GetStringFromName" language="Error:"]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: XStringBundle :: getString :: line 17"  data: no] Source File: XStringBundle Line: 17</div>

Googling gave me some clues but still nothing obvious to solve the problem. At first I thought it has something to do with the non-ASCII characters, so I did a binary-replace on the property values, but still no luck. It’s only after I cat-ed the file then I noticed an empty space before the first property key. This empty space turned out to be a weird character that didn’t show up on Eclipse text editor, gedit, and vi.

I still don’t know what that character is. Here’s what Eclipse compare editor showed when I compared the cleaned up line with the original line, notice the non-ASCII character before monitor.init property key.

And BuildMonitor speaks French after that character is removed. Parlez-vous anglais?

Update (20/11/2008): This problem kinda irked me, so I investigated it further.

The weird character is actually the ISO-8859-1 character for UTF-8 byte-order mark. It seems like XStringBundle expects ISO-8859-1 property file, hence interpreting the BOM as part of the monitor.init property key.

A handy tool to inspect the BOM is octal dump, where you should be able to see EF BB BF hex at the beginning of the file. And instead of manually cleaning up the property key, I should’ve used native2ascii.