Re: Re: [FeedValidator] Validating dates

> > 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.

It's not defined in the how RSS feeds are handled.  What's possible with
making HTTP requests in a browser are not necessarily mimicked in RSS
readers.  This is both a good and a bad thing, depending on what features
you're after.

> > 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.

And it's been my experience that no one solution works reliably enough not
to antagonize a really large part of the audience.  Language is such a
tricky area.  Made worse by developers often using only one language (often
english, but not always).

> 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...

Yes, I didn't want the postings to the thread to look like anyone was being
overly harsh toward the original posting.  I'm not one for political
correctness but I have seen where discussions about language often get
dramatically misinterpreted.  I don't think either of us are missing the
point.  Hopefully nobody else will either.

> 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.

Well, when you ass-u-me....  I wouldn't.  I've seen some really bad examples
of misconfigured browsers.  A worst-case scenario is how to deal with data
pasted into a korean web page served from an arabic configured http server
using a danish configured browser on a russian configured OS.  There's four
different places where "language" and "encoding" is being set, which one's
correct?  From what I've seen various tools make their assumptions based on
different parts, sometimes it almost seems random.  Thus I think it leads to
the classic problem of people developing a "fixed" opinion on what's correct
based on what are often entirely INcorrect tool behaviors.  Basically, "my
favorite tool says this is OK so all the rest of you are wrong", more or
less.  I don't have any miracle answers here, just warnings.

> I'm slightly disappointed to see that
> NetNewsWire doesn't.  Shame really since IMHO it would be perfect for a
> desktop aggregator like that.

Again, I think it's due to the usual situation of the developer being
focused on a given language and not being aware of or interested in
addressing some of the more subtle aspects of multilingual access.  I'm sure
if the issue was brought to any developers attention and explained
effectively they'd certainly be willing to consider adding features for it.
But, much like character encoding, language is a really poorly understood
facet of XML.

-Bill Kearney
Syndic8.com



 
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/