Consider
Norwegian-Bokmal (NO and nb-NO) done. Christian did it. Already
installed here; best seen in the comment view if you’ve got Norwegian as
the most preferred language.
Note: For visitors of your site, this entry is only displayed for users with the preselected language English/English (en) Error:
System.ArgumentException: Culture name en;q=1.0 is not supported.
Parameter name: name
at System.Globalization.CultureInfo..ctor(String name, Boolean useUserOverride)
at System.Globalization.CultureInfo.CreateSpecificCulture(String name)
at newtelligence.DasBlog.Web.Core.SharedBasePage.SetupPage(Object o, EventArgs e)
at System.EventHandler.Invoke(Object sender, EventArgs e)
at System.Web.UI.Control.OnInit(EventArgs e)
at newtelligence.DasBlog.Web.HomePage.OnInit(EventArgs e)
at System.Web.UI.Control.InitRecursive(Control namingContainer)
at System.Web.UI.Page.ProcessRequestMain()
while processing ht tp://staff.newtelligence.net/clemensv/default.aspx?external_referrer=ht tp://newtelligence.com/.
To whoever caused this event log entry to show up 10 minutes ago .... thanks, should be fixed now ;)
So.... dasBlog 1.2 nears completion and this will then also conclude the “feature rush“ for a while, because the allocated time for this “summer project” (5 weeks) is up and I have to shift gears. The last step for 1.2 is localization. Based on the user’s top preference in the Accept-Language header, dasBlog 1.2 presents all “hard coded” strings for publicly visible elements like the “Comment” link and the entire administrator interface in the preferred language, if the respective resources are available.
There’s now also an additional macro “localString” that you can use to define a multilingual expression in your templates: <%localString(“This is the English default|DE:Das ist die deutsche Alternative|IT:Questo e in italiano”)%>. This will resolve into German or Italian if that’s on the user’s language preferences list (Accept-Language header, again) and fall back to the default expression before the first delimiter if there’s no proper mapping. And, yes, you could also differentiate between “en-GB”, “en-US” and “en-CA”.
On the posting side, all posts are posted with the “invariant culture” (empty identifier) by default and will therefore show up on the blog independent of the user’s language preference. However, you can also select a language/culture pair when posting (for instance either “de” for German in general or “de-AT” for Austria, specifically) and then the post will only show up for users who have this language/culture listed in their browser’s language preferences. In the RSS feeds, the <item> tag will then carry the proper xml:lang designation (which propagates down to all its children as per XML 1.0).
By now, I have two complete language sets for the localized resources for English (en-US) and German (de-DE), but that’s as far as my “active” language skills take me. So if any of you folks out there (especially dasBlog users – hint, hint) have some 20 minutes of time and want to help me with localization into languages other than those two, grab the three files below (it’s just XML), translate the stuff between the <value> tags (except the topmost four) and send them, with the filenames reflecting the culture (such as Web.StringTables.ES.resx for Spanish), back to me at clemensv@newtelligence.com
Of course, I will have to figure out how trust the correctness if I am getting translations into languages that aren’t from Latin or Germanic descent (most of those I can usually figure out), but that’s something to determine if and when it happens. For now, this is also a great experiment to see whether this little call for help yields any results. You’ll definitely get a permanent link and mention prominently on the dasBlog website and I can also put your blog into the blogroll that is included the setup archives, how’s that for a “payment”?
Download: Web.StringTables.resx
Download: WebControls.StringTables.resx
Download: WebCore.StringTables.resx
Since the backend stores all times in UTC, the engine can also adjust for daylight savings time when rendering. Check out the April 1st page and compare the timezone info below the entries with the following March 30th.
(BTW, I've done the whole time handling stuff mostly because I've seen that being only on GMT is a bit painful if you are a Fast Chicken in NZ. Nic, you get your timezone back.)
Don't be surprised to see this Weblog showing you Russian day and month names if your browser's preferred language is set to Russian or talks to you in Spanish or Italian. Also, don't be surprised if even more things (like the "Comments" link or all the field names on the Comment page) show up in German, if your preferred language is German. That's a feature.
This is a split entry consisting of two posts. Everyone can see this post, but you will not see (2/2) on the website, if your browser's "Languages" setting doesn't have German as an acceptable language.
DateTime issued;
[XmlIgnore]
public DateTime IssuedUtc
{ get { return issued; } set { issued = value; } }
[XmlElement("issued")]
public DateTime IssuedLocalTime
{ get { return Issued.ToLocalTime(); } set { Issued = value.ToUniversalTime(); } }
Why?
Here's a CERT advisory to check out regarding the vulnerability of other DCE implementations to the Blaster worm. And unless otherwise stated on their site (which isn't the case now), I would assume that Software AG's EntireX DCOM is vulnerable as well.
In 1.1 (hidden) and in 1.2 (no longer hidden) of dasBlog, you can enable a feature for Mail-To-Weblog that will automatically turn attached pictures (not embedded pictures) into thumbnails in the post and you can also control the maximum height for the thumbnails. The relevant settings in site.config for 1.1 are
<Pop3InlineAttachedPictures>true</Pop3InlineAttachedPictures>
<Pop3InlinedAttachedPicturesThumbHeight>200</Pop3InlinedAttachedPicturesThumbHeight>
In 1.2 the config settings are the same, but I added them to the config page. Here's an example of how it comes out:
Das Blog-splash.jpg
Those who are using dasBlog for their own blog and everyone reading my blog on the website or ever looked at my RSS feed may have noticed that all times in version 1.1 now show up as GMT (it's actually UTC, but for all practical purposes, the difference between UTC and GMT matters little here; GMT is the more common designation).
I am in the GMT+2 time-zone and so is my server, but for a site with apparently global reach in a global medium this doesn't really matter, I think. Most people know their time zone offset from GMT, but do they know their time zone offset from Germany?
Bad examples for using time are the sites of the two most popular "recent blog changes" services. Blo.gs, for instance, uses some undeclared random time zone and Weblogs.com, does at least say that the timezone is "Pacific" (but that's of course PDT now and not PST, or isn't it?). There's a standardized, daylight-savings-time unaffected global time and that's GMT (actually, it's UTC). I know that's a little incovenient for folks in GMT-8 or GMT+12, but it's a standard.
Dan Farino, who wrote the CLR based, Regex extended stored procedure on which I put a warning sign yesterday, wrote me an email back (I notified him that I wrote that blog entry) and told me that he just uploaded an unmanaged version. Haven't downloaded it, yet, but it seems to be functionally equivalent. If it's stable and quick, I can think of 2 bazillon uses for this -- including, of course, Regex based XML parsing inside SQL Server (while we wait for Yukon).
My old blog is still on #1 for "Clemens" and my new blog is, surprisingly, already on #4 on Google. For "Vasters", my blogs take #1 and #2 with the Radio blog still on top. I guess that'll turn around within the next few weeks.
I guess my next little toy project will be around aggregation. Not that I won't continue adding stuff to "dasBlog", but I am quite happy with the status as of now and once we've got Stephen's caching work in the project, we'll make it a 1.2 .
So, the other bigger chunk of code that I have sitting around here from the blogging infrastructure that I wrote but didn't get done in the first quarter of this year (and from which the rendering engine made it into dasBlog) is a pretty serious, extensible syndication engine based on Enterprise Services and SQL Server. Pulling in RSS feeds is, in my view, a background server task. A common infrastructure for subscribing, queuing, requesting, transforming, filtering, caching and pushing out results (via LCE) is something that could be very handy, makes a great demo and there's lots of sample data to gather in a short time ;)
I am not at all interested in writing yet another aggregation GUI. I may grab one of the available aggregators like SharpReader or RSS Bandit and hook it up for demo purposes, but that's about it.
So ... while looking around for tools I could use, I found this cool extended stored procedure for using .NET Framework regular expressions straight from within SQL Server. Hold! What I also found (and I actually looked for it) was this Microsoft KB article (Q322884) that states that extended stored procs written in managed code "is not supported".
Based on some discussions I had with members of the SQL team about the next release of SQL Server (Yukon) earlier this year about their work around incorporating the CLR (the fact that they're doing that is public so I am not violating any of the papers I signed), this absolutely doesn't come as a surprise to me and the bottom line is: This stored procedure looks cool, but shouldn't get near a SQL Server 2000 production server, ever.
The reason for that is that SQL Server is essentially an operating system by itself. It does its own memory management, can do its own thread scheduling (it makes use of fibers, which are self-scheduled threads) and has, of course, its own I/O system sitting on low-level OS functions. The CLR doesn't know about any of that and SQL Server 2000 doesn't know about the CLR. If you are writing a stored procedure in unmanaged C/C++, you create just a DLL that runs on top of Win32 and if you follow a couple of rules, you should be ok. If you are writing in C# or VB.NET, you are bringing along an environment that doesn't know anything about these rules around SQL's use of threading and thread local storage, probably wants to launch additional threads under the covers and whose garbage collector hasn't been designed to cooperate with SQL's memory management. Yes, it may run, but what happens under stress or low memory conditions? How does it affect transactions? What's the story around performance once the CLR is present in the process and is probably used in only one of 500 queries? I know that putting the CLR into Yukon is nothing that a someone at Microsoft does in a day or two and therefore I doubt that putting the CLR into SQL 2000 within half a day is a good idea for a real system. Things are different if you are running inside what essentially is an OS kernel.
Jon Udell found (and Stefan Tilkov did too) that my new design doesn’t (didn’t) work in Mozilla Firebird.
The issues were inconsistencies in the behavior of the "float" and "clear" CSS properties between Opera, IE and Mozilla and, on top of it all, the rustiness of my CSS skills. All the "side-bar" elements on the left side of the page (calendar, navigator links, category list and blogroll) were "width:220px", "float:left" and "clear:both", saying "show this thing on the left hand side of any content that is rendered with regular layout and put the box under all other left floating boxes". So that causes all of these boxes to come out vertically aligned.
Now, the content section was also "float:left" but with "clear:right" and "width:70%". Opera and IE were showing the content as I intended it, to the right of the side-bar. As per the words of the spec, that indeed seems to be proper behavior for "clear:right", because it says that "The top margin of the generated box is increased enough that the top border edge is below the bottom outer edge of any right-floating boxes that resulted from elements earlier in the source document." In other words, since all other elements rendered before this element were "float:left" and there isn't any "float:right" up to this point, the top margin for the new float is should be at relative/top:0px. Opera and IE are right, Mozilla is wrong.
Now... I fixed this for all by simply removing the float/clear properties from the content box and not making the content floating anymore. ... and tripped over another problem: widths.
I set the content box's size to 78%. In IE, that turned out to be 78% of the available horizontal <body> space excluding the width of the already rendered side-bar boxes (now all set to 18% width). In Mozilla and Opera, that's simply 78% of the available horizontal <body> space (in effect, the available page width). So, 78% of 82% of the page width are roughly 64% (63.96%). Measuring pixels of what IE renders and taking the margins of the item boxes into account, I indeed got 64.3% for the content boxes. In Opera, measuring pixels yielded 78.6% of the page width and Mozilla came in at 78.1%.
Since I couldn’t find anything supporting IE's behavior reading the spec section on the width property and the definition of the containing block, I concluded Mozilla and Opera are doing this right and IE is doing it wrong. This was a bit surprising to me, because (a) I don't do web design for a living and would know otherwise and (b) because IE actually needs to perform extra work to get to these numbers, so that behavior is surely no accident.
Switching IE into “standards-compliant mode” by injecting <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> ultimately fixed the width calculation problem, but who would know that intuitively?
This left the problem that Mozilla doesn’t get the clear property right. So, I settled on an absolute horizontal positioning for the content box using “position:absolute;left:22%;width:73%” . Now with that, the footer (yet another <div> at the <body> level) was getting confused, because now I had only floating and absolutely positioned elements and therefore I wouldn’t know where the bottom is. Moving the footer into the content box below the content placeholder fixed that, too. Now it looks good for Mozilla and Opera and IE6.0. If you use an earlier version of IE, upgrade.
Tim Bray, author of the Namespace spec, enlightens us here that I am technically wrong by using the term "empty namespace". Yes. Absolutely. But the "not member of any namespace" vs. "member of the empty namespace" distinction becomes meaningless once you start coding against an XML infrastructure, because in the programming models, there is pretty much always a namespace qualifier. In the .NET Framework, for instance, the NamespaceURI is an empty string in such cases (... and it should really be null).
Jon Udell writes in his most recent column that some think that there is a "controversy" about the use of XML namespaces. This seems to stem from the sad fact that RSS never got a proper namespace assigned to it and is one of the hottest schemas specs in the XML space right now. Sorry, there may people in disbelief, but the XML Namespaces spec is normative and referenced in the current XML 1.0 (Second Edition) spec. The empty namespace is a namespace.
Some notable experts — including Sean McGrath, CTO of Propylon in Dublin, Ireland — argue that namespaces should be avoided for that reason.
You can't avoid namespaces, they are automatic if you use XML today. If you don't declare one for your vocabulary/schema, you are contributing to a large cloud of "stuff" sitting in the "not part of any" namespace. The "empty" namespace (which essentially says "not part of any namespace") is the XML equivalent of a the "these are just some tags" garbage dump.
My buddy Stephen now also runs dasBlog in "all features enabled" mode. Both of us are now using our Radio subscriptions, while they last, just to upstream our RSS feeds to the Userland cloud from dasBlog. His Radio feed is in sync with the new feed and so is mine.
John Bristowe is also a Radio convert and comments that exuberantly with "Free at last, free at last, thank God Almighty, I'm free at last.".
I guess we can sum this up with:
Dear Userland, for more than year you didn't even bother to try fixing all the substantial problems Radio has around random upstreaming failures, random crashes, losing content, whacky caching effects, broken comments, lack of extensibility with mainstream tools and a lot more things. Radio is stuck at version 8.0.8 in a time when a new blogging tool gets published every other day. This is our answer.
I've written a bunch of features in dasBlog specifically to give myself a clean upgrade path from Radio to my stuff (and some of them I still have to document cleanly). Whenever anyone hits a permalink at my old Radio site, they get redirected to the correct entry here, I can update my rss.xml at the Userland cloud and I can use any available Radio design templates pretty much unchanged. What's funny, for instance, is that my engine pretty much never fails with a timeout when upstreaming the rss.xml to the Userland cloud. These are the real reasons for why dasBlog does what it does. I just got totally fed up with Radio.
John Bristowe wrote me a "Thank you" email saying "I believe a "switch" campaign (a la Apple) is in order. Goodbye, Radio. Hello, DasBlog!  ".
There's certainly not going to be a campaign, but I'll happily share my config details with anyone who's asking. Sorry, Userland.
Today was another day of brutal heat. Nearly impossible to go outside during the afternoon. So I had a very lazy start into the day and then watched football (real football!) and observed the players getting grilled ;)
My team, Borussia Mönchengladbach ended up with a 1:1 tie against Werder Bremen, scoring in the 81st minute to equalize a Bremen penalty goal earlier in that half. Two games, 4 points and rank 5 in the league with ranks 1-4 having the same point score. Not bad at all for this year's start. I rarely ever have time to go to the stadium, but I have been a huge fan ever since I could kick a ball. It's my home city club, so we're talking love here, not just sympathy.
Anyways ... between breakfast and football I played around with CSS and created a new template for my own blog, trying to stop myself from jumping into the code-base and making adjustments. Then I dropped the 5 files onto the server some 15 minutes ago and .. voilá ... works. The theme uses IE filters for the shadows, but otherwise it looks the same in Opera. Haven't checked out other browsers, but, in all reality and honesty, and looking at our server logs .... 'nuff said.
Version 1.1 of dasBlog is up for download. Preferred download source is the GotDotNet workspace for the project, the other is on our server here.
With this drop, we’re also releasing the lock on the source and leave the files checked-in in the workspace. If you want to add stuff, you are invited to do so, but make sure you read the set of simple rules I posted there on how to deal with the source control system.
|
He's an author and a great speaker, he was one of the best known technical consultants at Microsoft Germany and he initiated the "MSDN TechTalk" event series. His in-depth knowledge of Win32, COM and COM+ is astonishing and the same goes for the dark corners of the .NET Framework. With this, and a lot more things I could mention here, he's already a "software legend" in the German developer community.
... and now he made a very newtelligent move and joined our team. Welcome on board at newtelligence AG, Michael Willers. |
 |
Jörg ist current checking out dotText. He very much likes the admin interface and says it's very cute. And not only that. I had a glimpse and I have to agree. I think it's fantastic that Scott and us are releasing such big chunks of public code for the same purpose at the same time, but there is no "vs.". I think .Text is cool.
The most striking between the two engines is that .Text sits on SQL and ours uses plain text files. What I found through the email feedback I've gotten is that a lot of people who want to use dasBlog have their stuff sitting at some ISP and either don't have a SQL Server to talk to or the setup is too much of a hassle. So for them, the plain text storage makes more sense. I was about to rip it out and replace the file storage with a SQL backend as well, but now I am quite happy that I didn't.
(Although i have to admit that the transaction-loving architect in me still opposes the whole idea of using plain text files for read/write in a concurrent environment)
The second difference is that I started the whole thing only a bit more than 3 weeks ago from a copy of BlogX.
James Avery suggests creating something new for topic-based aggregation. His idea is to allow aggregation of blogs by topic and not by person and wants new things invented for this.
I think they exist.
The item-level <category> element of RSS allows for setting a taxonomy on category items and that's sufficient to make James' idea work, if (a) aggregators were looking for the domain attribute and allowed grouping by it and (b) blog engines would allow you to attribute your categories like that. Then, we "only" need to agree on common categories (or someone just writes some up) and were set. No need to register anywhere or with a central system. Here's an example of how the elements could look for .NET bloggers:
<category domain="urn:msdn-microsoft-com:netframework">ASP.NET</category>
<category domain="urn:msdn-microsoft-com:netframework">Enterprise Services</category>
<category domain="urn:msdn-microsoft-com:netframework">C#</category>
<category domain="urn:msdn-microsoft-com:netframework">VB.NET</category>
<category domain="urn:msdn-microsoft-com:serversystem">SQL Server</category>
<category domain="urn:msdn-microsoft-com:serversystem">BizTalk Server</category>
|