How to manage i18n resource with API / JSON-LD / Hydra ? about core

[StephenOTT]

Any further progress on this?

[dunglas]

Wow, nice work on that topic! It looks good!

There is just one thing that hurts me: a resource is represented by an URL, so a translation is not a resource by itself but just a part of a resource. So what about issuing a PUT request to remove a lang but not the whole resource as it's just the modification of an existing resource?

3 other small questions:

• How the language support will be described in the Hydra vocab?
• Is an integration with DoctrineExtensions / DoctrineExtensionsBundle planned? How they will fit together?
• What do you think about sending a mail on the Hydra or JSON-LD mailing-list to be sure that everything is OK from a spec point of view?

Cannot wait to see the code 😅

[MLKiiwy]

Yeah, it's a good point of view for the PUT section.

Maybe to remove a translation use DELETE with a new endpoint ? Like the last point.

• How the language support will be described in the Hydra vocab?

I don't know, it's a real interrogation for me ...

• Is an integration with DoctrineExtensions / DoctrineExtensionsBundle planned? How they will fit together?

I think the base dev must be independant of these bundle. But we must propose an implementation to use these bundle quickly and simply.

• What do you think about sending a mail on the Hydra or JSON-LD mailing-list to be sure that everything is OK from a spec point of view?

Good idea, but where is the M-L ?

[MLKiiwy]

I study another possibility to provide the i18n support on a resource.
To add a collection of translation when needed.

For example :

GET http://api.example.com/countries/1?locale=fr-FR

{
  "@context": "http://schema.org",
  "@type": "Country",
  "@id": "/countries/1",
  "@language": "fr-FR",
  "nonLocalizedAttribute": 10,
  "localization": {
    "@type": "CountryLocalization",
    "@id": "/country_localization/1/fr-FR",
    "name": "Angleterre"
  }
}

GET http://api.example.com/countries/1

{
  "@context": "http://schema.org",
  "@type": "Country",
  "@id": "/countries/1",
  "nonLocalizedAttribute": 10,
  "localizations":{ 
     "en": {
         "@type": "CountryLocalization",
         "@id": "/country_localization/1/fr-FR",
         "name": "Angleterre"
      },
     "fr-FR": {
         "@type": "CountryLocalization",
         "@id": "/country_localization/1/fr-FR",
         "name": "England"
      }
}
}

This way he simpler for many reasons, but I think it's not very JSON-LD / Hydra compliant.
It's simpler because :

• you cut the "localized" part of the resource into separate resource, wich can be managed like other resources.
• "Like the DB storage"

It's not JSON-LD / Hydra compliant because :

• you change structure of object ( localization / localizations attribute is dynamical ... ), you cannot use schema.org vocabulary because of that

What do you think about this ?

[MLKiiwy]

@dunglas if you want to view, here is my work but still in dev : https://github.com/MLKiiwy/DunglasApiBundle/tree/tdd-i18n-support

[dunglas]

Nice to see progress on that :)

I prefer to keep with the standard: it's the only way to be interoperable with other systems (client-side JSON-LD / Hydra libraries, search engines...).

Maybe the best thing to do is to create thread on the Hydra working group about that. You can register to the mailing list on the Hydra website (you just need a W3C account): http://www.hydra-cg.com/

[nicolasricci]

@MLKiiwy very interesting approach to handle localized content.
@dunglas is there any plan to include this enhancement in the bundle?

[Simperfit]

@MLKiiwy have you gone further with this ?

[MLKiiwy]

No sorry, I stop my development on this part because I don't need it anymore :/ but the solution is still valid but must be implement in the new version of api-platform core. maybe as a plugin ...

[dkarlovi]

Is this the "front line" regarding API Platform and I18N or am I missing something somewhere?

[MLKiiwy]

No it was an old subject. I will close this.