Subject: Re: todo: add language encoding information

From: Henry Story <[email-masked]>
Date: Wed, 1 Feb 2006 10:14:12 +0100

On 1 Feb 2006, at 02:10, Eric Scheid wrote:

>
> On 31/1/06 1:27 PM, "James Holderness" <[email-masked]> wrote:
>
>> Actually I was thinking just a regular href and type. For example:
>>
>> <link type="application/atom+xml"
>> href="http://mydomain.com/feed"
>> hreflang="fr"
>> x:id="french_entry_id"
>> x:updated="2005-11-15T18:30:02X" />
>>
>> I'm not sure how valid that is considering a client that didn't  
>> understand
>> this extension would consider the full feed to be an alternative  
>> for that
>> one particular entry which doesn't seem right.
>
> Any reason that application/atom+xml document couldn't be an Atom  
> Entry
> Document, apart from the current lack of reader/browser support? It  
> could
> also then include the links necessary to subscribe to the specific  
> language
> feed.

I think that was one of James' original suggestions. It seems like  
one good solution. The only problem is that it forces people to have  
Entry Documents.

I am just writing up a document listing all the different ways one  
can solve this problem...

> e.

---

From: Henry Story <[email-masked]>
Date: Wed, 1 Feb 2006 16:07:23 +0100

Thanks for the reminder. I had not completely swapped in the earlier  
parts of the thread.

1. Content translation
-----------------------

With the  hreflang pointing to the alternate content inside the entry

     <entry>
        <title>Atom-Powered Robots Run Amok</title>
        <link href="http://example.org/2003/12/13/atom03"/>
        <link href="http://example.org/2003/12/13/atom03/fr"  
hreflang="fr"/>
        <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
        <updated>2003-12-13T18:30:02Z</updated>
        <summary>Some text.</summary>
      </entry>

we get the ability to point to any number of different language  
versions of the same document.
But this does not help the user who would like to find the  
translation of the metadata in his language.

2. Metadata translations
------------------------

For translation of metadata (title, subtitle, summary and content are  
the ones that would be affected - any others?), there are a number of  
solutions:

2.1 Feed translations.
---------------------

	As James Holderness points out below one can have the feed that the  
entry is contained in  point to a feed that contains the translated  
metadata feed. There was some discussion there about the best way to  
do that (self or alternate, if I recall correctly) but it is clear  
that there should be no difficulty there.

	One problem here is how to tell which entries in one feed are  
translations of which entries in the other.

  	a- One could simply find this out by giving the entries in both  
feeds that are translations of each other the same id. In web  
architecture terms the entries could be seen as different language  
representations of the resource named by the id. [[ but see problem  
with SHOULD restriction below ]].
	b- Otherwise one needs to be able to create translations (alternate  
language) link relations from entries to entries across feeds.

2.2. Entry Translations
-----------------------

   As Simon Phipps pointed out, for small players, translations are  
expensive. The creator of an entry may for example only have time to  
translate the metadata for a few of the entries for which he can see  
this to be of value. He may not even wish to translate the content,  
leaving that for someone else with a little more time perhaps to do.  
So we could have french metadata for content that is only available  
in english (but that may later become available in french).

    So here it seems that there is at least one use case requirement  
for having some way to tell that two entries in the same feed are  
translations of one another. Following the logic of 2.1 there should  
be 2 ways of doing this:

	a- Simply publish the two entries with the same id. Here the two  
entries are seen as two different language versions of the resource  
named by the id.
	b- We need to be able to create a translations (alternate language)  
link relation between two entries with different ids in the same feed.

Now solution (a) does not work in this situation because of the  
famous SHOULD level restrictions on when two entries can appear in a  
feed.

[[
   If multiple atom:entry elements with the same atom:id value appear in
    an Atom Feed Document, they represent the same entry.  Their
    atom:updated timestamps SHOULD be different.
]]

And the Swiss case shows that one may be obliged to publish two  
different language versions
simultaneously. But perhaps this is why we don't have a MUST level  
restriction, but only a SHOULD. And perhaps it really is permissible  
to have different language representations of the same entry id.

Even then we may still want some way to specify that two entries are  
metadata translations of each other (eTranslations in the graph).  
Perhaps someone wants to translate an entry of mine, but does not  
want to use the same entry id. They would then still want a way to  
specify the relation between the two ids. (note that in RDF one could  
solve this by saying that the two ids are same-as each other, and  
fall back to case (a)).

HOWTO
=====

So how can we specify that two entries are translations of each other?

0. Entries have same id
-----------------------

If the two entries have the same id yet have different language  
settings, then when we come across both we should guess that these  
two represent the same thing.
	+ it would mean that an aggregator that had found one entry would  
know he need not ping his user to let them know about the new version  
in a different language.
	- this does not help find a different language entry when one finds one

The biggest problem is finding a way to point from one entry to  
another. All entries have ids, but these don't tell us where we can  
get information about them. An atom id is usually not dereferenceable.

Also it is not clear that it would be understood that the new  
representation in a different language is not just meant to be a  
replacement of the old one. (See SHOULD level restriction mentioned  
above). [[ There needs to be a debate as to whether multilingual  
representations of an entry can exist simultaneously. Ie. is this a  
special case where SHOULD rule can be broken? ]]

1. give entries urls
--------------------

When entries have urls then it is easy to link to them.
Here is an example:

<feed>
	...
	<entry>
		<link rel="self" type="application/atom+xml" href="entries/en/ 
e1.atom"/>
                 <title>Atom-Powered Robots Run Amok</title>
                 <link type="application/atom+xml"
                       hreflang="fr"
                       href="entries/fr/e1.atom"/>
                 <id>tag:eg.com,2005/en/atom03</id>
                 <updated>2003-12-13T18:30:02Z</updated>
                 <summary>Some text.</summary>
		...
	</entry>
	<entry>
		<link rel="self" type="documents/atom+xml" href="entries/fr/e1.atom"/>
                 <title>Robots Atomiques se révoltent</title>
                 <link href="http://example.org/2003/12/13/atom03"/>
                 <link type="application/atom+xml"
                       hreflang="en"
                       href="entries/en/e1.atom"/>
                 <id>tag:eg.com,2005/fr/atom03</id>
                 <updated>2003-12-13T18:30:02Z</updated>
                 <summary>Some text.</summary>
		...
	</entry>

</feed>

The disadvantage is that one has to place entries at well known  
locations for this to work correctly, which creates duplication of  
entries (one in the feed, and one on the hard drive). The protocol  
may force this issue anyway. (does the atom protocol force entries to  
have urls, so they can be GET, PUT, and DELETEed?)

2. if entries do not have URLs
------------------------------

Then one can only point to entries by their id. But since ids are not  
dereferenceable, this is not very helpful. It would tell the reader  
of the entry that this is an entry whose metadata has an alternate  
language version, and so it would/could reduce the number of alterts  
a client would need to send out (he has already seen the alternate  
entry for example).

   this would require a new link type

   <link rel="translate" hreflang="en" href="tag:eg.com,2005/en/atom03">

where the href points to the id of the translated entry. I suppose  
one would assume that at the
time of the entry update the relations was true.

Now if one wanted to find the feed in which the entry with that id  
had appeared one would have to add an extension to the link such as  
xxx:feedhref="http://example.org/feed.atom"

<link rel="translate"
       hreflang="en"
       href="tag:eg.com,2005/en/atom03"
       xxx:feedhref="http://example.org/feed.atom">

where xxx:feedhref would point to a feed document that forms part of  
a next, prev chain of such documents that constitute a feed, in which  
the other language version entry could be found (among other places)

QUICK CONCLUSION
----------------

The simplest and least powerful solution of simply having entries  
with the same id but in different languages is (very probably) not  
possible because of the SHOULD restriction in the spec. This makes it  
impossible for one to just state that feeds are translations of each  
other, as it would not help one work out which entries in one feed  
were translations of which entries in the other feed.

We need a link relation to relate entries. The link alternate  
pointing to an entry would work best if entries had urls that were  
dereferenceable.

Otherwise one needs to create new "translation" link relation that  
points to an entry id in its href. This would not be very helpful in  
finding the translated entry (unless of course the id of an entry was  
the same place as that at which it could be GET, PUT, POST and DELETEd)

Henry Story

PS. Not sure what I should do with the above. Perhaps write it up  
somehow?

On 31 Jan 2006, at 02:17, James Holderness wrote:

>
> Henry Story wrote:
>> Just re-reading your mail I think you make a good point that perhaps
>> "translation" is the wrong word to use. We would like something more
>> abstract such as "otherLanguageVersion". This made me think that the
>> word we want is "alternate". And then looking at the spec again I
>> found the following:
>>
>> [[
>> 4.2.7.4.  The "hreflang" Attribute
>
> This was the first thing I suggested...
>
> "If you want to link the various translations together you can add  
> one or more link elements at the top of the feed with  
> rel="alternate" and hreflang set to the language of the alternate  
> feed. If you're feeling really enthusiastic you can include  
> alternate links pointing to the translated html pages for each  
> entry too." [1]
>
> Regards
> James
>
> [1] http://www.imc.org/atom-syntax/mail-archive/msg17609.html