Page MenuHomePhabricator

[Story] Improve input for monolingual text
Open, MediumPublic

Description

As an editor I want a better experience for inputting monolingual text.

We must come up with a better way and write it down here.

This topic is related (T111022)

Event Timeline

Lydia_Pintscher raised the priority of this task from to Medium.
Lydia_Pintscher updated the task description. (Show Details)
Lydia_Pintscher added a subscriber: Lydia_Pintscher.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 18 2015, 3:48 PM

Reassessing that: As mentioned before regarding the basically wiped out unit selector discussion, still, the general idea should be to not require two input fields at all by having the software detect the unit from the combined string of value and unit. The (rest of the) procedure is described in T103835. The same would actually be possible for monolingual text by having the software detect the language.
Multilingual text is a value that very likely would require multiple inputs.

Nikki added a subscriber: Nikki.Aug 19 2015, 8:02 AM

I agree that having a single field and parsing the units out of the input would be the most intuitive way to enter values with units (although I think it and the existing date parser also need a way to offer multiple options to the user for ambiguous strings, like "10 m" can mean 10 metres or 10 miles and 01/02/2003 can mean the 1st of February or the 2nd of January), but I'm not sure how you see it working for the language field for monolingual text. How would it actually detect the language? How would the user change it if it picks the wrong language? A second field of some sort seems necessary there and two normal fields seems better than the existing floating field.

Snaterlicious added a comment.EditedAug 19 2015, 11:39 AM

We could just ask Google: https://cloud.google.com/translate/v2/using_rest?hl=en#detect-language
Well, no, but detecting a language is feasible. Just like for units, it is about making a proper "best guess" that is influenced by various parameters in addition to the actual input. Such a "best guess" could, of course, be altered (see T103835#1423985).

I strongly suspect that making a remotely reliable "best guess" on the language based on the content is completely unfeasible. Google's accuracy is awful and only works at all for very few languages (compared to the hundreds or thousands that need to be supported), and if we try to make our own it will likely be substantially worse.

I think we should have a story for each monolingual text and quantities with units to make things more clear and be able to differentiate.

Jonas renamed this task from [Story] Improve input elements for monolingual text and quantities with units to [Story] Improve input for monolingual text.Sep 1 2015, 10:26 AM
Jonas updated the task description. (Show Details)
Jonas set Security to None.
Jonas updated the task description. (Show Details)Sep 1 2015, 10:29 AM
Charlie_WMDE added a comment.EditedDec 7 2017, 2:52 PM

@Lydia_Pintscher

I am trying to understand the issue here and it's not very clear to me from the comments or the ticket description. I am also not clear on what role quantities and units play, as mentioned in the comments above.

Would it be possible to update the descriptions based on this template to make the ticket understandable from someone not familiar with the topic?

User Story: As a user, I want to _________ so I can _________

Context of use: I assume the user would like to _______ because___

Current Problems: Currently, _________. This is not good, because ________

Possible Solution: One way to improve the situation for the user is