Subject: syntax for bilingual page

From: Yves Dorfsman <[email-masked]>
Date: Thu, 02 Sep 2010 00:24:42 -0600

Hi,

Is there a proper way to specify a title and an summary for an entry in two 
different language?

I have tried to specify two title and summary with different xml:lang="xx" in 
the same entry but it does not validate, and aggregators get confused.

I have tried different combination of html and xthml with <div lan="xx">, but 
again, when I do manage to make those validate, the aggregators just print 
both on the same line.

Finally I created two entries, both with the same ID, update and link, but 
with a different lang tag <entry xml:lang="xx">, and different title and 
summary. This seems to be the cleanest, but the aggregators see those as two 
separate entries...

Thanks.

-- 
Yves.                                                  http://www.SollerS.ca/
                                                        xmpp:[email-masked]

---

From: Yves Dorfsman <[email-masked]>
Date: Sat, 04 Sep 2010 08:28:25 -0600

I haven't received any reply, but a quick glance at the archive shows that 
this list is active.

Does my question make sense?

Or is it just that there is no way to do this with atom?

Should atom be extended / revised to allow something like this to be done?

Or is the problem the aggregators that show both entries with the same id but 
different languages? If that's the best way to do it, should we spread the 
word (document better) so that aggregators authors start taking it into account?

>
> Is there a proper way to specify a title and an summary for an entry in
> two different language?
>
> I have tried to specify two title and summary with different
> xml:lang="xx" in the same entry but it does not validate, and
> aggregators get confused.
>
> I have tried different combination of html and xthml with <div
> lan="xx">, but again, when I do manage to make those validate, the
> aggregators just print both on the same line.
>
> Finally I created two entries, both with the same ID, update and link,
> but with a different lang tag <entry xml:lang="xx">, and different title
> and summary. This seems to be the cleanest, but the aggregators see
> those as two separate entries...

---

From: Erik Wilde <[email-masked]>
Date: Sat, 4 Sep 2010 07:46:20 -0700

hello yves.

On Sep 4, 2010, at 7:28, Yves Dorfsman <[email-masked]> wrote:
> Or is the problem the aggregators that show both entries with the same id but different languages? If that's the best way to do it, should we spread the word (document better) so that aggregators authors start taking it into account?
>> 

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

cheers,

dret.

---

From: Yves Dorfsman <[email-masked]>
Date: Sun, 05 Sep 2010 11:34:32 -0600

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

Most large websites support more than one language with the same URL, based on 
the browser preference.

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

---

From: Erik Wilde <[email-masked]>
Date: Sun, 05 Sep 2010 19:39:24 -0700

hello yves.

> Why couldn't we extend / update the atom format to support 

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 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
        [email-masked]  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)

---

From: eric scheid <[email-masked]>
Date: Wed, 08 Sep 2010 10:28:09 +1000

On 5/9/10 12:46 AM, "Erik Wilde" <[email-masked]> wrote:

> internationalization, but makes life easier for consumers. as unfortunate as
> it is, it's not going to change (i guess), 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...

you could either link the entire feed to a translated feed, or link just the
entry to a translated entry document. I'd do the former generally.

<feed>
   <link rel="alternate" type="application/atom+xml"
    hreflang="fr" href="http://example.org/fr/feed.xml"/>
   <entry>
       <link rel="alternate" type="application/atom+xml"
        hreflang="fr" href="http://example.org/fr/entry.xml"/>
   </entry>
</feed>

---

From: Felix Sasaki <[email-masked]>
Date: Wed, 8 Sep 2010 08:57:52 +0200

Hello Yves, all,

there is a reason that you don't have such facilities in many text oriented
formats (also HTML, DocBook, DITA): versions in different languages are
often created via translation with many participants: creators of original
content, localization engineers preparing often a lot of documents (or
speaking more generally "pieces of content") for localization, translators /
localizers doing the actual translation etc., quality assurance people etc.
And in this chain of content processing of course there are also cycles
possible, e.g. from the QA people to the translators ...

The participants in this chain would have a hard life if they would have to
know every format in detail and would have to edit the formats directly. For
this reason, normally content to be localized is extracted from various
source formats, and at the end of the workflow put into the original again.
A standard to manage that workflow is XLIFF, see the example in sec. 2 at
http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#SectionStructure .
Using XLIFF and setting up such a localization chain might be an overkill
for your problem, but maybe a sustainable solution which you then can easily
use for additional formats, not only Atom.

Best,

Felix

2010/9/2 Yves Dorfsman <[email-masked]>

> I have tried to specify two title and summary with different xml:lang="xx"
> in the same entry but it does not validate, and aggregators get confused.
>
> I have tried different combination of html and xthml with <div lan="xx">,
> but again, when I do manage to make those validate, the aggregators just
> print both on the same line.
>
>                                                       xmpp:[email-masked]<[email-masked]>
>
>
>

---

From: Yves Dorfsman <[email-masked]>
Date: Wed, 08 Sep 2010 01:38:52 -0600

Thanks for all the help and suggestions, I ended up setting up two separate 
feeds as suggested.I created atom.xml.en and atom.xml.fr, and setting up 
apache to send whichever based on http language negociation for atom.xml. I 
also used the .en and .fr in the links in the html pages as I don't trust the 
aggregators to have a language preference.