I guess this one will be a lot harder to fix ... The RSS validator complains when the front page has two occurrences of the same URL. I don't know if that can be easily solved ... Either don't put the link in the "rdf:about" field, or somehow make each occurrence unique? (Or maybe just link to the actual entries in the RSS feed. I've been sort of annoyed that it doesn't work that way by default, but chances are I'll regret wishing for this. :-)

mieses: Not within your control, obviously, except you could try to rephrase the offending entries See also http://de.lirio.us/rubric/entry/2636, by mieses. My own bookmarks also contain an error; the RSS feed I see in Firefox for the "live bookmark" ends with the last entry before the error. Now that mieses has an error already in the first entry (unescaped ampersand in title), his/her/its feed is completely empty. Update: Rubric 0.08 contains fixes to RSS parsing.

When you've copied a link, you end up looking at your own bookmarks We speculate that just adding &when_done=go_back to the end of the URL would fix it. ... Nope, didn't work. So I guess it requires a software fix. Update: As a workaround, use tabbed browsing (as if anybody who is serious about bookmarks wasn't already doing that).

The de.lirio.us pages always have a horizontal scroll bar Even if I maximize the browser on my 2048x(mumble) hot shot monitor, the horizontal scroll bar is still there. Scolling right does not reveal any new information. This is with Firefox 1.0.7 on Ubuntu 5.04, for the record. As far as I have been able to tell, this occurs with all de.lirio.us pages except "help"

Clicking "expand" on page 2 takes you to an expanded view of ... page 1 See also http://de.lirio.us/rubric/entry/4204 and http://de.lirio.us/rubric/entry/2533

If like me you routinely deny cookies without thinking about it, you can't log in I already sent Steve email about this but I figured I'd list it here too. To repro, turn off cookies altogether (including removing any cookies you aready have for this site), then attempt to log in. At a minimum, you should get some sort of diagnostic, perhaps suggesting that if you are blocking cookies, you should not. (Maybe check if the referring page is the same you are landing on.) Alternatively, since this is probably most likely to happen to first-time visitors who are deciding to register even though they weren't planning to, perhaps you could diagnose this earlier in the registration process -- try to set a cookie on the Register page, then if it's not set when you have submitted the registration and get the info page about the verification ticket having been sent to you by email, There Be Trouble. Perhaps still more to the point, what's the use of attempting to set a cookie already when you visit the front page? It's not like it's going to be used for anything until you attempt to register, is it? (Just speculating here, though.) Me, I reject any cookie anybody requests unless I see a real reason to accept it. That would be, for example, if I've just clicked on a link to register with the site.

I think copying an item should copy more or less the entire entry Removing or revising the text you don't want to keep is easy; not having it within view makes things cumbersome -- in the worst case, you do the "back button - select - copy - forward button - select - paste" routine three times in order to copy over the description, the tags, and the body.

Any #fragment part disappears from the URI when you copy an entry The link is to an entry which features a #fragment so you can try to repro with that. (Dang, looks like the entry view doesn't have a (copy) link. Welp, now that we have search, search for "CSS: a tabbed interface" http://de.lirio.us/rubric?like=css:+a+tabbed+interface and pick the oldest hit.)

Apparently, any non-UTF8 input will simply be discarded without warning The referenced entry is supposed to contain the letter lower-case a with a circle on top ("Swedish o", "Angstrom"). I was not able to enter this with my current input locale. The body I had typed in was simply discarded, and Rubric looped back to displaying the input form again (with other fields left intact). At the very least, there should be a warning indicating why this is happening. Fortunately, I was able to get back my original form input by pressing my browser's Back button, and I was able to massage it into a form which was accepted as valid input. (Good thing I had just viewed the Rubric Changelog, which gave me a clue about what was wrong.) Update: This may or may not be a browser setting bug, too. In Firefox, selecting View > Character Encoding > Unicode (UTF-8) seems to help. Caution: Switching forces a reload of the current page. If you are on a form, you'd better copy the data in the form because it might disappear. When editing an entry, if you insert a non-UTF character, pressing Save gets you back to the input form with the unedited entry in the form. Again, the Back button at least in Firefox seems to get back the old data, but copying the current form data to the clipboard is probably always a good precaution. Update too: I am no longer able to trivially repro catastrophic errors, but maybe I am more cautious and/or maybe my understanding of this problem has improved or gotten worse or whatever. Something could have changed with the Rubric 0.10 update, too.

As the site grows, it will be increasingly useful to be able to focus on languages you understand Ideally, the site would be able to supply a meaningful default guess for every field, and a user preference for which languages to display and/or suggest. See also the Accept-Language HTTP header. Gertjan van Noord's TextCat is a fairly popular Perl-based language identification module. (It's not actually a proper module, but you can get a modularized version e.g. from the SpamAssassin sources.) Samma på svenska. Ja suomeksikin.