One issue is that you can only have one title element. Sure I can use xml:lang on that, but I want to have the titles of all language versions in there.
I was curious about that. I checked some specs and frankly I think you are in a world of pain :).
I think you need to have different feeds, one per language, or use HTTP content negotiation.
Something that is not clear to me: you could duplicate the entire item, with a different xml:lang but with the same identifier. But I doubt atom processors would even understand that.
We do offer the ability to choose the language of feeds, and in that case it indeed chooses the language of each entry to match that, if there is a version in that language, or some default.
However, in this case I want to send a representation of a thing (say an article or a person) over pubsub, preferably with all language versions for title, subtitle and summary. Reading some discussions about it, people seem to suggest using multiple entries for each language and linking them. I.e. not using the same id, which seems stupid to me, for my use case. And yes, naive feed processors would not like that either.
I am now thinking of inserting application-specific elements with the values of the fields I need, one for each language. Ugh.
I'm not sure if resource carries over so well with multi-lingual entries. If they are 1:1 translations, I'd say yes, but I get the feeling most entries are more like separate entries about the same subject?
as an example, a resource is a person. The representation of this person is a 'thing' in our CMS, and there are descriptions of this person in multiple languages. Are you saying that they should be different resources? If so, how do I refer to the person?
If the resource is the person, all entries should have the same id. If the resource is the description, that wouldn't have to be the case, as long as they all point to another "person resource".
Since this has to fit into Atom, the Person resource could have some information about the person itself. So title would be her name, and perhaps there wouldn't be any content, but just a link to another resource. Then you have a Person Description resource, which links to the Person resource, and contains the description in various languages.
Have you looked to some of the attempts at standardising localisation, for instance the xml:tm name-space. Read more at LISA.org.
This will, of course, not solve your problems fitting it into Atom, but you could provide the feed in several formats, including one that fits your datamodel, and then also have a hacked legacy Atom feed.
@melo: Well sure we can a new payload format, but I rather like atom over XMPP. I am only sad about the language thing, really. We are now going with a new anymeta:alternate element with an xml:lang attribute for the other language that has atom:title,atom:summary and other child text elements.
Don't get me wrong, I also prefer Atom-over-XMPP, but re-reading this thread just now, it seemed to me that the source of the problems is the Atom format. That's all.
27 comments so far
Use XHTML for the content representation with xml:lang?
1 year, 2 months ago by novemberborn
One issue is that you can only have one title element. Sure I can use xml:lang on that, but I want to have the titles of all language versions in there.
1 year, 2 months ago by ralphm
Why one entry?
1 year, 2 months ago by novemberborn
I was curious about that. I checked some specs and frankly I think you are in a world of pain :).
I think you need to have different feeds, one per language, or use HTTP content negotiation.
Something that is not clear to me: you could duplicate the entire item, with a different xml:lang but with the same identifier. But I doubt atom processors would even understand that.
But yes, it would be nice to have.
Mabe on Atom-bis
1 year, 2 months ago by melo
We do offer the ability to choose the language of feeds, and in that case it indeed chooses the language of each entry to match that, if there is a version in that language, or some default.
However, in this case I want to send a representation of a thing (say an article or a person) over pubsub, preferably with all language versions for title, subtitle and summary. Reading some discussions about it, people seem to suggest using multiple entries for each language and linking them. I.e. not using the same id, which seems stupid to me, for my use case. And yes, naive feed processors would not like that either.
I am now thinking of inserting application-specific elements with the values of the fields I need, one for each language. Ugh.
1 year, 2 months ago by ralphm
I'm assuming that the original author used only one language and the others are translations.
I wonder if the translations shouldn't be different items with a link-back to the original item.
Maybe that is what you meant with "people seem to suggest using multiple entries for each language and linking them"?
1 year, 2 months ago by melo
Well, not in our case. A significant amount of works in our sites are really multi-lingual.
1 year, 2 months ago by ralphm
I am afraid we have to add our own elements. Maybe by using the dc: name space.
1 year, 2 months ago by wok
Can you use something similar to the in-reply-to Atom extension?
1 year, 2 months ago by novemberborn
@novemberborn: that relies on different ids. And we are really talking about the same resource.
I am now looking if we could use Dublin Core elements, but it isn't clear to me if we can embed (x)html in there.
1 year, 2 months ago by ralphm
I'm not sure if resource carries over so well with multi-lingual entries. If they are 1:1 translations, I'd say yes, but I get the feeling most entries are more like separate entries about the same subject?
1 year, 2 months ago by novemberborn
as an example, a resource is a person. The representation of this person is a 'thing' in our CMS, and there are descriptions of this person in multiple languages. Are you saying that they should be different resources? If so, how do I refer to the person?
1 year, 2 months ago by ralphm
If the resource is the person, all entries should have the same id. If the resource is the description, that wouldn't have to be the case, as long as they all point to another "person resource".
1 year, 2 months ago by novemberborn
Ok, following your theory, does your person resource have a title? In which language(s)?
1 year, 2 months ago by ralphm
Since this has to fit into Atom, the Person resource could have some information about the person itself. So
titlewould be her name, and perhaps there wouldn't be any content, but just a link to another resource. Then you have a Person Description resource, which links to the Person resource, and contains the description in various languages.1 year, 2 months ago by novemberborn
apart from not fitting in our data model, do you have any idea how complicated that makes stuff? Ugh. I just want more than one title. :-(
1 year, 2 months ago by ralphm
Having one Person, and various language descriptions of that Person, is quite elegant I think. But that's from a clean-slate perspective.
What extra titles do you need?
1 year, 2 months ago by novemberborn
just one in each language
1 year, 2 months ago by ralphm
I mean, what's the title of a Person resource?
1 year, 2 months ago by novemberborn
Have you looked to some of the attempts at standardising localisation, for instance the xml:tm name-space. Read more at LISA.org.
This will, of course, not solve your problems fitting it into Atom, but you could provide the feed in several formats, including one that fits your datamodel, and then also have a hacked legacy Atom feed.
1 year, 2 months ago by kimbach
Maybe thats part of the problem, trying to fit this into Atom? Of course if Atom is a done deal non-negotiable then this point is moot.
1 year, 2 months ago by melo
@kimbach: Thanks, I will looked into that.
1 year, 2 months ago by ralphm
@melo: Well sure we can a new payload format, but I rather like atom over XMPP. I am only sad about the language thing, really. We are now going with a new anymeta:alternate element with an xml:lang attribute for the other language that has atom:title, atom:summary and other child text elements.
1 year, 2 months ago by ralphm
Don't get me wrong, I also prefer Atom-over-XMPP, but re-reading this thread just now, it seemed to me that the source of the problems is the Atom format. That's all.
1 year, 2 months ago by melo
@melo: Very true. It would be so nice if the restriction of at-most-one would be relaxed to at-most-one-per-lang
1 year, 2 months ago by ralphm
wow, I'm really surprised that this passed muster at the IETF -- clearly I didn't review the spec closely enough during Last Call...
1 year, 2 months ago by stpeter
+1, and I say that for all XML documents, really. It should be something at the XML level...
1 year, 2 months ago by melo