L10n updates
Remove superfluous whitespace
Number parameters in message when two or more are used
ClientException and ServerException should end with a period
Original fixes in c169dcb5221cf3dd452c291bf97374bb459cc5b9; didn't get merged in 39cad55711 because the code had been broken out to another file, but manual merge went smooth.
These affect twitterstatusfetcher.php on all 32-bit installs and some 64-bit installs (depending on whether the version of the JSON library reads the large numbers as long or double internally). 64-bit bug is harder to see as it tends to manifest as off-by-one due to losing a bit of precision off the end.
We were checking the list as comma-delimited (per the description of it as comma-delimited), but in fact spaces are also accepted, and who knows what else.
Added StartRegistrationTry/EndRegistrationTry calls into those three, and moved the actual recording hook to EndUserRegister which is guaranteed to be called from User::register (so we don't need to worry about other auth methods forgetting to call the other UI-code hooks).
It seems to have actually been saving correctly, but the update of the colors on the form success page wasn't working properly.
When a design object is pulled out of the database, the numeric fields are read in as strings, so black comes back as "0".
But, when we populate the new object and then stick it live, we've populated it with actual integers; with memcache on these might live for a while in the cache...
The fallback code in Design::toWebColor() did a check ($color == null) which would be false for the string "0", but counts as true for the *integer* 0.
Thus, the display code would initially interpret the correctly-saved black color as "use default".
Changing the check to === against null and "" empty string avoids the false positive on integers, and lets us see our nice black text immediately after save.
We can make a lot of HTTP requests from the server side. This change
adds some configuration options for using an HTTP proxy, which can
cache hits from multiple sites (good for status.net-like services, for example).
We were passing DOM nodes directly into the queues for the final bookmark import stage; unfortunately these don't actually survive serialization.
Moved the extraction of properties from the HTML up to the first-stage handler, so now we don't have to worry about moving DOM nodes from one handler to the next. Instead passing an associative array of properties, which is fed into the Bookmark::saveNew by the per-bookmark handler.
