Currently, the whole JSON for the entry is displayed, which includes all but 5.

So, we don't want the whole JSON-object to show, but more of an explaining interface for the user?

Example:

Word: “ren”

Part of Speech: “PM”

Paradigm:  "s0c-\u00f6vriga"

Morphology: "||NOM place|GEO"

Transcription: "\" r e: n"

Tag: -

Yes and we probably want to translate some of the terms both in terms of natural language and machine to human readable. E.g. "PM" for "Part of Speech" means "pronoun".

What properties are important, or even present, will likely depend a lot on language. I think we'll have to write mapping between the values and the text to show to the user for each. Adding new languages would include those to.

For now I think it's enough that we have some properties for Swedish and English. Just having the framework in place should make it easier to extend when we need to. And probably keep the JSON string, but maybe hidden behind a "Show advanced details" button.

So, I noticed that most (or any) of the posts in english don't have paradim, morphology or partOfSpeech, so my solution now is to:

if the languague is set to Swedish, then do this new solution, otherwise show the whole JSON-object as before.

What do you think?

Sounds good. I think you'll have to do it by language anyway since properties are relevant or even possible for a word will differ.

I think it's good to always have the possibility to show the raw lexicon data. This means you can get some information even if the nicer UI solution isn't implemented for a language yet.

Change #1150625 had a related patch set uploaded (by Viktoria Hillerud WMSE; author: Viktoria Hillerud WMSE):

[mediawiki/extensions/Wikispeech@master] Show relevant information to user in lexicon post

https://gerrit.wikimedia.org/r/1150625

I think the solution in the latest patch looks fine for a proof-of-concept and as help during development and testing. It certainly looks better than before.

The layout shouldn't use pre-elements with line break and standard UI buttons should be used. We could leave it as it is and create a new task for making it fit for end users. @Viktoria_Hillerud_WMSE, what do you think?

In T277152#11131075, @Sebastian_Berlin-WMSE wrote:

I think the solution in the latest patch looks fine for a proof-of-concept and as help during development and testing. It certainly looks better than before.

The layout shouldn't use pre-elements with line break and standard UI buttons should be used. We could leave it as it is and create a new task for making it fit for end users. @Viktoria_Hillerud_WMSE, what do you think?

Yes, sounds good, but jsut out of curiousity, what could be done better to making it fit for the end users? Is it the look of the UI?

Yes, it should look and behave as close as possible to the rest of the UI (and still work well of course). This would help fulfil at least some parts of "predictable" as defined by WCAG.

That said I don't know if all the special pages in MW core do that so it's not a blocker. If we can re-use standard component we'll also get future improvements "for free", without having to touch our own code.

In T277152#11131270, @Sebastian_Berlin-WMSE wrote:

Yes, it should look and behave as close as possible to the rest of the UI (and still work well of course). This would help fulfil at least some parts of "predictable" as defined by WCAG.

That said I don't know if all the special pages in MW core do that so it's not a blocker. If we can re-use standard component we'll also get future improvements "for free", without having to touch our own code.

Aha, because I thought it was that that this task was already about, to show it in the best way to the user? Or was this task just about the information and not the looks?

I'd say that depends on the use case. Is it something we want mostly to help us during the development and maybe to show some early testers? In that case what we have now is enough. I think that was what we had in mind when we created this task.

If on the other hand we want it to be done as part of the finished product we should make sure it conforms to the UI standards. The risk we're running there is putting work into things that may change later, at least if it turns out to be a lot of work.

I'm leaning towards keeping it as it is for now. We have plenty of other things to work on. Unless you want to take this as an opportunity to learn how to make UI for special pages. That's something we'll need to do more with later on.

In T277152#11131533, @Sebastian_Berlin-WMSE wrote:

I'd say that depends on the use case. Is it something we want mostly to help us during the development and maybe to show some early testers? In that case what we have now is enough. I think that was what we had in mind when we created this task.

If on the other hand we want it to be done as part of the finished product we should make sure it conforms to the UI standards. The risk we're running there is putting work into things that may change later, at least if it turns out to be a lot of work.

I'm leaning towards keeping it as it is for now. We have plenty of other things to work on. Unless you want to take this as an opportunity to learn how to make UI for special pages. That's something we'll need to do more with later on.

Ok! Let's keep it as it is, and then maybe I will create a task that handles the UI regarding this?

Change #1150625 merged by jenkins-bot:

[mediawiki/extensions/Wikispeech@master] Show relevant information to user in lexicon post

https://gerrit.wikimedia.org/r/1150625