Feature #2173
closed
API: classes translation
Added by Bernhard Koschiček-Krombholz 8 months ago. Updated 8 months ago.
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.
Updated by Alexander Watzinger 8 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.
Updated by Stefan Probst 8 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" }
]
}
Updated by Stefan Probst 8 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 (?) |
Updated by Bernhard Koschiček-Krombholz 8 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?
Updated by Alexander Watzinger 8 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 ;)
Updated by Stefan Probst 8 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.
Updated by Bernhard Koschiček-Krombholz 8 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".
Updated by Bernhard Koschiček-Krombholz 8 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.
Updated by Stefan Probst 8 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.