Re: [FeedValidator] Validating dates

Bill Kearney <[email protected]> wrote:

[snips]

> > HTTP language negotiation works perfectly for direct subscriptions (if
> > supported by the reader), but not so well (I imagine) for web-based
> > aggregators like Syndic8.  For Syndic8 I could provide different
> > 'autodiscovery' <atom:links> to feeds with a hard-coded language
> > parameter in the url, but that defeats my beautiful HTTP language
> > negotiation if someone subscribes to one of those hard coded links using
> > a standalone reader.
> 
> There's no defined mechanism for negotiating language with feeds.

That's like saying there's no defined mechanism for caching, compression
or encryption.  Feeds delivered by HTTP have a mechanism available;
it's just that people like you and me have to decide whether using it
makes sense.

> That and plenty of readers are multilingual.

You mean a bilingual French & German speaker might want to read one feed
in French and one in German even if both feeds are available in both
languages?  Certainly you're right that the 'transparent' HTTP mechanism
doesn't cope with that at all.

> I've always found it's better to let users of a given language select one
> in that language independently of whatever 'default' language might be
> used.

Yes, that probably makes sense, but until <atom:link> there was no
uniform way to do that.  My feeds do have a cgi variable to set an
explicit language choice (actually, it gets prepended to the priority
list from HTTP).

> That and none of the readers (I'm aware of) make proper use of
> language requesting in the first place. I'm not sure that's a bad thing.

You may be right!

> > Absolutely: what the OP was apparently doing was unquestionably wrong.
> > But I'm not doing that!
> 
> Well, I don't want to characterize anything as "unquestionably wrong" just
> not an ideal practice in the context of feeds.  While it's true the dates
> were being improperly adulterated I'm sure the other aspects of the
> framework might offer useful mechanisms.

Heh :)  All I meant was "unquestionably wrong" is the (language-based)
adulteration of <pubDate> (or whatever it was).  No disrespect intended
to the OP.  He was clueful enough to try to validate his feed, and he's
probably fixed that tiny bug by now...

> > That's one of the good things about Atom.  While it might be obvious to
> > you and me which bits of a feed may be translated, and which bits should
> > never be, when I wrote my Atom feed generator I didn't need to think
> > about it because I could translate (some of) only those elements
> > explicitly marked in the spec as 'language sensitive'.
> 
> I'm curious, what tools have you seen that effectively handle them?

<atom:link language="xx"> for translation autodiscovery?  I haven't
looked, but Atom is fairly new and even if there aren't any now there
may well be in the future.  Besides it's a bit of a chicken & egg
situation.  Err, now I think about it, I haven't actually implemented
that in my feeds anyway...

As for traditional HTTP-based language negotiation, Safari and Firefox
certainly do it in their feed readers (as you'd expect).  I assume other
browser-based readers will also.  I'm slightly disappointed to see that
NetNewsWire doesn't.  Shame really since IMHO it would be perfect for a
desktop aggregator like that.

Regards,

Peter
-- 
Peter Robinson
<http://www.ticketswitch.com/> Concerts, sport and theatre tickets


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/