Feature #1925
open
Multi language support for data entering
Description
Being able to add translations to entered data would enhance OpenAtlas enormously.
Nevertheless, the adaption of the user interface has to be planned carefully to keep it usable and clear.
Updated by Alexander Watzinger over 1 year ago
- Description updated (diff)
- Status changed from Acknowledged to Assigned
- Assignee set to Stefan Eichert
- Target version changed from Wishlist to 8.0.0
Assigning to Stefan who had some ideas.
Name translations could be solved similar to external reference systems but we still have to work out how to deal with description translations.
Ideally we can solve it via a CIDOC mapping and implement it using new OpenAtlas classes.
Updated by Alexander Watzinger about 1 year ago
- Status changed from Assigned to Acknowledged
- Assignee deleted (
Stefan Eichert) - Target version changed from 8.0.0 to Wishlist
Although there were some good initial ideas we still haven't solved translation for descriptions.
Since there was now progress for a few month (either conceptual or otherwise) and we are currently more involved with annotation features, I move this issue back to the wishlist for now.
Updated by Alexander Watzinger 3 months ago
Vera kindly gave some interesting input, e.g.:
E1 CRM Entity -> P1 is identified by -> E41 Appellation -> P2 has type -> E55 Type
taken from the Sari documentation
We could simplify it in the database with:
E1 CRM Entity -> P1 is identified by -> E41 Appellation
where the appellation entity has the translated name and description (similar how entities are used now), the language could be the link description (which in turn has defined range of languages).
One difference to the former solution would be that we would need one additional entity for every translated name/description pair but at least we could solve the description with it.
Updated by Alexander Watzinger 3 months ago
Vera also shared a link to an interesting CIDOC CRM discussion
My take from that is that we can refine my previously suggestion to:
E1 CRM Entity -> P1 is identified by -> E41 Appellation -> P2 has type -> E53 Language
This would be way cleaner and we could introduce a system type language which would be easier to manage.
Of course this opens up immediate other questions like:- Can the language types than have translations as well
- How great will be the performance be impacted e.g. if listening hundreds (or thousand) of places with all their translations in one request, ...
- And all the other connected challenges like: how is the default language defined, what to deal with missing translations, ...
But I like where this is going and we can take it one step at a time.
Updated by Alexander Watzinger 3 months ago
- Start date changed from 2023-01-08 to 2023-09-26
- Follows Feature #2079: Text annotation added
Updated by Bernhard Koschiček-Krombholz 3 months ago
Veras solution works for names and types, but not description.
A solution how we model the description field would be:
E1 CRM Entity <- P67 refers to <- E33 Linguistic Object -> P72 has language -> E56 Language
The technical implementation will be another issue.