Clean build and translation tools

[Trim]

Create a Makefile to replace build.sh script.

Remove unused translator update script as the Transifex will do the same (from en locale instead of en-us).

Note: this PR comes from a split of #70 with more tested Makefile (beautify target is ready to be used)

[Trim]

I've just added a commit to fix the exclude list: up to now, the .git directory wasn't correctly excluded and I had some 10 Mio xpi files generated. I remove the .tx file too which is not needed inside the extension itself.

PS: Github don't show here in the discussion page, but you can see it in the commit history.

[Trim]

I've added another commit to set the default target of the Makefile to be the simple build package target instead of dev which beautifies and builds.

[advancingu]

Wouldn't it be possible to execute transifex from a Make target? It would make building releases much easier for a maintainer when there are no manual commands needed other than launching the build itself.

[Trim]

Wouldn't it be possible to execute transifex from a Make target? It would make building releases much easier for a maintainer when there are no manual commands needed other than launching the build itself.

I think it would be possible but it will requires:

• for the release manager to install transifex client (and configure the credentials)
• for the Makefile:
  • to call the transifex client to update code
  • If differences exists, it will require too to create automatically a commit
  • with a "release" target we could even think about automatically adding a git tag to the branch
• Finally, the release manager will have to manually push the branch to the community repo (it will contains a commit for translation and a new release tag)

Does it make sense for you ?

[Trim]

Well, I've just added translation targets and release target.

Note, that the VERSION file will still require a manuall update before making a release as it's not easy to automatically increment a string like "4.0.0-beta4".

Note also that the Makefile defines a releasebranch variable to update too.
I except that later we'll use always the master branch to release as it will be really more convenient than having a branch by release and because we are already using branches to develop new features before merging.

[advancingu]

Looks like a typo.

[Trim]

The dash prefix is the way for Makefiles to say "execute this line and if you get an error, continue anyway the rest of the script".

Here, it allows us to continue the script even if nothing needs to be committed (the return value of the git command is non-zero if there was nothing to commit).

[advancingu]

Got to love Makefile syntax :D

[advancingu]

@Trim Release process sounds good for now. This is already much better than before. If there are still issues we can update it again later. Updating the version file is ok, too.

Once 4.0 is ready, I'd like to merge all this into master, yes. Release version branches don't make much sense for this kind of project at this time. Right now, branches are useful for feature development.

Code was correct.