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.
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]|.
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.
Don’t know how to use this one but hoping to find any help..
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.
His problem isn’t using the code but rather making sure his spam comment isn’t removed…
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.