Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Protect against undefined vocab / language terms (N) #215

Open
ColmDC opened this issue Jul 15, 2023 · 1 comment
Open

Protect against undefined vocab / language terms (N) #215

ColmDC opened this issue Jul 15, 2023 · 1 comment

Comments

@ColmDC
Copy link
Contributor

ColmDC commented Jul 15, 2023

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

@ColmDC
Copy link
Contributor Author

ColmDC commented Jul 15, 2023

New version of this corrupted Issue/Epic #188

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant