Numbered parameters when more than one used in a message.
L10n updates for consistency.
i18n for non-translatable exception.
Updated translator documentation.
Removed superfluous whitespace.
FormNoticeXHR now is triggered on any form labeled with class 'ajax-notice', so those other than the traditional notice form should work as long as they handle the AJAX submission and return a properly formatted notice.
Things to watch out for:
* to determine whether the resulting notice should show on the current timeline, the JS code needs to be able to check the author and such. Keeping the existing vcard bits helps for this!
* the notice form submission stuff clears out inputs from your form -- test to make sure this behaves correctly
* error messages returned from the thingy _should_ come through, but this needs more testing for consistency
* while form components that aren't in a custom form should just be ignored, this should be tested more. (eg there's no location or attachment box for poll or bookmark plugins)
* NoticeListItem isn't currently reachable via autoloader -- touch NoticeList explicitly before calling into it for now.
Location information removed from translation files with msgmerge --no-location to decrease size of files and reduce diff size. Unfortunately there does not appear to be a setting in msgmerge or msgattrib to remove the extracted comments ("#.") from translation files. If you do know of such a switch, please let me know!
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.
delicious bookmark exports use the godawful HTML bookmark file format that ancient versions of Netscape used (and has thus been the common import/export format for bookmarks since the dark ages of the web :)
This arranges bookmark entries as an HTML definition list, using a lot of implied close tags (leaving off the </dt> and </dd>).
DOMDocument->loadHTML() uses libxml2's HTML mode, which generally does ok with muddling through things but apparently is really, really bad about handling those implied close tags.
Sequences of adjacent <dt> elements (eg bookmark without a description, followed by another bookmark "<dt><dt>"), end up interpreted as nested ("<dt><dt></dt></dt>") instead of as siblings ("<dt></dt><dt></dt>").
The first round of code tried to resolve the nesting inline, but ended up a bit funky in places.
I've replaced this with a standalone run through the data to re-order the elements, based on our knowing that <dt> and <dd> cannot directly contain one another; once that's done, our main logic loop can be a bit cleaner. I'm not 100% sure it's doing nested sublists correctly, but these don't seem to show up in delicious export (and even if they do, with the way we flatten the input it shouldn't make a difference).
Also fixed a clearer edge case where some bookmarks didn't get imported when missing descriptions.
I was trying to generate URIs for Bookmarks based on (profile, crc32(url), created).
I failed at that. CRC32s are unsigned ints, and our schema code didn't like that.
On top of that, my code to encode and restore created timestamps was problematic.
So, I switched back to using a meaningless unique ID for Bookmarks.
One way to do this would be to use an auto-incrementing integer ID. However, we've been
kind of crabbed out a few times for exposing auto-incrementing integer IDs as URIs, so
I thought maybe using a random UUID would be a better way to do it.
So, this patch sets random UUIDs for URIs of bookmarks.
