As a user I want to be able to record senses of a lexeme. For the lexeme "to go" this could be "to move through space". I want to be able to say more about each of the senses to for example provide a quote that uses the lexeme in this sense.
@Jan_Dittrich: this is how it would like now, if I try to make it look exactly as form representation (FTR: I am not saying it should look the same, e.g. glosses would most likely in general be longer etc than representation)
I just realized this screenshot actually is quite bad as it does not show the Senses section in the context of the whole page. OTOH the current looks of the page is not really something that is pretty in any way, and I guess it might not be the best idea to try to focus on existing stuff when designing new things.
Does this need to have a full design
I guess we could go with the above for the "read" mode for now, although I am quite convinced we agree this is not the way we want it.
There is no "edit" mode designed currently at all but we could say let's have a big enough text field for now.
What has not been designed so far, and I think there is nothing somewhat similar in the existing UI we could try to reuse for now is the fact that a single gloss would be available in multiple language (ie. there should be a "description of what a word means" in all language, not just the language the "word" comes from). So there should be a way to change the language of the gloss shown, or to show multiple language "versions". And also it should be possible to add/edit/delete glosses in multiple languages, not just my current UI language.
So I guess the answer to your question would be: at least "language switching" should be designed but if we could have all that would be amazing.
- I believe "Statements" header would be needed, unless we really want to make Sense look different than say Forms, or the "top" Lexeme in the regard of how they statements are rendered.
For instance, there might be more than single "Example" statements, translations will be modelled as statements, and there will plenty of other statements involved. Without a header that might be difficult to be rendered in a somewhat reasonable way, I guess.
- Regarding list-like vs. header-like appearance: if we want to only show senses in a single language at once (as in the mock up), then it should be clear that the language name there is something that could be changed. In this case list seems to be obviously suggesting "change me".
- When the language is changed I would say only sense list should be change. It is, I would not expect the language of the whole UI to change when this happens. Not sure, if this was something you had in mind.
I believe "Statements" header would be needed, unless we really want to make Sense look different than say Forms, or the "top" Lexeme in the regard of how they statements are rendered.
Yes, I was just thinking that it is a rather technical term and I wondered if we can get along without (since the hierarchy would still be clear)
Copying over from: https://phabricator.wikimedia.org/F8445148
For display, we shouldn't need a language selector here. The senses (glosses) would be shown in the user's UI language, with language fallback applied.
The selector only becomes relevant when trying to edit, or rather, when trying to translate a gloss into another language.
Hmm, OK, is there a scenario for it or something else that puts this into context? It is hard for me to understand what this is aiming for on a mid level of "what should the user be able to do with it"
After talking about it in the team:
- We currently have the standard of showing text in the UI language, and, if one is logged in, in other, selectable languages, too (@daniel, @WMDE-leszek correct me if that is wrong)
- This would be violated by a new kind of language selection
- @thiemowmde said, that while providing a standard solution, the current way causes usability problems
- Given the timeframe to Wikimania, one could go with the current standard solution, though we should keep in mind that it has it's problems and might not be great for the Lexeme usecase(s), either.
- @Lydia_Pintscher maybe this is different than the usual case of labels.
- In addition to what we have for labels etc. we, in addition, have lexeme language.
- @daniel: What about 2 languages, lexeme and UI.
- Suggestion mid-term: See what usecases the people at Wikimania might want to do.