Mulitilingual support

A general version using placeholders of a list request would be

https://www.rijksmuseum.nl/api/{langcode}/collection

with response

 "artObjects": [
    {
      "links": {
        "self": "https://www.rijksmuseum.nl/api/nl/collection/SK-C-5",
        "web": "https://www.rijksmuseum.nl/nl/collection/SK-C-5"
      },
      "id": "nl-SK-C-5",
      "objectNumber": "SK-C-5",
      "title": "Schutters van wijk II onder leiding van kapitein Frans Banninck Cocq, bekend als de ‘Nachtwacht’",
      "hasImage": true,
...

So objectNumber is the id as language should be provided by Drupal.

and item would be

https://www.rijksmuseum.nl/api/{langcode}/collection/{id}

The list items and single item are both processed through the field mapping. Either one fail as list items are in artObjects and singular item has content in artObject next to artObjectPage.

Not sure what is best.

Attached patch adds alterURI code.

You can use (currently) two placeholders:

• {langcode}
• {id}

These can be used like https://www.rijksmuseum.nl/api/{langcode}/collection and is used fetching the list or a single item.

The use of {id} is for discussion as fetching a list or item has currently hardcoded ID position aka appending the ID https://www.rijksmuseum.nl/api/{langcode}/collection/XYZ-12

Using https://www.rijksmuseum.nl/api/{langcode}/collection/{id} as endpoint would fail for the list as ID is empty and is not scrubbed of the endpoint URI yet.

What I tested was

1. Install Drupal default language (EN)
2. Visit http://drupal.d8/rijksmuseum/SK-C-5 it's in English
3. Add language (NL)
4. Set new language (NL) default
5. Revisit http://drupal.d8/rijksmuseum/SK-C-5 it's in Dutch

For me, the patch in #11 works for single items for placeholder {langcode}, I tested with the Rijksmuseum API as well.

With the {id} placeholder I get an 404 on said API, this is because the id is still appended in function `Rest::load($id)` . In this case we could append the ID at the end of the url, only if no '{id}' is present in the configured URL.

The patch to append the entity ID only when there is no '{id}' specified in the endpoint.

Hi guys,

Using {langcode} in External Entities configuration is helpful but it is arbitrary and implies that the API endpoint or parameter is expecting exactly the langcode value

• So this would work : https://www.api-endpoint-example.com/api/de/collection because de={langcode}
• But this would not work: https://www.api-endpoint-example.com/api/german/collection because german!={langcode}

I believe we should adopt a more generic and Drupal-way approach to solve the multilingual need :

• Currently, it is possible to translate a 3 settings of External Entities bundles : Name, Plural name, Description

• What we could do is make all of the External Entities bundles configuration translatable (in the Drupal native way) :
• All configuration settings would be able to take a different value when translated
• Drupal drupal multi language support will handle most of the heavy work to use the relevant config depending on language negotiation settings

That would be very powerful, flexible and support all use-cases I can think of: different endpoints per language, different parameters, different field mapping, etc

+++ b/src/Plugin/ExternalEntities/StorageClient/Rest.php
@@ -274,6 +274,33 @@ class Rest extends ExternalEntityStorageClientBase implements PluginFormInterfac
+  protected function alterURI($uri, $id = NULL) {
...
+    $alteredUri = strtr($uri, $map);
+    $this->logger->debug("altering URI from $uri into $alteredUri");
...
+    return $alteredUri;

I think it could use event or hook to allow mapping for case when locale needs it - another case is pt-BR

Otherwise it will need to decorate/replace plugin for custom needs

Hi guys,

I added a French interface translation.

Following suggestion at #17 I created MR https://git.drupalcode.org/project/external_entities/-/merge_requests/3 where I use config schema to expose "Field Mapping" and "Storage" settings to be translatable on UI.

Thanks @piggito

Patch working as expected !

Thanks for the work, the configuration translation seems the way to go, as it is more flexible and in line with the Drupal way.