Project

General

Profile

Actions

Feature #2173

closed

API: classes translation

Added by Bernhard Koschiček-Krombholz 5 months ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Category:
API
Target version:
Start date:
2024-02-09
Estimated time:
Cooperation:

Description

For the endpoint /classes is currently only the English name of the classes available. It would be beneficial, that all available languages are shown.

Actions #1

Updated by Alexander Watzinger 5 months ago

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.

Actions #2

Updated by Stefan Probst 5 months ago

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" }
  ]
}
Actions #3

Updated by Stefan Probst 5 months ago

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

system class en de de (suggested)
------------------- ------------------- ------------------------ --------------------------
acquisition Acquisition Erwerb
activity Activity Aktivität
actor_function Actor function Akteur Funktion Akteursfunktion
actor_relation Actor relation Akteur Beziehung Akteursbeziehung
administrative_unit Administrative unit Administrative unit Verwaltungseinheit
appellation Appellation Benennung Bezeichnung
artifact Artifact Artefakt
bibliography Bibliography Bibliographie
creation Creation Creation ???
edition Edition Edition
event Event Ereignis
external_reference External reference Externe Referenz
feature Feature Feature is this a geojson feature?
file File Datei
group Group Gruppe
human_remains Human remains Menschliche Überreste
involvement Involvement Involvement Beteiligung
modification Modification Modification Modifikation
move Move Move ???
object_location Object location Object location Objektstandort (?)
person Person Person
place Place Ort
production Production Production Produktion
reference_system Reference system Referenz-System Referenzsystem
source Source Quelle
source_translation Source translation Quellübersetzung Quellenübersetzung
stratigraphic_unit Stratigraphic unit Stratigraphische Einheit
type Type Typ
type_tools Type tools Type tools Typ-Werkzeuge (?)
Actions #4

Updated by Bernhard Koschiček-Krombholz 5 months ago

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?

Actions #5

Updated by Alexander Watzinger 5 months ago

  • Status changed from Assigned to In Progress

I updated the translations (thanks Stefan for suggestions in the table before) in the develop branch.
So now they should all be available in German via gettext.
Of course we still have to solve the other issues but we should be one step closer ;)

Actions #6

Updated by Stefan Probst 5 months ago

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.

Actions #7

Updated by Bernhard Koschiček-Krombholz 5 months ago

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".

Actions #8

Updated by Bernhard Koschiček-Krombholz 5 months ago

  • Status changed from In Progress to Closed

Pushed solution in develop branch. Is in /swagger under Proposal tag.

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.

Actions #9

Updated by Stefan Probst 5 months ago

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.

Actions

Also available in: Atom PDF