Only pass string substitution values
Even though you could, at one point, pass integers as substitution values to
chrome.i18n.getMessage, you cannot do this now. A
bug was opened when this "number or string" functionality was broken, which caused me to investigate the actual API docs on the matter. The docs clearly state that the substitutions should be...
string or array of string substitutions
Even though, the bug looks like it will be fixed and "number or string" functionality will be restored, it's not a good idea to pass numbers. This issue broke Better History in Chrome Dev as I was not parsing dates as strings, so watch out!
Refreshing your locale files
You don't need to restart the browser or reinstall your extension to have your locale changes picked up. Nope, just disable and enable your extension to pick up any locale changes.
If you want to change the browser's locale, you will need to restart Chrome after you change the language preference for your operating system.
Just because your extension works locally does not mean it will work on the Web Store
It's true, let those words sink in for a moment.
The tips below only relate to the Web Store when you are uploading your extension. If you do not follow these tips, you will see a useless error message like the one below then you upload your extension...
An error occurred: Message JSON file must be in UTF-8 encoding.
So be sure to follow everything below or else you'll be pulling your hair out.
No comments in your locale files
Although your extension will install fine locally, it will be rejected by the Chrome Web Store if any locale file contains...
// a comment like this
It will fail the UTF8 validations that your extension is only subjected to when uploading to the store.
No byte order mark (BOM) in your locale files
This should be a no brainer because the
BOM is not recommended in UTF8, but this got me. You can check for the BOM in your locale files by running the following in the command prompt...
> file _locales/en/messages.json
_locales/en/messages.json: UTF-8 Unicode (with BOM) English text
No improperly encoded character anywhere
Be on the lookout for strange characters, missing characters, or miss matched symbols because anything like that will result in a validation error on the server. I had to comb through all 19 locale files to fix one, little character.