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
I guess using wildcards is a possible way, but it is somewhat too simplistic. If you think of how far conjugations can differ from the infinitive in many languages, e.g. in German schaffen can become geschafft, schaffte, schuf, the only viable way is to have modules that generate possible word forms of an infinitive for a specific language.
Ideally these modules would be reusable across various h5p content types (I could use them for my project on an advanved fill the blanks content type as well) and have a common contract, allowing language-agonistic content types. The content author could simply choose from a list of supported languages.
Wow, thanks for the quick feedback! Didn't know you were folliwing the issues.
The wildcard solution was a request that was mentioned at the H5P conference (I think from someone from Finland where it might be different). Please keep in mind that I'm not trying to "build Rome in one day". You are absolutely right, and your idea would definitely work better, but nothing that I can accomplish right now with the spare time I can invest. I am rather trying to put "everything" in the first release that's necessary to let it work fairly well in practice (hopefully).
In addition to fuzzy comparison, allow wildcards (at the beginning or the end of a keyword) that may be very useful for language learning.
Smartest way? Use the * in the text field? If we do that, we might as well think about replacing the GUI keyword alternative addition with a |
The text was updated successfully, but these errors were encountered: