What it actually does on import is:
- clones or updates the appropiate Mercurial repository
- parses l10n.ini files to build the en-US directory with files to localize
- if the project is not Firefox, copies the required translation files from the associated Firefox project
- builds a languge pack
- runs compare locales and interprets the output to build Narro links to the contexts with errors or warnings
You need the mercurial path to the proper repository. Common options are comm-central, comm-aurora, comm-beta, comm-release and mozilla-central, mozilla-aurora, mozilla-beta, mozilla-release.
You need to specify the internal application type, browser (Firefox), suite (Seamonkey), mobile (Fennec/Firefox Mobile), mail (Thunderbird), calendar (Sunbird).
Also need the release name, this is empty for central, aurora, beta or release. This is used to find specific l10n.ini files, e.g. l10n-aurora.ini.
If the project is Seamonkey, Sunbird, Thunderbird or Fennec/Firefox Mobile, then you need some folders from Firefox, that's why you need to do this association here.
It makes no sense translating dom and toolkit folders again if you already did that in Firefox.
Now here's how the export page looks after an export, if the Mozilla Build plugin is activated:
You can see at the bottom the output of compare locales, with a link to the text to correct.
Also, you can see the xpi language pack as well.
What's happening in the background is quite complex and very platform dependent (Fedora/Centos/Debian/Ubuntu only supported).
You need to have make, autoconf-2.13, python, easy_install installed on the server.
But the result is quite amazing, since you can get an xpi language pack directly from the browser, no Mercurial, no build commands, no terminal, just the browser.
I'm currently converting all l10n.mozilla.org to use this plugin, so expect possible problems today.