Page MenuHomePhabricator

Add voice input to cards (captions and descriptions)
Closed, ResolvedPublic1 Estimated Story Points

Event Timeline

Charlotte created this task.
Charlotte set the point value for this task to 1.
Charlotte lowered the priority of this task from Medium to Low.May 28 2019, 4:56 PM

@Dbrant, I was only able to have a look at it for descriptions yet, since captions are not yet available. I have the following questions:

  • There’s a discrepancy in capitalizing the first letter when using keyboard vs voice input. Keyboard input capitalizes the first letter, voice input doesn’t. Can we keep it consistent? The guidelines suggest to only capitalize the first word if it’s a proper noun, but I guess detecting that would add too much complexity. So I suggest to just capitalize the first letter, since I assume that it’s a more common case. What do you think?
  • Is it possible to top align the microphone icon in the input field so it does not move down when there are multiple lines of text? It’s currently bottom aligned and moves with the text. The less movement, the better.
  • Just to make sure, is the touch target size of the microphone button/icon at least 48x48dp ? (Can’t verify since I haven’t setup Android Studio on my old/new laptop).

image.png (234×258 px, 8 KB)

Thanks!

In T224501#5223554, @schoenbaechler wrote:

I suggest to just capitalize the first letter, since I assume that it’s a more common case. What do you think?

@schoenbaechler - The more common case would probably be to not capitalise the first letter. There was, as @Lydia_Pintscher mentioned, some significant annoyance about this. So if we can avoid capitalising the first letter, that would be grand.


T131013 for background reading if interested

Thanks for chiming in @Charlotte (& @Lydia_Pintscher). Sounds good, as long as keyboard and voice input are consistent.

as long as keyboard and voice input are consistent.

Unfortunately they are not. Voice input does not follow the same IME rules as keyboard input.

as long as keyboard and voice input are consistent.

Unfortunately they are not. Voice input does not follow the same IME rules as keyboard input.

What does this mean in practical terms? Can we not lowercase the first letter by default on voice input?

What does this mean in practical terms? Can we not lowercase the first letter by default on voice input?

Oh, the voice input will always be lowercase by default. It's the keyboard input that cannot be (consistently) lowercased. This varies by device, manufacturer, OS version, etc.

@Charlotte A slight side note on this:
Supposing there's a way to make the keyboard input lowercase (on most devices)...
The thing is, in the places where we display the description, we actually explicitly uppercase the first letter (even though it's stored in lowercase on wikidata). This was a decision made by previous PMs of old. This is why, when adding new descriptions, the first letter is uppercased for "consistency" with the way they're presented elsewhere in the app.
Do we want to change this behavior?

@Dbrant - Ah, ok - think we might have been talking slightly at cross purposes. What I care most about is that we don't start sending strings with uppercased first letters to Wikidata (unless proper noun obvs) - that's what I was trying to convey, anyway.

Re: the display as a user is typing them in, which (as I understand from what you were saying) is different from what we actually send to Wikidata, I'm happy to leave the behaviour as-is. Which, for that hobgoblin consistency, means we should display the voice input strings with a capitalised first letter if we can. If we can't, then bugger it - I doubt that any but the most pedantic of users will notice anyway. And nobody likes a pedant.

The other option would be to just display the descriptions elsewhere in the app exactly as they are saved in Wikidata, but since we could not consistently ensure that the keyboard input fields lowercased the first letter, this makes things no better.

Re: the display as a user is typing them in, which (as I understand from what you were saying) is different from what we actually send to Wikidata

Not quite:

  • When we display the descriptions elsewhere in the app (in the article, in search, in the feed), we explicitly capitalize it.
  • When we send the edited description to Wikidata, it's sent exactly as it's formatted in the edit box. This will include whatever capitalization Android imposes on the first letter. This would mean that certain descriptions sent from the app will be against the guidelines.

Now, looking at the recent-changes log on Wikidata, it looks like most of the new English descriptions have the correct lowercase first letter, but I will bet that this is because most of these descriptions are copy-pasted from the first sentence of the article. (That's certainly how I generally add descriptions.)

I would actually recommend trying to make Android no longer capitalize the first letter in the edit box.

@Dbrant Thanks for the clarification! Let's then lowercase wherever possible - as I say, priority #1 is to not send unnecessary capitalised strings to Wikidata, and the consistency of display is a secondary goal.

Looks good now @Dbrant! Disclaimer: I was only able to have a look at it for descriptions, since I can’t edit and therefore unlock captions (T224492#5236613).

Thanks for working on this @Dbrant, all issues related to this task are listed in T225635. Moving this to QA signoff.