Re: How to manage i18n resource with API / JSON-LD / Hydra ?

Hi Markus,

Sorry for my late response, (pretty busy).
I think, we can already discuss about GET a i18n ressource and when we are
completely agree, I will update my complete document with your suggestions.

> using DunglasApiBundle.
>
> Cool! If you can share some more details, please do so.
>
>
Yes ! It's really a cool symfony bundle ! I will write a message in the
topic soon.


> > Imagine you have a "Country" (http://schema.org/Country) resource in
> your API.
> > How to manage i18N on it ?
>
> So we are talking about concepts which have localized descriptions. This
> is (sometimes) an important distinction as, let's say, a translated blog
> post is really a different resource.
>

Yes, we speak about same resource like a country.


> Let's make this clearer. There are n URLs, one for each localization. In
> the case of things like countries this is tricky and probably not the best
> design. Assume you addresses for Italian and English customers. Do you
> really want to link different resources just because they speak different
> languages?
>
>   { "@id": "/italian-addres", "country": "/francia" }
>
> vs.
>
>   { "@id": "/english-addres", "country": "/france" }
>
> I deliberately didn't use query parameters here.. it simply doesn't matter
> whether it is "just" a query parameter or some other part of the URL that
> differs. You would need to reconcile those to resource with something like
> "sameAs" to tell a machine that they are really identifying the same
> concept.
>

Ok, I am totally agree : one resource (eg :
http://references.com/countries/france ) must have only one URI. (it's the
base of linked data)
My main objective is : how to provide to the client string data on the
resource in his own language if available.


> > ### Sample 1 : No locale specified
> >
> > GET http://api.example.com/countries/1
> > ```json
> > {
> >   "@context": {
> >     "@base" : "http://schema.org",
> >     "name" : {
> >       "@container": "@language"
> >     }
> >   },
> >   "@type": "Country",
> >   "@id": "/countries/1",
> >   "name": {
> >     "fr-FR" : "Angleterre",
> >     "en" : "England"
> >   }
> > }
> > ```
> > => Will return resource with all locale data
>
> >From a linked data perspective this would be preferable I'd say. You can
> still only return a partial view on the resource with content negotiation
> (Accept-Language)
>

Ok, so instead of using a GET parameter to "limit" languages in the
response, prefer using HTTP-Accept-Language header to determine the limited
locale to return.

So you confirm, that for the url :
http://references.com/countries/england

These two json response can be "equivalent" and valid, the second is just
partial :
{
  "@context": {
      "@base" : "http://schema.org",
      "name" : {
         "@container" : "@language"
      },
    "@type": "Country",
    "@id": "http://references.com/countries/england",
    "name": {
      "fr-FR" : "Angleterre",
      "en" : "England"
    }
}

{
   "@context": "http://schema.org",
   "@type": "Country",
   "@id": "http://references.com/countries/england",
   "@language": "fr-FR",
   "name": "Angleterre"
}

One other question is : for the actual defined schema (on schema.org for
example), we can suppose that every "string" field can be
internazionalizable ?


Thanks for your help !

---
Mikael Labrut
06 78 47 47 85
Skype : labrut.mikael