I am a design engineer at Friday, May 6th, 2011
Using Google Chrome locale files in Firefox extensions, updated
A generalized method that works in recent all versions of Firefox.
After I posted my latest revision to some code for using Google Chrome locale files in Firefox extensions, Wladimir Palant pointed out some shortcomings with the code; I’ve made some changes to address these issues, and the new code is shown below.
Usage
The new usage rules are as follows:
- Replace
MY_EXTENSION_NAMESPACEwith the namespace of your extension’s files. e.g., if your files are atchrome://abcdefg/content/, then replaceMY_EXTENSION_NAMESPACEwithabcdefg. - Rename
MY_EXTENSION_STRINGSto something that won’t interfere with another extension. - The
_localesdirectory from your Chrome extension should be in thechrome/content/directory of your Firefox extension (or update my code to point to wherever you put it).
Advantages
This code has four advantages over the previous versions:
- It’s a single code block that works with all recent versions of Firefox.
- You don’t need to include an additional library for file I/O.
- It fixes a bug in retrieving the proper locale code in Firefox on Linux.
- You don’t have to specify
<em:unpack>true</em:unpack>in your install.rdf in Firefox 4.
Thanks Wladimir for your input; this version is undoubtedly better than both previous versions. I can’t ensure that it’s the best possible solution, but it’s the best one that I’ve found so far.
May 7th, 2011 at 12:38 pm
Thank you, that’s better (though personally I prefer using “native” string formats both in Chrome and Firefox and converting between the two when packaging). A minor issue: I think that you either need to pass in MY_EXTENSION_STRINGS.strings in the last line or change the assignment into |string_object.strings[i] = messages[i]|.
May 7th, 2011 at 1:50 pm
You are correct about the MY_EXTENSION_STRINGS.strings issue; I’ve fixed it in the code sample.
This method definitely won’t be for everyone, but for ScribeFire, where 99% of the functionality is inside a single HTML webpage that is run in Firefox, Chrome, Safari, and Opera, choosing a single locale format and method for loading strings cuts way down on the complexity of localizing in each browser.
May 10th, 2011 at 10:09 am
Don’t know how to use this one but hoping to find any help..
May 10th, 2011 at 10:13 am
IT Rush: What specifically do you need help with? To use the code above, include it in your extension, and then call MY_EXTENSION_STRINGS.get(“string_key_foo”) to get the localized version of string_key_foo.
May 24th, 2011 at 3:22 pm
His problem isn’t using the code but rather making sure his spam comment isn’t removed…
May 24th, 2011 at 3:31 pm
I had a feeling, but I thought I’d give him the benefit of the doubt. Oh well.
Wladimir: Do you have any thoughts on this bug? https://code.google.com/p/scribefire-chrome/issues/detail?id=351 As soon as I switched to reading the locale files via XMLHttpRequests and chrome:// URLs, that guy says that it fails and he’s left with an un-localized interface.