|Resolved||Dbrant||T207338 [EPIC] Suggested edits V2 (Add/edit/translate image captions)|
|Resolved||cooltey||T224051 Add image captions in “Suggested edits”|
|Resolved||Dbrant||T224501 Add voice input to cards (captions and descriptions)|
@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).
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
- 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.