OpenAtlas

I'm not sure about the details but I also wanted to add that the table Stefan (Probst) has shown was a mix between OpenAtlas class names and an English translation of the corresponding CIDOC classes.
For the frontend translation the OpenAtlas classes would be needed because I assume cooperation partners want the same "structure" represented as seen when they entered their data. But of course the CIDOC translation would be needed too in case somebody wants to show them.

i'd suggest to add a locale query parameter to control the language of systemclass labels.

for example /api/classes/?locale=de would then return:

{
  "locale": "de",
  "results": [
    { "systemClass": "source", "label": "Quelle" }
  ]
}

also, i had a quick look at the current german systemclass translations, some are missing or could be improved i think:

Since I don't want to raise the API version again, I would add a new endpoint /api/class_mapping and will deprecate /api/classes.

I would suggest this solution without a new locale parameter, since you will need all translations anyway:

{
  "results": [
    { 
      "systemClass": "source",
      "crmClass": "E33",
      "view": "source",
      "standardTypeId": "39",
      "icon": "mdi-text-box",
      "locale": {
         "de": "Quelle",
         "en": "Source",
         "ca": "",
         .....
       }
    },
    {
      ....
    }
  ]
}

But I don't know how you deal with translations in the frontend, so I'm also happy to implement your solution Stefan.

Are more information about the classes needed?

I would suggest this solution without a new locale parameter, since you will need all translations anyway:

not necessarily. yes, currently translations for system classes are used at build time, so we do need to get all supported translations.

however, i can imagine scenarios where we fetch these lazily at runtime, and then we'd want to only fetch translations for the currently selected language.

in any case, no strong feelings about this.

Stefan Probst wrote in #note-6:

I would suggest this solution without a new locale parameter, since you will need all translations anyway:

not necessarily. yes, currently translations for system classes are used at build time, so we do need to get all supported translations.

however, i can imagine scenarios where we fetch these lazily at runtime, and then we'd want to only fetch translations for the currently selected language.

in any case, no strong feelings about this.

Good point. As I said today to the frontend team, I'm not the user of the API, so I don't think in frontend developer terms. I will implement this and give it in swagger under a new tag named "proposal".

One question: which has more weight, a parameter or the request header? Because if I make both possible, one has to outweigh the other if they are different.

do you mean the "Accept-Language" header? imho query param should have higher priority than request header.