Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Word requests for contextual sentences #1148
Feature: a user submits a word in a foreign language to get back sentences created by native speakers to show how this word can be used.
This feature has been requested many times, I compiled information from the GSoC 2015 page, user scenarios and Trang's use cases and I tried to re-use already existing similar behaviour patterns whenever possible to integrate it as seamlessly as possible with the current structure.
This feature has been called 'wishlist', 'word request'... I chose 'request' because it's clearer than 'wish' and I removed 'word' because it could be misleading, as users could ask for phrases or even sentences. Because Tatoeba is primarily about text, in my opinion it's obvious that the 'default' request is request about text, not about features or questions (if we had a page for feature requests, it should state 'feature requests').
It works in a similar way as adding sentences.
When I add a new request, it appears in the 'Requests added' list below (disappears if I leave the page).
I get a list of all my open, closed and favourite requests.
I can filter them by language.
For each request, I see the language, the notes, the sentences that have been added already and the user.
For the requests I raised, I can edit, delete, close or re-open them.
If there is more than X requests, a pagination will appear. (I only put 4 on the wireframes to make it lighter) Maybe we could start with 10?
I see the open (public) requests.
I can see the request text, the language, user, notes and already added sentences.
This looks good. Nice work!
My initial comments:
(2) I think some people will want to add a word request for multiple languages at a time. Will they be able to choose multiple languages from the drop-down list?
(3) Note that the rest of the website uses the English spelling for "favorite". I'll save my other comments about wording for later, when we're closer to consensus on how the UI will look.
I'll let you know if I have other comments on the basic UI after looking at your proposal some more.
Thank you for your feedbacks!
@LokSyut : it sounds like a good idea, users who want to keep their requests unlisted are likely to have a specific user in mind to add sentences
(2) For simplicity sake for the first implementation, I would say no because I'm not sure how widely this would be used as this means having the same word with the same spelling in multiple languages, but maybe it's just my feeling and if many users request this we could add it
(3) It could be great if a native English speaker could review all of the wording :)
Thank you again for your work @kamillel :) Having pictures to think upon really helps. Here's my feedback.
Another approach for requests?
It occurred to me that maybe we should take a different approach for collecting requests. It seems more useful if we put an emphasis on the fact that users create requests around vocabulary that they are learning, and therefore the "requests" are more of a "vocabulary tracking list".
Among other things:
The problem if we take the "requests" approach, is that I feel we're sort of giving users the expectation that we can provide example sentences for any request, in a relatively short period of time. This is achievable for languages where we have active contributors, but it won't be the case for a lot of languages. If their requests remain unanswered for days, then weeks, users may feel discouraged from creating requests at all.
If however we take the "vocabulary list" approach, then users will always feel a use for the feature: even if their requests is never fulfilled, they can still use Tatoeba to simply keep track of which vocabulary they've been learning so far.
It is unclear to me how users would share unlisted requests so this is an option we may want to drop for the first iteration.
I personally think to implement this, we would need to provide a way for users to create lists of requests, and the public/unlisted status would be set on the list level rather than on the request level. It would be too cumbersome if users have to specify the status of each request individually, and share each unlisted request individually.
Implementing lists of requests will require a quite significant additional effort, which is why I'm suggesting to leave this on the side for now.
I don't think we need to associate a request to one specific user. A request can belong to several users, and instead of using the "favorites" concept, I think we should use the "+1" concept.
Roughly something like this:
After I've +1'ed your request:
I can click (x) if I change my mind and don't want to request it anymore. Then it goes back to the previous state.
@trang: thank you for your feebacks!
I changed 'request' references to 'vocabulary item', added the multiple ownership approach and used more the 'translating' mechanism.
As suggested by Trang, I removed the single ownership concept:
That means that items could en up being 'orphans'. I'm not sure if it's an issue or not but they could be automatically deleted if it is.
About the edit function, I don't know if it's possible to have two scenarios:
In the same way it would only be possible to delete a request if there is only 1 user and no sentences.
Use case 3: I want to add sentences for existing requests
After a lot mulling over, I think the user goal is closer to translating (helping others) than adding sentences (asking for help), so I rearrange the wireframes in this way:
The first interface would be a search and the second would be the list.
Vocabulary items are ordered by the number of people requesting them (high to low).
There's one use case missing in the wireframes: the possibility for users to link existing sentences to their vocabulary. But we can leave this for later I think.
We can implement this feature with the following steps:
Here are the scenarios I have in mind.
This scenario is more or less the ideal case, where I have control over the sentences that are connected to my vocabulary and I can explicitly request sentences.
This is a possible scenario for the first iteration. It focuses on implementing the "Step 1".
In this scenario don't control which items are linked to my vocabulary, instead we use the search engine as an intermediate: each of my vocabulary items are linked to all the search results for that item. This has some obvious limitations but it can be enough for a start.
There are more things we could drop for the first iteration.
If all of this makes sense to you, then I'd suggest we continue discussing the details in a separate issue that would cover the things to implement in the first iteration. I'll let you create it, and add your updated wireframes in it.
We can keep the current issue open to discuss about the next iterations.
Many thanks for your feedbacks, this approach makes a lot of sense, it was bugging me that previously the vocabulary items were a bit disconnected from the rest of the site, now it feels more integrated.
I don't think the concept of 'followers/requesters' will be needed any more, it was just a way of ordering items (to show the most 'needed' first) but using the amount of sentences sounds a more relevant way of ordering items for now.
I agree for the notes, I struggled to find good examples while making the wireframes, I think that something we need users' inputs on. Once people start using the requests we will see if there is a case for it.
I created a new issue for the first implementation: #1166
The Suggested Improvements.
I'd suggest changing the ALL CAPS to standard sentence capitalization, and also adding a period at the end of the sentence. It would also be a good idea to change this to the standard link color used throughout the website.
Why (The Problems)
URL and Screenshot
(Note that the English wording for this could perhaps be better, but this is understandable.)
I'd also suggest using the standard link colors used throughout the website for these links, too, for the same reason as mentioned above. (#1148 (comment))
While, I find the current link color, light green, difficult to read, if you make sure that all the link colors on the website are standardized, it will be easier to change all the links in the future.
We likely need a way to prevent spam-like word requests.
Someone has already submitted multiple requests across languages mentioning a product name, WhatsApp.
This could potentially become a major problem and irritation to members.
2 Possible Approaches to Preventing This
Perhaps other solutions could be considered, too.
Multiple near duplicate submissions are possible, depending on capitalization.
URL and Screenshot
This is not an immediate problem, perhaps, but it is something that likely needs to be dealt with. It could be ignored, of course, and just assume members will use the most logical capitalization of words.
It might be possible just to convert everything to UPPERCASE or lowercase. All lowercase is how most people likely search, but ALL UPPERCASE avoids the problem of seeing words like "boston" which should be capitalized.
An exact match for sentence counts implies that a word isn't covered, though it might be in another form of the word.
For example, on the dev site someone asked for "armpit" which shows 0 sentences, but the more normal way we use this word in the plural "armpits" has a number of sentence examples.
It's probably still a good idea to maintain the exact search.
Add a column to the right of the "0 SENTENCES", perhaps calling the column "fuzzy search" or something like that. In this column, have a link the the search for "armpit" without the equal sign (="armpit").
Regarding exact search, it occurred to me that we should probably mention in the Tips section on the right side of the page that this system is based on exact search. I stress this because the Vocabulary system, by its nature, favours languages that do not feature heavy inflection.
For languages like Marathi or Sanskrit, which strongly inflect nouns, users would probably require a wildcard-based search at the very least.
Vocabulary items that already have examples.
I think we should hide the words from the list of wanted items if they already have examples. As a native speaker I would prefer to contribute something that isn't in the database yet. If someone just wants more examples with a certain word I think he should be able to indicate how many sentence with that word he wants. It's something annoying when you accomplish someone's request but the word still remains in the list.
When filtering by language, often the page is blank with no idication why it is blank.
Put a message saying something like the following.
There are no requests for Korean.
There are no requests for Korean that do not already have at least 10 sentences.
In the current dev branch, adding a duplicate vocabulary item causes a sql error and screen freeze, but no message is given to user. In model vocabulary.php
In the controller, check for 'error' index on $result:
And then pick up the error in add.ctrl.js.
That'd be great :)
Separate issue would be better, to avoid overwhelming this thread, but in the end it doesn't matter too much. What's important for me is that the problems and solutions are documented and can be traced. So you could just reference to your comment above in your pull request, and that'd be fine too.