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
