Refactor SocketIORouter
Fix authorship sanitization

author colors wouldn't get disttributed, if their id was greater than 9
(due to apool encoding them to base 36)
IE8 complains, if catch block is missing
IE8 don't knows the Array.forEach function (simple version fix)
use document, not doc
Merge pull request #1750 from ether/fix/authorship-once-and-4-all

Fix authorship sanitization
fixed spacing
Just a missing character
Merge pull request #1754 from goldquest/patch-1

Just a missing character in README
Localisation updates from http://translatewiki.net.
Issue #1625: Fix to client-side-induced changeset spamming.

THE BUG - HIGH LEVEL:
- When client A sends out an attribute change, client B applies that change to itself but
  also thinks that it made the change itself, which is incorrect. This means that when client B
  next makes a change, he will send out that he made the attrib change that A actually made.
- Ex: Have 2 clients on the same pad. Have A apply bold on some text. Next, have B type a character.
  B will broadcast that it both added a character AND applied bold, when in reality it did NOT
  apply bold at all, that change was done by the other client and this client incorrectly adopted it as its own.
- This root bug behavior results in clients continuing to think that they each made the other client's change,
  thus resulting in an infinite loop of changeset spamming that bogs down clients and harms server stability.

THE BUG - IN DEPTH:
- The root issue is in the way that Changesets are combined in Changeset.follow(). Specifically, in the case of a
  changeset with ONLY new attrib changes (no text changes) being merged with an identity changeset (has no ops).
- In this case, Changeset.follow() copies the ops of the new CS and fully overrides the other CS.
- applyChangesToBase invokes Changeset.follow to determine the final client document CS state after applying the new CS.
  If the final client document CS state is NOT the identity CS, then the client broadcasts that it made a change.
- When client A changes just attribs, client B's applyChangesToBase calls Changeset.follow() and passes client A's
  changeset (attrib change) and Client B's current changeset state (identity).
- As per the noted bug, Changeset.follow() returns client A's changeset as a result, causing client B to adopt
  client A's changeset as its own document state. Thus, client A ends up thinking it has made client B's changes.

THE FIX:
- Changeset.follow() should NOT copy the ops of the new CS passed in if those changes are only attrib changes.
  This allows applyChangesToBase to properly set the client's CS back to the identity after applying an
  external attrib change, instead of incorrectly adopting the external client's changes.
Add a server-side changeset queue per pad

fixes #1573
Localisation updates from http://translatewiki.net.
Merge pull request #1760 from bemeric1/develop

Issue #1652: Fix to client-side-induced changeset spamming.
Merge pull request #1740 from ether/feature/add-cs-queue

add a changeset queue
Let travis use sauce labs key of the etherpad user
Merge pull request #1770 from ether/feature/travis_fix

Fixed sauce labs key in travis config file
Merge pull request #1751 from goldquest/dev_IE8-fix

Fixing IE8 errors