Re: syntax for bilingual page

Erik Wilde <dret@berkeley.edu> Mon, 06 September 2010 02:49 UTC

Return-Path: <owner-atom-syntax@mail.imc.org>
X-Original-To: ietfarch-atompub-archive@core3.amsl.com
Delivered-To: ietfarch-atompub-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121D03A65A6 for <ietfarch-atompub-archive@core3.amsl.com>; Sun, 5 Sep 2010 19:49:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.554
X-Spam-Level:
X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGKVZN0c4A0N for <ietfarch-atompub-archive@core3.amsl.com>; Sun, 5 Sep 2010 19:48:58 -0700 (PDT)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id B00833A6359 for <atompub-archive@ietf.org>; Sun, 5 Sep 2010 19:48:58 -0700 (PDT)
Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o862dUYX063357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Sep 2010 19:39:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o862dUO6063356; Sun, 5 Sep 2010 19:39:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.ischool.berkeley.edu (bliss.ISchool.Berkeley.EDU [128.32.78.13]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o862dTKm063351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <atom-syntax@imc.org>; Sun, 5 Sep 2010 19:39:29 -0700 (MST) (envelope-from dret@berkeley.edu)
Received: from [192.168.1.105] (70-36-134-55.dsl.dynamic.sonic.net [70.36.134.55]) (authenticated bits=0) by smtp.ischool.berkeley.edu (8.13.1/8.13.1) with ESMTP id o862dSYf028864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 5 Sep 2010 19:39:28 -0700
Message-ID: <4C84545C.6070302@berkeley.edu>
Date: Sun, 05 Sep 2010 19:39:24 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: "atom-syntax@imc.org" <atom-syntax@imc.org>
CC: Yves Dorfsman <yves@zioup.com>
Subject: Re: syntax for bilingual page
References: <4C7F432A.3070506@zioup.com> <4C825789.5040300@zioup.com> <6482EA48-E855-4DD8-8EE9-F42B316B93E0@berkeley.edu> <4C83D4A8.8040704@zioup.com>
In-Reply-To: <4C83D4A8.8040704@zioup.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.70 on 128.32.78.13
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>

hello yves.

Yves Dorfsman wrote:
>> you're right that there only can be one title, which is bad for
>> internationalization, but makes life easier for consumers. as
>> unfortunate as it is, it's not going to change (i guess),
> Why?
> Why couldn't we extend / update the atom format to support 
> internationalization ?

we could, but i would be surprised if that would get enough people 
behind it to support it. it would break atom 1.0, and there seems to be 
little desire to do that. the occurrence indicators for the metadata 
elements on both the feed and the entry level in atom look fairly random 
(at least that's my personal opinion), and it probably would have been 
better to not create them this way. but that's what we have now, and i 
don't see it changing anytime soon.

>> so you will
>> just have to make peace with this design. maybe use one feed per
>> language? not great, but correct and probably a pattern you'll see in
>> many places...
> So do you suggest to use the same <id> for both entries then?

you could certainly used localized feeds and from those point to 
internationalized entry resources. but then you have to think about what 
to do if the feed reader does not specify a language preference in HTTP 
when GETting the entry, so maybe instead of using HTTP language 
negotiation, it might be more robust to link to the entry URIs with the 
language preference encoded in a query parameter, and let the entry 
service accept both query parameter language preferences and HTTP 
language negotiation.

for general advice on how to create and manage entry IDs, you might want 
to look at http://diveintomark.org/archives/2004/05/28/howto-atom-id

kind regards,

erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        dret@berkeley.edu  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)