Christopher Finke writes about software, woodworking, and other creative endeavors.

Using Google Chrome locale files in Firefox extensions, updated

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.

View the code at GitHub.

Usage

The new usage rules are as follows:

  • Replace MY_EXTENSION_NAMESPACE with the namespace of your extension’s files. e.g., if your files are at chrome://abcdefg/content/, then replace MY_EXTENSION_NAMESPACE with abcdefg.
  • Rename MY_EXTENSION_STRINGS to something that won’t interfere with another extension.
  • The _locales directory from your Chrome extension should be in the chrome/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:

  1. It’s a single code block that works with all recent versions of Firefox.
  2. You don’t need to include an additional library for file I/O.
  3. It fixes a bug in retrieving the proper locale code in Firefox on Linux.
  4. 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.

Posted

in

, , , ,

by

Christopher Finke

Tags:

Comments

6 responses to “Using Google Chrome locale files in Firefox extensions, updated”

  1. Wladimir Palant Avatar
    Wladimir Palant

    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]|.

    Reply
  2. Christopher Finke Avatar
    Christopher Finke

    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.

    Reply
  3. [deleted] Avatar
    [deleted]

    Don’t know how to use this one but hoping to find any help..

    Reply
  4. Christopher Finke Avatar
    Christopher Finke

    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.

    Reply
  5. Wladimir Palant Avatar
    Wladimir Palant

    His problem isn’t using the code but rather making sure his spam comment isn’t removed…

    Reply
  6. Christopher Finke Avatar
    Christopher Finke

    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.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Google+