Open lajanda opened 4 years ago
I agree, this makes sense (compute and display a list based on the abbreviation). I am postponing this a bit however and will prioritize other issues first.
Looking at this after a while. I understand the problem of possibly too long list. But right now there is already a mouse-over which spells out the abbreviations but what you suggest here is something different?
What we have works fine for Russian. I am just thinking ahead to other languages where there could be thousands of combinations, so it would be better to start from building blocks. But maybe it is better to leave this aside and see if we get the COST funding?
I was just wondering whether this is not already done (except of maybe removing the overview page with all abbreviations).
But definitely no problem to leave this for a while.
Oh, maybe that is already in your code and I just had no idea. I apologize.
There is a mouse-over which "explains" abbreviations. But perhaps that's not what you meant.
At present we have a system whereby we use abbreviations of grammatical categories like Imperf.Masc.Sing.Past that are spelled out in the List of abbreviations and by mouseover, as in this example: Imperfective Masculine Singular Past For the original purpose of a SMARTool for Russian, this is ok. However, I am thinking about other languages like Finnish and North Saami where the number of combinations of grammatical categories is much larger. At that point, it makes more sense to instead list just the building blocks in the List of abbreviations, so that list would only contain individual abbreviations, not combinations, as in: Imperf = Imperfective Masc = Masculine Sing = Singular Past = Past And then to have the mouseover “calculate” the spellout from the individual abbreviations rather than listing every one individually. So it might be better to engineer this now rather than to encounter a problem down the road with languages that present more complex combinations of grammatical categories. For the sake of Russian, we have a little over 100 combinations already (a few more are possible but not attested in our current dataset). So we can do it either way. But it might make sense to change the programming for Russian also since in the future we might want to expand it and might thus encounter some new combinations.