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).
http://de.lirio.us/rubric/post?uri=http://www.snopes.com/religion/hammer.asp&title=Urban%20Legends%20Reference%20Pages:%...
- cached
- mail it
- history
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
I don't get it. The site is in Unicode already.
What does "for language support" mean?
The site generates pages encoded in UTF-8 and generally on its own is behaving correctly as far as I can tell (but I'm no expert on this).
What is problematic is when your browser guesses what character encoding to use, and guesses wrong, and/or when you are linking to a page which uses some other encoding in its .
My Firefox, for example, is currently configured to auto-detect; this page where I'm editing this, which has correct UTF-8 headers, gets autodetected as ISO-8859-1 nevertheless. I can manually change it when needed -- via View > Character Encoding > Unicode (UTF-8) but on the editing form, this sometimes has undesired side effects (such as, for example, discarding the contents of some form fields -- I believe I have reported here about the problem previously).
Many sites have the <title> element of the page encoded strangely; currently, it appears that the /rubric/post command will simply copy whatever is there into the "title" field of the form, without any sort of attempt to adapt the text encoding. This can result in invalid UTF sequences in the form (which will be rejected when you try to submit) or, in the worst case, in wrong glyphs being generated. It probably also throws off the heuristics used by the browser to determine which encoding to use.
Perhaps Lirio could detect this, and generate a warning already when the submission form is generated; and/or ideally attempt some sort of up-translation, but this is error-prone.
Update: The title stuff isn't handled by the server at all; there was a problem in the bookmarklet which is now fixed. See http://de.lirio.us/rubric/entry/8737 and http://de.lirio.us/rubric/entry/8761
</div>
by <a class="syUsername" title="User's Bookmarks"
href="/user/era">era</a>
<span class="syLinkTime">2006-06-19 01:23</span>
<span class="syLinkTag">
<a class="syTag" href="/user/era/tag/%22blog%22">blog</a>
·
<a class="syTag" href="/user/era/tag/%22delirioussiteblog%22">delirioussiteblog</a>
·
<a class="syTag" href="/user/era/tag/%22deliriouswishlist%22">deliriouswishlist</a>
·
<a class="syTag" href="/user/era/tag/%22deliriouswishlist.workaround%22">deliriouswishlist.workaround</a>
·
<a class="syTag" href="/user/era/tag/%22erablog%22">erablog</a>
·
<a class="syTag" href="/user/era/tag/%22rubric_0.09%22">rubric_0.09</a>
·
<a class="syTag" href="/user/era/tag/%2220060619-0123%22">20060619-0123</a>
</span>
<div>
<span class="syLinkPublicURL">
http://de.lirio.us/rubric/entry/8375
</span>
<!-- - <a href="LinkSimilar.do?username=era&href=http%3a%2f%2fde.lirio.us%2frubric%2fentry%2f8375">similar</a>
-->
<!--
- <a href="http://web.archive.org/web/*/http://de.lirio.us/rubric/entry/8375">cached</a>
-->
- <a href="ShowCachedUrl.do?url=http%3a%2f%2fde.lirio.us%2frubric%2fentry%2f8375&userName=era">cached</a>
- <a href="LinkMail.do?href=http%3a%2f%2fde.lirio.us%2frubric%2fentry%2f8375">mail it</a>
- <a href="/link/info/http://de.lirio.us/rubric/entry/8375">history</a>
</div>
</div>
</div>
</div>
<div class="syLinkBlock">
<div class="syLinkTitle">
<!--
5.
-->
<a title="Copy this Link" href="LinkAdd.do?title=Wishlist+item%3a+Keep+previous+description+(and+body%3f+and+tags%3f%3f)+on+copy&href=http%3a%2f%2fde.lirio.us%2frubric%2fentry%2f5577&_doneURI=%2fuser%2fera%2ftag%2f%22rubric_0.09%22%2fp%3d0%2c10"><img width="8" height="8" border="0" alt="Copy this" src="/img/icon-add-8x8.gif"/></a>
<a style="font-weight: bold;" class="mcsp" href="http://de.lirio.us/rubric/entry/5577">Wishlist item: Keep previous description (and body? and tags??) on copy</a>
</div>
<div class="syLinkMeta">
<div class="syLinkFragment">
</div>
<div>
<div class="syLinkNote">
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.
</div>
by <a class="syUsername" title="User's Bookmarks"
href="/user/era">era</a>
<span class="syLinkTime">2006-06-19 01:23</span>
<span class="syLinkTag">
<a class="syTag" href="/user/era/tag/%22blog%22">blog</a>
·
<a class="syTag" href="/user/era/tag/%22bugs%22">bugs</a>
·
<a class="syTag" href="/user/era/tag/%22deliriouswishlist%22">deliriouswishlist</a>
·
<a class="syTag" href="/user/era/tag/%22erablog%22">erablog</a>
·
<a class="syTag" href="/user/era/tag/%22rubric_0.09%22">rubric_0.09</a>
·
<a class="syTag" href="/user/era/tag/%22rubric_0.10%22">rubric_0.10</a>
·
<a class="syTag" href="/user/era/tag/%2220060619-0123%22">20060619-0123</a>
</span>
<div>
<span class="syLinkPublicURL">
http://de.lirio.us/rubric/entry/5577
</span>
<!-- - <a href="LinkSimilar.do?username=era&href=http%3a%2f%2fde.lirio.us%2frubric%2fentry%2f5577">similar</a>
-->
<!--
- <a href="http://web.archive.org/web/*/http://de.lirio.us/rubric/entry/5577">cached</a>
-->
- <a href="ShowCachedUrl.do?url=http%3a%2f%2fde.lirio.us%2frubric%2fentry%2f5577&userName=era">cached</a>
- <a href="LinkMail.do?href=http%3a%2f%2fde.lirio.us%2frubric%2fentry%2f5577">mail it</a>
- <a href="/link/info/http://de.lirio.us/rubric/entry/5577">history</a>
</div>
</div>
</div>
</div>
<div class="syLinkBlock">
<div class="syLinkTitle">
<!--
6.
-->
<a title="Copy this Link" href="LinkAdd.do?title=Bug%3a+URL+%23fragment+lost+on+(copy)&href=http%3a%2f%2fde.lirio.us%2frubric%2fentry%2f5563&_doneURI=%2fuser%2fera%2ftag%2f%22rubric_0.09%22%2fp%3d0%2c10"><img width="8" height="8" border="0" alt="Copy this" src="/img/icon-add-8x8.gif"/></a>
<a style="font-weight: bold;" class="mcsp" href="http://de.lirio.us/rubric/entry/5563">Bug: URL #fragment lost on (copy)</a>
</div>
<div class="syLinkMeta">
<div class="syLinkFragment">
</div>
<div>
<div class="syLinkNote">
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.)
</div>
by <a class="syUsername" title="User's Bookmarks"
href="/user/era">era</a>
<span class="syLinkTime">2006-06-19 01:23</span>
<span class="syLinkTag">
<a class="syTag" href="/user/era/tag/%22blog%22">blog</a>
·
<a class="syTag" href="/user/era/tag/%22bugs%22">bugs</a>
·
<a class="syTag" href="/user/era/tag/%22deliriousbugs%22">deliriousbugs</a>
·
<a class="syTag" href="/user/era/tag/%22erablog%22">erablog</a>
·
<a class="syTag" href="/user/era/tag/%22rubric_0.09%22">rubric_0.09</a>
·
<a class="syTag" href="/user/era/tag/%22rubric_0.10%22">rubric_0.10</a>
·
<a class="syTag" href="/user/era/tag/%2220060619-0123%22">20060619-0123</a>
</span>
<div>
<span class="syLinkPublicURL">
http://de.lirio.us/rubric/entry/5563
</span>
<!-- - <a href="LinkSimilar.do?username=era&href=http%3a%2f%2fde.lirio.us%2frubric%2fentry%2f5563">similar</a>
-->
<!--
- <a href="http://web.archive.org/web/*/http://de.lirio.us/rubric/entry/5563">cached</a>
-->
- <a href="ShowCachedUrl.do?url=http%3a%2f%2fde.lirio.us%2frubric%2fentry%2f5563&userName=era">cached</a>
- <a href="LinkMail.do?href=http%3a%2f%2fde.lirio.us%2frubric%2fentry%2f5563">mail it</a>
- <a href="/link/info/http://de.lirio.us/rubric/entry/5563">history</a>
</div>
</div>
</div>
</div>
<div class="syLinkBlock">
<div class="syLinkTitle">
<!--
7.
-->
<a title="Copy this Link" href="LinkAdd.do?title=Bug%3a+UTF8+does+not+display+correctly&href=http%3a%2f%2fde.lirio.us%2frubric%2fentry%2f5417&_doneURI=%2fuser%2fera%2ftag%2f%22rubric_0.09%22%2fp%3d0%2c10"><img width="8" height="8" border="0" alt="Copy this" src="/img/icon-add-8x8.gif"/></a>
<a style="font-weight: bold;" class="mcsp" href="http://de.lirio.us/rubric/entry/5417">Bug: UTF8 does not display correctly</a>
</div>
<div class="syLinkMeta">
<div class="syLinkFragment">
</div>
<div>
<div class="syLinkNote">
If you require input to be UTF8, you should also serve it back as UTF8
The referenced entry contains a bit of background. Anyway, I was trying to create an entry with a body which contained the letter lowercase a with a circle on top ("Angstrom", "Swedish o") and the post was getting rejected. I finally managed to get it accepted by typing in the raw Unicode for this character, which displays as ÃÂ¥ in Latin-1 (that's uppercase A with a tilde accent, and a Yen currency symbol). But now that I view the page in Latin-1, that's still how it displays. (And the UTF-8 in this entry displays as roughly AfAY, i.e. the same with a "franc" currency sign and an uppercase A with a circonflex accent in between the two others.)
The server should be configured to serve the pages as UTF-8, and/or the served pages should have a http-equiv header identifying the character set of the content (but this is not widely supported -- I believe it's disabled in Apache by default, and on the client side at least Mozilla didn't use to obey it).
Update: It seems that this is merely a bug in my browser. It appears to ignore the header which is sent correctly from the server as it should.
HTTP/1.1 200 OK^M
Date: Mon, 18 Apr 2005 12:09:09 GMT^M
Server: Apache/2.0.51 (Fedora)^M
Set-Cookie: CGISESSID=1dae828430a5d71938409c99ddf93897; path=/; expires=Mon, 25-Apr-2005 12:09:09 GMT^M
Connection: close^M
Content-Type: text/html; charset="utf-8"^M
^M
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>de.lirio.us :: : entries filed under { delirioussiteblog }
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.
simpy
