** Stats - 2020-07-25 - Native Speakers with Contributions **
Find out who the native speakers are and get links to their sentences.
For the first time *ever*, Slovak is 100% translated and got the "Ready for use" status on Transifex - https://www.transifex.com/tatoe...ite/dashboard/
Thanks a lot, po_slovensky, for your hard work!
(Translation supplied by Tatoeba. :->)
In order to add a comment under a sentence I must klick 3x in the comment field.
Does it happen to anyone else too?
Mir ist das noch nicht aufgefallen. Vielleicht mußt Du einfach nur warten. Manchmal ist alles etwas langsam.
** What's New on Tatoeba? - Your biweekly recap #21 **
(What's New on Tatoeba will be published biweekly until the end of August.)
※ We have two new issues solved on internal code since last time.
• Information about original sentences is now available in the "Base of Sentences" section of the Downloads page. Thanks to ftumsh.
• All the export files are split by language. Thanks to lbdx for the scripts that splits our exports, and to gillux and rumpelstilzchen for helping to optimize the solution.
※ A few external projects are now ready to receive feedback. You are kindly invited to check them out and share your thoughts!
• jacopofar's cloze deletion tool: https://grammarquiz.online/
• jonnyk's tool to automatically generate vocabulary flashcards: https://sentence-finder-frontend.herokuapp.com/
• Jpec's Japanese learning app: https://play.google.com/store/a...ec.benkyou_app
※ The vocabulary count has been fixed. Thanks to AlanF_US for reporting the issue and rumpelstilzchen for fixing it.
※ Searching sentences with a question mark at the end no longer returns an error page. Thanks to CK for reporting this and gillux for fixing it.
※ rumpelstilzchen solved a bug where the search was returning sentences in the wrong language. Thanks to him for the fix and to brauchinet for reporting it.
※ The landing page is now responsive. Thanks to Trang for implementing this and to everyone for testing.
※ Logs on our servers are now a bit less cluttered. Thanks to rumpelstilzchen for taking care of this, and to gillux for suggesting it.
ON THE WALL
※ miketheknight asked if we could extend the functionality of the search option "Owned by a self-identified native": https://tatoeba.org/eng/wall/sh...#message_35625
※ CK announced that we have a new Polish voice: https://tatoeba.org/eng/wall/sh...#message_35655
※ Trang needs people to test the responsive search results: https://tatoeba.org/eng/wall/sh...#message_35638
※ morbrorper asked how we can more easily flag and track translations that don't match: https://tatoeba.org/eng/wall/sh...#message_35618
※ Tatoeba is supporting eight new languages: Chinook Jargon, Southern Subanen, Ancient Hebrew, Pali, Baluchi, South Levantine Arabic, Southern Haida and Northern Haida.
※ Serbian has been enabled on production as a UI language.
※ Several other UI languages have been enabled on dev: Bulgarian, Filipino, Turkmen, Croatian, Slovak and Balushi.
As usual, thanks to all the members who helped to translate the website!
If you'd like to help to the development of Tatoeba, report issues, or are just curious, have a look at the GitHub repository.
If you want to help us translate the website to your language, you can join us on Transifex: https://www.transifex.com/tatoe...ite/dashboard/ and check this article on the wiki https://en.wiki.tatoeba.org/art...e-translation.
If you're especially happy with one of the updates, don't hesitate to personally thank our developers :) They're working in the shadow but they'll be glad to hear your feedback.
Last recap: https://tatoeba.org/eng/wall/show_message/35583
See this recap on the blog: http://blog.tatoeba.org/2020/07...-biweekly.html
In advanced search there's a checkbox "Owned by a self-identified native". Would it be reasonable to extend this functionality to "Owned or approved by a self-identified native"?
It could be.
Can you tell us what made you think of this? With a bit more context, we can better assess whether we should extend the checkbox as you suggested or whether we should add another search option.
Note that there has been a similar request raised on GitHub:
Because I like working with sentences added by native speakers. They are less likely to be awkward, they are less likely to contain structural mistakes. I even enjoy noticing typical mistakes that native speakers make - for example, I used to pronounce "they're" and "there" differently in English a long time ago, and only after having noticed that native speakers of English regularly confuse "they're", "there" and "their" in writing did I understand those three have identical pronunciation.
Anyway, I have a lot of reasons to work only with sentences added by native speakers, so I almost always use the "Added by self-identified native speakers" checkbox in my searches.
However, I think I'm missing out on sentences added by non-native speakers that were approved / corrected by native speakers. I don't see why those would be any worse than sentences added by native speakers.
So I believe it would be useful to treat "Sentences added by native speakers" + "Sentences approved by native speakers" as one set.
The github link is not the same. If I OK an English sentence, it doesn't make it any more reliable than it was before me okaying it, but it's important for a sentence to be reviewed by a native speaker.
> only after having noticed that native speakers of English regularly confuse "they're", "there" and "their" in writing did I understand those three have identical pronunciation.
Not identical, at least not for every speaker, but definitely similar. :)
There are a lot of correct sentences that belong to users that have not indicated their native language. And I have come across quite a few sentences with errors, by native contributors. Nevertheless, I think this would be a useful feature.
In relation to this, I would like to call for an overview of all the sentences having the @needs native check tag. I find it discouraging to see sentences with this tag being ignored for ages.
There are also quite a few sentences that have both this tag and an "OK" tag, which is confusing. I understand that may be because the person who OK's a sentence does not always have the right to delete other people's tags, or they just forget; this makes me think the issue is perhaps not best handled using tags.
> In relation to this, I would like to call for an overview of all the sentences having the @needs native check tag. I find it discouraging to see sentences with this tag being ignored for ages.
In which languages? I make a point of frequently reviewing the English sentences with this tag (along with @check and @change). Sometimes they build up in the short term because they are owned by an active member who hasn't had a chance to get through all of them yet.
> There are also quite a few sentences that have both this tag and an "OK" tag, which is confusing.
Again, in which languages?
OK, I looked a bit closer, using the web interface, and found that Norwegian Bokmål actually stands for more than half of the total ~4500 sentences. It is among these that I found the OK'd ones.
Other languages that stand out are Japanese (412), and Mandarin Chinese (384). To get the whole picture, for each language, maybe somebody could run an SQL query?
Indeed, English has very few unhandled @NNC requests, for which I am grateful.
We have a new Polish voice.
Farmersa has contributed 223 audio files.
Glad to know that! :D
Shouldn't "Translations" be localized? I mean in cases like this one:
It doesn't have to. It's a title, it's not a description.
Ricardo, what makes you think that it is not localized? When I use the French UI, that string is displayed as "Traductions".
In English, even when there is just one translation, it shows "translations" instead of "translation".
Okay, so if I understand what you're saying correctly, the issue is that:
- "translations" is not marked as a word with singular and plural forms
- the UI does not count the number of translations to determine how many there are, and then use this logic plus the singular/plural forms to determine the correct text to display
Personally, I don't mind that "Translations" is displayed even when there is only one translation (in fact, it never occurred to me before you mentioned it), but I see your point. Note, however, that if we used a singular/plural form, we'd have to reexamine and possibly update it every time the number of translations changed for a given sentence because a translation was added or removed.
I think "Translations" is fine as it is. If we have it read "Translation" when there is a single translation, it would give off the implication that there can only be one translation below the sentence. For new users, this could be confusing.
Like Trang said, "Translations" is a title, so think of it as a box marked Translations. The number of translations in that box may vary (or it may be empty), but the title of the box will remain as it is.
I haven't thought on that way. Thank you!
**Responsive landing page**
I have deployed on the dev website an attempt at making the landing page responsive and will need some feedback. If you have time, please visit the dev website from your smartphone.
Only the landing page (for non-authenticated users only) will adjust to small screens. Other pages will still be displayed as miniatures of the website.
To convert this page into a responsive page, I had to rework some elements so that they would display properly on smartphones. Some of these changes have an effect for the desktop users too (login box and UI language selection being the most notable changes). I'll let you try out and report things that you find confusing or inconvenient.
Thank you for testing!
Note that TRANG is referring to the non-logged-in main page.
You will have to make sure to log out to see what she's talking about.
This is the only problem that I noticed right off.
The interface language icon wasn't intuitive to me, but perhaps it is to others.
The "show more features"/"show fewer features" icons are displayed, but have no effect, for a user who is not logged in.
It does, but it expands and collapses the hidden sentences instead of showing features...
The icons appear in two places: (1) in the top green bar and (2) next to each sentence. I was looking at the one in the top green bar, which didn't seem to do much. But in fact, it does affect sentences that have unreviewed automatically-generated alternate transcriptions: It shows or hides the transcriptions.
The "show more" button in the green toolbar should indeed not be displayed. This bug should be fixed on dev now.
I have implemented additional changes to the top menu. As always, if you have time, please test it on the dev website and let me know if you have any issue.
The main change is the part with the user menu, inbox, log out and language selection.
It works, but I don't like the way it takes multiple clicks to get to things I often access.
With the current design (on the main site), I can mouse-over my username, then click "comments on my sentences." This only requires one click.
The new design requires multiple clicks.
1. Click my username in the menu bar.
2. Click "my profile."
3. Click my username again where is appears under the search bar.
4. Click "comments on my sentences."
It's not only this, but it requires this same number of clicks to get to everything else in the drop-down menu that I use.
Changing my language isn't something that I use very much, hardly ever, but I do use the other things, so I'm not sure why the language change part cannot just be included in the "settings."
I agree. I rarely change my profile, but I often want to look at my lists, my most recent comments and sentences, and comments on my sentences. It is a pain to have to go through my profile in order to get there, especially on the desktop, where I have plenty of room for a longer drop-down list.
In addition to forcing us to use more clicks, moving these items out of the menu has a negative effect on discoverability. If I didn't see them in the menu, I might think that such functionality didn't exist at all, especially if I didn't visit my profile after setting it up as a new user.
When I look at my profile, there's a box on the right-hand side with the heading "Settings". Three items are shown: (1) whether e-mail notifications are enabled, (2) whether the profile is public, and (3) the list of languages for translations I want to display. The problem with item (3) is that there's no explanation, just a bare list:
>> deu, eng, epo, fra, heb, ita, jpn, por, rus, ukr
It would be better if there were a short introductory phrase:
>> Translations displayed in: deu, eng, epo, fra, heb, ita, jpn, por, rus, ukr
I wish there was a way to easily flag links to translations as being questionable. That would cover the case where a linked translation is correct as a sentence, but does not mean the same as the original sentence.
Of course one could go and write a comment on each questionable translation, but it is quite tedious, and it is easy to get sidetracked in the process. Or, as an advanced contributor, one could simply unlink the offending translations, but then nobody would probably notice.
I have seen the "unlink" tag, but I don't think a tag is enough.
See sentence #807032 for a current example.
What I normally do is the following.
I take notice who was the one to create the link. for example, #1508983 was linked by marcelostockle - you can see that in the logs. In this case it's a relatively simple case, he added his sentence as a translation. So I comment under his sentence asking him to verify his translation.
Sometimes it's more complicated than that. Sentence A and sentence B were added independently, and then someone linked them. In this case I comment under any of those tagging the person who linked them and asking them to verify the link.
I do something similar, but it is rather difficult to keep track of the sentences I have remarked on in this way. At least there is a page with all my sentence reviews, but no such thing for my translation review.
I wish some of this could be automated somehow, with notifications going out to those involved.
Thanks for sharing your thoughts on this. I completely agree with you that we could streamline the process of dealing with non-matching translations a lot better. While I have some ideas on what we can do, I can say that designing a good feature for this will not be an easy feat.
In any case, I have created an issue on GitHub: