You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When using a "vocab" initiative property (AKA field) in mykomap, the value stored is an identifier (a URI), but the display value is defined by the vocab's tables of terms for the target language (if it exists).
There is nothing which requires there to be a full set of terms for each language.
When it doesn't exist, either a blank or the text undefined is displayed (depending on the code and the situation). This needs to be prevented.
The problem is also that it is not very visible in the UI if some terms are missing, unless you look in the right place.
Describe the solution you'd like
For vocabs, we could add runtime checks that ensure that all the terms are defined in the language (or languages) we plan to support. These could be made in the mykomap app, but also in the code which generates the vocabs in the datafactory. Both is probably advisory.
For other language terms, which are constant and depend on only the app's UI, runtime checks could also work, but there is also the possibility to use type checks to mandate that all the slots for the required terms are set.
It also occurs to me that we could supply these latter language terms as a vocab just like any other. This would have the benefit of making mykomap more language agnostic, as currently the set of languages (as well as the set of terms) are baked in to the code. This would allow the languages to be unhardwired (if not the terms).
Also, the failure mode, if it can't be avoided entirely, should not just be to show "undefined", or nothing, but either the English term - and/or a language specific "untranslated" value.
Possibly a config option could switch between a strict / explicit failure mode in which errors are made visible, and a relaxed mode in which it fails over to something (the English value) without making that an explicit error.
Describe alternatives you've considered
See the previous section.
Additional context
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
When using a "vocab" initiative property (AKA field) in mykomap, the value stored is an identifier (a URI), but the display value is defined by the vocab's tables of terms for the target language (if it exists).
There is nothing which requires there to be a full set of terms for each language.
When it doesn't exist, either a blank or the text
undefined
is displayed (depending on the code and the situation). This needs to be prevented.The problem is also that it is not very visible in the UI if some terms are missing, unless you look in the right place.
Describe the solution you'd like
For vocabs, we could add runtime checks that ensure that all the terms are defined in the language (or languages) we plan to support. These could be made in the mykomap app, but also in the code which generates the vocabs in the datafactory. Both is probably advisory.
For other language terms, which are constant and depend on only the app's UI, runtime checks could also work, but there is also the possibility to use type checks to mandate that all the slots for the required terms are set.
It also occurs to me that we could supply these latter language terms as a vocab just like any other. This would have the benefit of making mykomap more language agnostic, as currently the set of languages (as well as the set of terms) are baked in to the code. This would allow the languages to be unhardwired (if not the terms).
Also, the failure mode, if it can't be avoided entirely, should not just be to show "undefined", or nothing, but either the English term - and/or a language specific "untranslated" value.
Possibly a config option could switch between a strict / explicit failure mode in which errors are made visible, and a relaxed mode in which it fails over to something (the English value) without making that an explicit error.
Describe alternatives you've considered
See the previous section.
Additional context
The text was updated successfully, but these errors were encountered: