@Dbrant
Are we able to include functionality to define in another language?

@Dbrant
Also checking out wiktionary pages, they are quite messy. Hopefully we can skip over sections like Pronunciation and Etymology if they are present, but there isn't a standard structure.
I also think we can remove any templates to clean it up.

Questions from @Niedzielski

1. Were you wanting the Wiktionary buttons to have a stock ripple effect or the translucent effect like link preview?
2. I forgot that many words will have sizable content! Just to confirm, tapping "full definition" is expected to take you to Wiktionary word article which is expected to look something like a Wikipedia article?
3. Do we want to show whether the word is a noun / verb / etc? What about pluralization and IPA? Is that secondary text?
4. Do we want a dismiss button on the Wiktionary sheet since it's nonmodal or will users know to swipe that away when they're done?
5. Do we want to limit how much we show? For example, the noun "dog" has a list of 12 definitions.

Screenshots from other apps
.
Kindle

New York Times

Maybe the highlight will be sufficient context, but I think that having the word in the title would be even clearer. Either way it should be trivial to change this detail later.

I agree with @Niedzielski that the word for which we're fetching definitions should be the dialog title.

Further thoughts on "Questions from @Niedzielski" above:

2. I forgot that many words will have sizable content! Just to confirm, tapping "full definition" is expected to take you to Wiktionary word article which is expected to look something like a Wikipedia article?

I envisioned this with the "full definition" menu option launching a browser to view it in the mobile website, at least in the initial version of this feature.

I haven't tested this, but I would imagine, as is the case with Talk pages, that our existing section-based loading strategy would actually handle Wiktionary pages pretty well for the most part, though I've seen at least one infobox-like construct for which we'd have to write a JavaScript handler.

3. Do we want to show whether the word is a noun / verb / etc? What about pluralization and IPA? Is that secondary text?

Wiktionary appears to provide definitions, grouped by part of speech, in order of commonness of use, and in my view this is sufficient. I don't think we'll be able to detect the part of speech from a word's usage in the article anytime in the foreseeable future.

(@Niedzielski, in T114494#1723934, are you envisioning Parsoid emitting all of these part-of-speech annotations? How would they be generated?)

4. Do we want a dismiss button on the Wiktionary sheet since it's nonmodal or will users know to swipe that away when they're done?

Swiping away is a common enough action in the Android UI that I would imagine most users would do so intuitively, but this might be a good candidate for an A/B test.

5. Do we want to limit how much we show? For example, the noun "dog" has a list of 12 definitions.

I'd rather set a max dialog height and make the content scrollable than arbitrarily limit the definitions shown.

@KHammerstein @Dbrant @Niedzielski : what do you think of making the button title "View full definition" to make it more of an invitation to action?

@Mholloway
Thinking about how definitions will be accessed. There's not a clear icon that means "define" that we could add to the top toolbar.
In marshmallow we can have an in-context menu with words instead of icons.
Mocks:
A user first selects a word

Can we make an in-context menu?
Not sure if selection and menu should disappear when definition drawer appears. Maybe it should be modal, menu and selection disappear and background grays out.

Hi @KHammerstein,

I agree that a context menu and modal dialog behaving as you describe makes more sense -- actually, @Dbrant and @Niedzielski and I had a quick chat about it last week and that's exactly what I'm building at the moment.

That only leaves the question of what to do about a "define" icon. It's too bad we're already using a book icon to mean "fair use" in the image licensing context, because that's the most appropriate one I can think of.

Or were you envisioning creating a floating context menu for pre-Marshmallow versions? I imagine that would be a fair bit of work in its own right.

@Mholloway
Ok, so we can go with a floating context menu for marshmallow and regular toolbar for pre-marshmallow. I'll work on an icon!

@KHammerstein Sounds good! Here's where I'm at now:

Here's the result when I create the png icons with our python script:

:(

This is how the generated png for xhdpi looks like on my system:

Here's the result when I run it:

Change 259173 had a related patch set uploaded (by BearND):
Wiktionary definition icon

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

Change 259173 merged by jenkins-bot:
Wiktionary definition icon

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

Thanks @bearND for the icon patch! @KHammerstein, here's a couple of screenshots of the latest work in progress (including the icon as well as HTML formatting in the popup):

Never mind, I just inverted the colors from the previous file and the result looks good, I think!

@KHammerstein - latest screenshots (with new menu icon):

@Mholloway Looks good!
Could you change icon color on drawer to #777777?

@KHammerstein Sure, how's this?

@Mholloway Perfect!
Sorry I noticed something in this last screenshot that I forgot about - I wanted to set an initial height constraint. Should I give you a number in pixels, or can we do a height of 1/3 of the screen?

@KHammerstein 1/3 of the screen makes sense and is I think not too tricky to do. I'll play with it and update in a bit!

@KHammerstein Like so?

@Mholloway
That looks great, I think its done!

\o/