Our data is released under various Creative Commons licenses.More information
If you love this content, please consider a donation.
Wall (5,913 threads)
Tips
Before asking a question, make sure to read the FAQ.
We aim to maintain a healthy atmosphere for civilized discussions. Please read our rules against bad behavior.
morbrorper
7 hours ago
deniko
11 hours ago
morbrorper
12 hours ago
Ricardo14
yesterday
Ricardo14
yesterday
Ricardo14
yesterday
samir_t
yesterday
TRANG
yesterday
yatomoya
2 days ago
CK
2 days ago
Mi ne ricevas nun retpoŝtajn sciigojn. Kial?
The email notifications are still working on our side, as far as I can tell.
Are they maybe marked as spam on your side?
Yes, they were marked as spam. The problem is solved. Thank you very much.
is it ok to webscrap Tatoeba?
Since Tatoeba doesn't provide an API, I've been developing a simple API myself that scraps the search results and returns them as JSON data. I'm playing with an Android app made with React Native as a way to quickly search for words without having to load the website on mobile browsers. I'm also developing another personal web app which uses Tatoeba Japanese sentences but as I didn't know how to properly download and use the data in the beginning of the project (and how to do it with good performance for the web), I decided to use the same webscraping mechanism.
I read the ToS and there's nothing against it on there. I'm aware that there's so negative views about webscraping out there but in my defense, it would be the same as a user requesting a search page, only difference is my code parses and returns the data in another format with no further stress to Tatoeba's servers.
There's no automated scraping involved.
Perhaps having an API of this type would also help anyone else who wants to participate in Kodoeba or simply use data from Tatoeba in a personal project?
If it's ok and anyone is interested, I would be glad to share the code :)
Yes, it’s perfectly fine to webscrape Tatoeba as long as the scraper is not too aggressive and you give proper attribution (the contents are under Creative Commons CC-BY).
We are aware that there is a need for a proper API. It’s just that nobody had time or energy to create an API so far. You, or anyone else, is welcome to contribute. We think that creating a read-only API could be a good project for Kodoeba (especially if other Kodoeba participants want to build something based on that API, that would be a nice collaboration between participants).
Thanks for the answer!
I've been contributing a few sentences for a while (not consistently though) and have looked at the repo a few times but as it's mainly written in PHP I have no clue how I could contribute to create an API. My experience is mostly with Python and Django, I'm also working with React but it seems Tatoeba uses Angular instead?
Some time ago I even researched a bit about CakePHP and how to make a REST API but couldn't find anything simple for a non PHP dev so I gave up.
In Django it's so simple, I just have to use drf and create a few views and paths and voilà, I have an API. If anyone could point me some resources for creating an API with CakePHP, how it works, etc, I would like to try at least.
> it seems Tatoeba uses Angular instead?
Yes.
> If anyone could point me some resources for creating an API with CakePHP, how it works, etc, I would like to try at least.
Well, there's the cakephp.org site, which has a "CakePHP at a Glance" page:
https://book.cakephp.org/4/en/intro.html
though I don't see anything on that page about creating an API. You could also take a look at the "Contributing as a developer" page:
https://github.com/Tatoeba/tato...as-a-developer
I know the developer team would be glad to have you help them in any way!
How many developers are there in the team and may we know their names?
At the moment, the core developers are:
- myself, since the very beginning
- gillux (jiru on GitHub), since June 2018
- rumpelstilzchen (AndiPersti on GitHub), since April this year
Core developers have write access to the main source code. Any code change submitted by anyone else has to go through the approval of a core developer.
You can the full list of people who contributed to the code here:
https://github.com/Tatoeba/tato...s/contributors
You can see the latest changes in the code here:
https://github.com/Tatoeba/tatoeba2/commits/dev
> it seems Tatoeba uses Angular instead?
AngularJS to be more specific.
> Some time ago I even researched a bit about CakePHP and how to make a REST API but couldn't find anything simple for a non PHP dev so I gave up.
The main docs are at https://book.cakephp.org/3/en/d...ment/rest.html and https://book.cakephp.org/3/en/d...estful-routing
> In Django it's so simple, I just have to use drf and create a few views and paths and voilà, I have an API.
It turns out that with CakePHP it's also pretty simple. I've just created a simple demo which you can find at https://github.com/Tatoeba/tatoeba2/pull/2341
> My experience is mostly with Python and Django,
When I've started contributing to Tatoeba I also didn't know much about PHP and CakePHP but it's not hard to learn if you already have programming experience. You can contact me any time if you need some help.
Hi, rumpelstilzchen, thanks for your answer and sorry for the late reply.
Judging by your demo, it really doesn't look as complicated as I thought it would be.
I'm currently working on a side project and would like to finish a few plans I have for it in the next weeks before starting to contribute, after that I'll take my time to (re)learn PHP and better understand REST and how to implement it with Cake.
I say (re)learn because around five years ago when I started coding I was using Codecademy and went through their PHP tutorial at the time but I forgot most of it because I've never used it ouside of the tutorials. I also think I should step up some of my skills before trying to contribute to other projects. I'm sure you get what I mean, writing code on a personal project is one thing but contributing to such a huge project as Tatoeba is something entirely different!
Although I've learned a lot over the last 2 years, which is basically the time I have been working on my current project, I feel like there are a few things I should go back and study more.
Anyways, I hope to finish my project and start soon, meanwhile I'll keep contributing a few sentences here and there when I can.
** Stats - 2020-05-30 - Native Speakers with Contributions **
http://tatoeba.ueuo.com/stats-2020-05-30.html
Find out who the native speakers are and get links to their sentences.
Will the new design for the sentences eventually replace the old design for everyone, or will the old design be kept as an option, as it is now?
There will be a period of transition, but sooner or later we will get rid of the old design entirely.
Thanks for replying. Sad news, I guess.
Are you being melancholic?
You can put it like this, if you wish. The new design is terrible and clumsy to use. I'd hate to have it, but, obviously, we won't have a choice, which I accept.
Well, you could explain what is terrible and clumsy to use, and we could see how things can be improved, as a first step :)
1. By default, some translations are hidden in the new design and I need to click "Show N more translations" every time in my search results:
https://i.imgur.com/YyBRn8s.png
It is very annoying and very counterproductive. I do understand why someone might have this preference, but can we make it optional? Create another checkbox - "Expand all the translations". By default, if the user doesn't bother to change it, the sentences will be displayed as they're displayed now, but some of us can make it more comfortable for us.
I am aware you can permanently limit yourself to just a bunch of languages in your profile, and this issue will become less important, but I'm going to do it because I enjoy being able to see all the translations.
EDIT: I'm also aware of this setting:
"Display a link to expand/collapse translations when there are too many translations"
But it seems to be working for the old format only. I guess if you make it work for the new and the old format, that would resolve this problem.
2. The second thing that bothers me A LOT are the words "Translations" and "Translations of Translations":
https://i.imgur.com/rZCd1yi.png
I understand why they are there - a lot of users, especially the non-regulars or the relatively new contributors are confused by the whole idea of "gray" links and report the indirect translations as wrong while they're not wrong, they're just translations of translations and they don't have to match the "original" exactly. But for more experienced folks who understand and embrace the concept of indirect translations those words are just a nuisance, completely unnecessary information in words that can be perfectly color-coded. Could we optionally remove those words, leaving them there by default?
3. A less important issue - the new format is just less compact than the old one. Compare (this is the same sentence with the same translations):
https://i.imgur.com/4yuO9YJ.png
Thank you for your always useful feedback. :)
Well, I don't think there is so many terrible things there!
1. This setting needs improvement. Notice that the new design isn't complete yet so functionalities may be behave incorrectly or be missing. Even after the new design implementation, that might still be the case and we hope we can count on people's feedback to correct and improve them. As gillux mentioned, there will be a transition period, but the old design will only disappear when we will be absolutely sure that nothing's gone missing in the new design.
2. That's your personal opinion, so there isn't much to say. I can't say two. The first one is that of course, we can discuss that point. The second is that I'm not sure for how long you've been using the new design, but maybe after a while, you'll get used to it and those words won't bother you anymore. Once you're used to the new design, they might get easily ignored by your brain.
You also mentioned color-coded sentences. That's is also currently under discussion.
3. Yeah, I've noticed that too. Now, we need more scrolling. Not a really impacting issue, but it has been reported.
I hope I could answer your points clearly.
As a final, more general, note, change is always a difficult thing, and we expect a lot of complaints from a lot of people. However, if people could start by "here what I like and dislike now" before the "this crap is terrible", that would be appreciated and we would be able to discuss with a better set of mind. Thanks.
Hi Aiji,
I really hope you're not part of the development team, or at least not a decision maker of what will be implemented or not.
Your smug, dismissive and passive-aggressive way of dealing with our concerns is not ideal.
Your active-aggressive way of expressing your concerns wasn't ideal either.
Now, I hope I could give you an overview of what was currently being discussed on GitHub (mainly) and that a part of your concerns were already discussed or will be, and if my answer seemed too aggressive, I apologize. My thanks for your feedback were sincere, as I think you're one of those who very often gives precious information regarding how we could improve things.
How do I get specific languages to be above "show more"? Do I need now either to always click "show more" or to hide most of the languages completely?
You can deactivate this link in your settings: https://tatoeba.org/eng/user/settings
If you want it activated but would appreciate it to behave differently, please elaborate on what you would like to have and *why*.
From the same settings page, you can also choose a list of languages to only display sentences in those languages (all others will be hidden).
If I choose a list of languages, all other languages will be completely hidden. They won't be displayed if I click "show more". Here are my options if I don't hide languages completely:
Best option (not available) - show my preferred languages first; if there's a lot of translations, put everything else under "show more".
Worse (old design) - show everything; it's up to me to find sentences in my preferred languages among all others
Even worse (new design) - hide some translations no matter if they are in my preferred languages or not; I have to always click "show more" and then do everything I had to do in the previous option, so it's more work. Also, the list takes more space.
As noted above by deniko, it's impossible to disable "show more" in the new design. But even if it would have been possible, new design would still be worse for sentences with many translations.
> Best option (not available) - show my preferred languages first; if there's a lot of translations, put everything else under "show more".
That would actually be a cool solution. Thanks for this idea.
I would still prefer to be able to expand the sentences by default without clicking, but if you can actually list the languages that you want to be displayed first that would really be awesome. And would be cool if you can specify the order in which they're displayed.
For example, if I specify
eng,spa,fra,ita
In my profile, I would see the translations in those languages in that order, and only after those 4 languages I'd see all the other translations in their default (alphabetical, according to the language code) order.
The existing solution of completely hiding all the other languages is just not satisfying at all, at least for me.
I agree with Denis and Anton. The new design is extremely frustrating.
Is it for the same reasons as them or do you have other reasons?
The reasons are the same. They described them very well and I have nothing to add so far.
Then please see my reply to deniko below.
https://tatoeba.org/eng/wall/sh...#message_34492
I have the same questions for you as I have for deniko.
Most importantly the last question:
> Could you provide a scenario of your activities in Tatoeba that can make
> us understand "Okay, indeed, if the translations were not expanded by
> default, it would be annoying"?
When I see a sentence in a foreign language I know, first of all I look whether it has already been translated into Russian or not.
If yes, I proofread the existing Russian translation(s) (not only for translation accuracy but also for punctuation, spelling and grammar). Sometimes I add my own translation(s) as well.
If not, I add one or several Russian translations.
If I see that my newly added sentences can be linked to the existing translations in the other foreign languages I know, I do it right away or later from this page:
https://tatoeba.org/rus/activit...ces_of/marafon
Besides that, I check the indirect Russian translations and link them to the main sentence if they match.
I also check the indirect translations in the other languages. Sometimes it helps me find some linking errors like this one:
https://tatoeba.org/rus/sentenc...omment-1165179
Just looking at the indirect link here:
https://tatoeba.org/rus/sentences/show/5918489
helped me find this error.
I'm also interested in some languages that are not listed in my profile. For instance, I enjoy seeing the Ukrainian, Czech or Italian translations.
It's just one of my activities in Tatoeba. I'm not sure I described it well enough but I hope it helps you understand why I find the new design and particularly the button "Show more" so frustrating.
I used to love the random sentence on the main page. But not anymore.
p.s.
> Now it works super weird - I add
> 3 Ukrainian translations out of habit, only to realize 20 seconds later
> it already had Ukrainian translations, they were just hidden.
That was my experience, too.
I created the following issue on GitHub:
https://github.com/Tatoeba/tatoeba2/issues/2210
If you were able to increase the limit of translations that you can see, what would be your limit? Would it be higher than 50?
On a side note, your description actually brings up other fundamental issues in the overall design of Tatoeba. It's a problem with the way Tatoeba is structured and organized. But addressing that problem is a whole other story so I won't delve into the details here.
50 would be enough, I think.
Btw, now I don't see the way to link the indirect translations to the main sentence. That's what I used to do all the time.
The linking feature has not been implemented yet in the new sentence design.
OK
And also the feature of reviewing?
Here an example:
https://tatoeba.org/epo/sentences/show/8604386
This sentence has been corrected, so my review has to be changed from red to green. For doing this I need to switch back to the old design, no?
Sorry if that has been answered before. I didn’t see it.
That will be implemented later :)
> Best option (not available) - show my preferred languages first;
A similar idea has been mentioned before:
https://github.com/Tatoeba/tato...ment-505311261
Additionally there has been some debate regarding the order in which translations should be displayed:
https://github.com/Tatoeba/tato...ment-577132284
> And would be cool if you can specify the order in which they're displayed.
That's also my opinion.
Based on the various discussions on GitHub, it became quite clear that we need to provide a better way for users to define the languages they want to see in Tatoeba and what is the priority of each language.
I'm still wondering however what is your use case for preferring to have all translations displayed by default. Do you confirm that it is because most of the time, the translations you are interested in are not displayed at the top? Or is there another reason?
Also, which of your activities does it affect the most? Is it slowing you down for translating sentences? For linking sentences? For proofreading? For something else?
Could you provide a scenario of your activities in Tatoeba that can make us understand "Okay, indeed, if the translations were not expanded by default, it would be annoying"? Right now I must say I can't imagine this scenario.
Joskus, yksinkertaisten lauseiden tapauksessa, löydän uusia kieliä joita voin linkittää. Esimerkiksi suomalais-ugrilaisten kielten numerot ovat hyvin samanlaisia, enkä tiennyt niistä kaikista ennen kuin selasin kielilistaa läpi sen lauseen kohdalla, joka listaa numerot ykkösestä kymmeneen.
Samoin olen joskus linkittänyt satunnaisen latinankielisen lauseen, vaikka en suuremmin latinaa osaakaan, jos olen sattunut tietämään mitä se tarkoittaa.
Usein selatessani Tatoebaa luen lauseita kielillä, joita en osaa tarkasti, saadakseni tuntumaa niihin ja kenties oppiakseni jotain. Tämä kattaa monet romaaniset ja germaaniset kielet, suomalais-ugrilaiset kielet ja latinan. En osaa kääntää näistä tai edes lukea näitä itsenäisesti ja näiden näkemin on huomattavasti vähemmän tärkeää kuin niiden kielten, joita osaan jonkin verran.
> Also, which of your activities does it affect the most? Is it slowing you down for translating sentences? For linking sentences? For proofreading? For something else?
Linking mostly, not proofreading.
When I link, just browse through Ukrainian sentence using the search feature to give me random sentences, and link them to all sentences they can be linked directly.
Also, when I stumble upon some interesting expression I really like searching for it here and check out translations to all languages I kind of understand, even those not listed in my profile just because I'm curious. I'd say that activity is very important for me.
Also, I used to enjoy having the random sentence on the main page. I don't know why, but I've always thought it to be a fascinating feature. I've stumbled upon some real gems there a few times, something I would have never found if I was trying to search for something. I would occasionally translate them. Now it works super weird - I add 3 Ukrainian translations out of habit, only to realize 20 seconds later it already had Ukrainian translations, they were just hidden. I turned on the random sentence because all this was very annoying.
So, in general, I understand why someone might prefer the new format, and I understand why you would prefer this to be the default format for the unregistered users and the default format for everyone else, but I kindly ask either to leave the old format for us, or at least add t those two features as optional features:
1. Expand them automatically, if my settings say so.
2. Remove the words "Translations" and "Translations of translations" as completely unnecessary and distracting (again, leave them there by default, but please allow us to get rid of them).
Everything else doesn't really bother me too much. Making the new format more compact or dense is nice, but not really a deal-breaker. Same about the feature mentioned by Anton - allow users to configure which translations to display first. That's a cool feature, I'd love to have it, but purely psychologically I feel like it's less important for me.
One thing to get a cool new feature - yeah, that's nice, but I understand why it's not there - another thing - taking a nicely functioning design and breaking it to something barely functional - that feels bad, like a giant step back.
Olen samaa mieltä kohdan 1 ja motivaation kanssa.
Kohta 2 olisi myös minulle parempi, mutta toisaalta ylimääräisten sanojen aiheuttama harmi on hyvin pientä, ja liika valinnaisuus käyttäjillä aiheuttaa kasvavaa työtaakkaa ohjelmoijille. Niinpä ehdotan, että vaikka tiiviimpi käyttöliittymä olisi mukavampi, ei ehdotus kaksi luultavasti ole pitemmässä juoksussa toteuttamisen arvoinen.
Thanks, Thanuir, you can be right about point 2, but I just feel they take space and they don't do anything useful for the experienced users. The direct and indirect links are already colorcoded by the color of the arrows (or > in the new design). It feels right to use words where they belong, for the important information - the sentences themselves - and icons and other mnemonics for technical information and actions.
All that feels consistent.
Now, using words to distinguish direct and indirect links just seems to be very inconsistent and it makes me uncomfortable. I will absolutely get used to the less compact design, but I just liked the consistency of everything else.
While this might be way less important for others, I still feel like it's something easy to implement and hopefully I won't be the only one who chooses to opt out from seeing the words "Translations" and "Translations of Translations".
I wonder whether I can join the development team just for this single task? I'm a software developer by profession, after all, although I do lack any web-development experience.
> I wonder whether I can join the development team just for this single
> task? I'm a software developer by profession, after all, although I do lack
> any web-development experience.
Tatoeba is open source. You (and anyone) can make a pull request on GitHub.
Please see our guide for people who want to contribute as developers:
https://github.com/Tatoeba/tato...as-a-developer
You can by the way use the Stylish add-on to make some readjustment of the UI to better suit your personal needs.
https://userstyles.org/
You would need to know CSS, but hiding certain elements or making the UI more compact would be totally possible with Stylish.
You can find various styles that people already created for Tatoeba in the Stylish website, by searching "tatoeba":
https://userstyles.org/styles/b...eba&type=false
> You can by the way use the Stylish add-on to make some readjustment of the UI to better suit your personal needs.
Thanks, that actually sounds cool. CK also mentioned Stylish to me today, so I guess I'll give it a whirl.
You may be interested to check the CSS code that I posted over here:
https://gist.github.com/trang/0...33407ccd794716
Related comment on GitHub:
https://github.com/Tatoeba/tato...ment-636214078
Just to be clear, I was not asking you those questions in defense for keeping the new design as it is. We will always try our best to provide the best possible user experience for everyone. But to do so, we need to understand how people use Tatoeba.
Users tend to go straight off saying "I would like things to be this way" or "Is is possible to implement this", but that is not helpful to us. We don't make changes just because someone prefers things to be a certain way.
Unless you are a trained UX/UI designer, you will not necessarily think of the best possible solution for a UI problem. You will suggest solutions based on your own habits and your own biases and the things you suggest may have a negative impacts on others without you realizing it.
The best thing you can do to help us provide you, and everyone, the best possible user experience, is to describe how you use Tatoeba, a little like you are telling a story. You can always provide a solution, but without the story behind it, it doesn't help us figure out the best course of action. That's what my questions were aimed to do: to extract this story.
Now more concretely, you shared this bit of story:
> I've stumbled upon some real gems there a few times, something
> I would have never found if I was trying to search for something.
> I would occasionally translate them. Now it works super weird - I add
> 3 Ukrainian translations out of habit, only to realize 20 seconds later
> it already had Ukrainian translations, they were just hidden.
So this is useful information to me. It is a lot more useful than hearing you say you want to be able to have all translations expanded by default.
It explains why you prefer to have the translations expanded and it also explains why you prefer to have a more compact design. And it helps me understand where precisely are the problems.
Now what I can say is that having the translations expanded by default isn't great if you have tons of translations. The more translations, the more effort for you to spot the existing Ukrainian translations.
For that specific problem that you described, a better solution, in my opinion, would be that whenever you select the translation language, it displays the existing translations in that language.
Having all translations expanded does solve that problem but it is not a solution that will scale in the long run. It works only because at the moment, most sentences don't have more than 10 translations.
But one day, if Tatoeba continues to grow (which I hope it will), we may have 100+ translations on the majority of the sentences, and displaying them all is not exactly usable. There's still time until we get to that point, which means if expanding all translations is the cheapest solution, we can still go for that solution. But that shouldn't stop us from trying to figure out better ones.
For instance we could make an option to allow users to choose how many translations are displayed by default. We chose 5 arbitrarily, but some people like you may need this limit to be higher, perhaps up to 20 or 50 even. We have a similar option for the number of sentences per page (we chose to have 10 by default, but users are able to increase it up to 100). I think that would be longer-term solution than keeping the "expand all translations" option.
I really do think that we should make the tag facility of Tatoeba more efficient and a better place to be.
Before even daring to ask our developers for some structuring of the current system, only a few simple considerations could drastically reduce the amount of existing tags and improve the conveyance of their intent and thereby the visibility and accessibility of every single one.
————————————————
Sorted by Count:
The first 64 of 153 pages of tags are tags with one occurrence only. I think many of them are not eligible to be treated as tags but should rather be a comment on the sentence.
A few days of review and sorting out could go a long way towards a major improvement.
————————————————
Sorted by Name:
Looking at the 5 pages of tags that don‘t start with a letter of the alphabet the following observations seem to be worth mentioning:
The 18 tags starting with # are uniformly monopolized by ‚Almanac de Interlingua‘ (itself a tag - with 410 occurrences) and do only occur in tandem with it.
Because of typos (2104 instead of 2014), (missing) empty spaces and differences like ‚Dec. vs Dec‘ - 5 out of the 18 are only attached to 1 sentence and are redundant, what leaves us with 13 #-tags in total.
Even if the ‚Almanac de Interlingua‘-tag with 410 occurrences makes sense, the 13 #-tags (with Issue number and Release date only) don‘t. They cannot be reused for any other application and should explicitly be prefixed with ‚Almanac...‘!
‚Almanac de Interlingua - # 1 - Oct. 2009‘
The tag ‚Almanac de Ainterlingua’ has only 1 occurence and seems to be a typo.
————————————————
* “man“ as person (3)
* “man“ meaning person (1)
* “man“ meaning human (1)
looks like being candidates for one single tag. About starting with quotation marks -> see System-Tags below...
————————————————
* „that that“ (1)
* that that (47)
search for ‚that that‘ sentences result is several thousands which could be tagged by someone ;-)
————————————————
* s-a (1)
* ‘-‘ it is used for linking two different parts of (1)
* ‘s‘ = reflexive pronoun (1)
do not make sense as tag (no language information etc.) and are only used in one common sentence
https://tatoeba.org/eng/sentences/show/5130610
————————————————
* (Appius Claudius Caecus)
occurs in 2 sentences and should be conformed to hundreds of similar references made with
* by Appius Claudius Caecus
————————————————
All Esperanto grammar tags used for denoting tense/mode etc. with groups of
* -as
* -is
* -os-
* -us
* -u
* -i
* -nte
should be prefixed with Esperanto or a language code
————————————————
Numbers like
* 1762
* 1790
* 1816
* 4072
make no sense without context and are always used in conjunction with other tags.
They should either be incorporated in the contextual tag or explicitly and uniformly be extended with
* 1762 (year)
* 1762 a.d.
or what ever the number tries to convey.
Some ‚body’ has to decide which format is recommended for years e.g.
————————————————
* 1/1
* 1/2/1
* 1/2/3
* 2/1/2
etc.
are all monopolized by Esperanto and have no obvious meaning as to be eligible for being tags
Not even a prefixed country code would make the intent of these random numbers any clearer.
————————————————
What is the ‚official‘ language of tags?
* 2 sentences (1159)
* 2 orações (2)
————————————————
* 3 Henry VI (1)
What is the intent of the prefixed 3?
And it should be ‚from Henry VI‘ - just like all other citations are marked uniformly
————————————————
Tag ‚?‘ has one occurrence ;-)))
————————————————
SYSTEM TAGS:
There are 40 @-tags at the time of writing this.
I understand that the @-tag should be reserved for System information.
Maybe user tags should be restricted to starting with numbers, letters and maybe certain „“‘ punctuation only.
Tags like @NNC, @Japanese puns, @Islamophobic etc. don‘t match these requirements.
@check translation
@check A-to-B translation
is not necessary as a tag (endless number of combinations) and should for individual needs be done with a comment anyways and a List for collaboration.
etc., etc., etc.
————————————————
The set of @-tags or other potential System tags like a #-tag etc. should be maintained by a very restricted group of admins to guarantee their small number and unified use because of recommended applications.
————————————————
There are still a number of open tag-related issues on GitHub.
https://github.com/Tatoeba/tatoeba2/issues/961
Allow admins/corpus maintainers to merge tags (2015)
https://github.com/Tatoeba/tatoeba2/issues/333
Add categories for tags (2014)
https://github.com/Tatoeba/tatoeba2/issues/330
Add a way to delete tags from the set of possible tags through the UI (2014)
https://github.com/Tatoeba/tatoeba2/issues/305
Prevent users from adding unnecessary new tags (2014)
Search "tag" https://github.com/Tatoeba/tato...+is%3Aopen+tag
You have obviously spent a long time considering this problem, so perhaps you should open several issues on GitHub, explaining the problems and perhaps suggesting several approaches to solving the problems.
Well, almost all of the above mentioned problems could be solved in 20 minutes by someone with the permission to rename (for typos) and delete tags (duplicates). I have them already properly laid out and justified.
Others that require some knowledge of policies or decision-making (how to extend year numbers ‚1848 a.d.‘ or ‚1848 [year]‘ in a multi-cultural environment) could follow suit.
The wrong audio recordings, hinted to with tags like
• incorrect audio (2)
• wrong audio (2)
are not seen by the right people with the responsibility to change such cases and remain in the corpus since as far back as 2014.
So I have already addressed the audio-tag issues by providing comments and the official @-tags to all sentences. So they are just waiting for some admin to delete the wrong and redundant tags to be left with a clean set of 3 remaining ‚official‘ tags.
https://tatoeba.org/eng/wall/sh...#message_35382
The Wall is a shared space. It is not the place for one person to post daily lengthy bug reports or enhancement requests. You have now had two people (CK and me) suggest to you that you open these as issues on GitHub. It's not just a suggestion anymore.
By the way, telling our busy developers and admins (or any other members of the community) the order in which they should tackle issues, or how long it should take to fix them, is not the way to get them to the front of the queue, or to make friends.
Please repost this at GitHub. This thread is now closed.
Searching the tags for ‚audio‘ I get the following result
• has audio (559)
• Audio (1)
• by Cl-audio Magris (1)
• incorrect audio (2)
• wrong audio (2)
in addition to the officially supported
• @change audio
• @move audio
• @wrong audio
I have added comments and official @-tags to all entries, except for the (559) ‚has audio‘ tags, but I think they are redundant anyways these days.
So I think a nice clean-up of the unnecessary tags by somebody with permission to delete tags could be performed.
DATA: CREATION, GATHERING and LOSS of information
I think it‘s safe to say that every contributor on Tatoeba is trying to make the most use of their time by finding workflows that suit and complement their skills and knowledge about certain languages.
Every time we consume blocks of information (by reading sentences, going through metrics, analyzing graphs etc.) and correlate them in our brains with other blocks, we essentially create new information on the fly. Some of this pieces of information can be made permanent by contributing or translating sentences, or linking existing ones. So subsequently new pieces of information can be deduced from this data and made available in the UI, like indirect links etc.
However, when I observe my own workflow I realize how much useful knowledge I create on the fly - a vast temporary set of data that is impossible to be remembered in a structured way and therefore gets thrown out of short-term memory very soon.
A consequence of this data loss is that a lot of redundant work has to be done over and over again by every single contributor.
In the last weeks I have given these underlying workings and mechanics a lot of thought and with the help of many of you I have come to some conclusions, which I’d like to share.
THE LINKING SYSTEM:
The simple design of the linking system makes it on the one hand very easy to understand and work with, on the other hand I consider it as being one of the major culprits for how valuable data gets lost.
Indirect links are ‘generated only’, or more precisely put, they are ‘two-hops-relationships’, translation of translations that are not stored but rather deduced from the generic SENTENCE and LINKS datasets.
PROBLEM:
So one way of contributing to Tatoeba is to turn these indirect links into direct ones if need be. That also means we are reading through tons of indirect links and evaluate for every single one of them whether it should be converted or not.
However, when we assess it to be a worthy candidate and we link it to the base sentence on top of the list, we completely ignore the fact that the remaining already checked indirect links - the non eligible candidates - ARE in fact non-eligible. This information is nowhere to be stored! They remain as a big unstructured blob.
So when the next contributor takes their turn, the whole list has to be re-assed entirely -and against the benefit of maybe gaining one or two conversion from indirect links into direct ones, stands this vast inefficient redundant task of having to re-read the list from scratch every single time.
PROPOSAL:
So I am proposing the introduction of a second LINK file that stores the information of a sentence being explicitly marked as an indirect translation of the base sentence. This second LINK list is just an extension and does in no way interfere with the existing dataset.
BENEFITS:
The UI can now display indirect links in two ways (e.g. different colors or different symbols) and present them in a grouped fashion, like direct links appear as a group on top of each sentence list.
So when a contributor is checking for indirect links in the languages they are working with, they can still press the link symbol, but instead of immediately triggering the linking-action, being presented with a small call out selection box
• Direct link (explicit)
• Indirect link (explicit)
which on selection is
• adding a link to the LINK dataset
• adding a link to the new LINK2 dataset
Because of the grouped presentation the next contributor who checks for similar languages doesn’t have to go through the whole set of indirect links anymore but only through the group of not explicitly marked indirect links in order to find candidates for an indirect-to-direct conversion, knowing that the explicitly marked ones have already been checked by someone else, and hence are not eligible or suitable for being direct links.
And if they wanted to double-check the already checked explicit ones they would also find them in a convenient group for doing so.
FURTHER IDEAS:
I haven’t got the complete picture of direct-links mechanics yet but I could very well image that after further investigation the same distinction could be useful for direct links, e.g. to show under which circumstances a direct link was created (system, user explicit, de-coupling etc.).
If such information is valuable to accommodate a certain workflow it could also be used to display direct links in a system of colors/symbols to further enhance information density and quality of the linked sentence list.
CONCLUSION:
My goal here is to provide a facility to make the linked sentence list as accurate as possible by getting rid of as many implicit indirect links as possible in favor of gaining direct links and explicit indirect links.
As an additional bonus we would also be able to create indirect links to new sentences that have no translations yet, and will therefore never show up as similar translations in any list because of the two-hops-rule.
This side effect is essentially extending the model from indirect links just being translations of translation, to being a first class member - a real indicator for related sentences that have similar meanings. This would IMO drastically increase the value of the linked sentence list and the corpus in general.
And because of the modular approach with different LINK datasets and its non-interfering character, extended features could be introduced step-by-step over time.
> So one way of contributing to Tatoeba is to turn these indirect links into direct ones if need be. That also means we are reading through tons of indirect links and evaluate for every single one of them whether it should be converted or not.
Please take into account that your focus and workflow may not match other people's. From the comments you've made recently, I think that you are particularly concerned with indirect links, and with judging whether they can and should be made into direct links. But the way that many (most?) people look at them, and the way that the database was set up, they are an epiphenomenon, something useful, but not essential, to producing direct links, and also useful in figuring out a likely meaning of a sentence.
> My goal here is to provide a facility to make the linked sentence list as accurate as possible by getting rid of as many implicit indirect links as possible in favor of gaining direct links and explicit indirect links.
By "explicit indirect links", I guess you mean indirect links that are marked as NOT being good direct links. The effort of marking up links in such a way feels like clearing a beach of sand with a teaspoon. I have the same attitude towards this idea as I do toward massive marking of sentences as OK in languages (such as English) where the overwhelming majority of sentences are OK. (One objection is that the task is so mind-numbing that even sentences with errors end up being marked as OK.) But even that gargantuan task has a number of people willing to do it whose only qualification is a knowledge of English. Who would do all this markup, given that we have a limited number of people, each of whom is knowledgeable in a limited number of language pairs?
It's important to take into account cognitive load (how much information someone can keep in their mind), screen real estate (how much room there is on the display), and computational complexity when proposing a feature. It's also worthwhile to balance it against all the other bugs that need to be fixed and features that could be implemented. It's great that you're thinking about how to improve our system, but I can't say I'm enthusastic about this proposal.
Let me first summarize the points you have made and quickly list them here in a non-chronological order that suits my line of thought and then respond to you in 3 different ways, being
• A. Picture a short UI scenario with a potential workflow without arguing too much
(let us see how you‘ll feel afterwards about the points you made, just letting it sink in as unbiased as possible)
• B. Give a short answer to the points you raised.
• C. Add some additional thoughts to the short version if necessary
That should make it an easy digestible read and maybe liven things up a bit on your enthusiasm scale ;-)
————————————————————
> 1. ‘Indirect Links’ - their prominence, usefulness but (non-)essentiality
> 2. Cognitive load - screen real estate - computational complexity
> 3. The effort of marking up links in such a way feels like clearing a beach of sand with a teaspoon.
> 4. Who would do all this markup, given that we have a limited number of people, each of whom is knowledgeable in a limited number of language pairs?
And yes, by ‘explicit indirect links’ I am referring to the links that would come from the new LINK2 dataset file I proposed to be implemented, and not from the two-hop deduction of the current LINK file - these would be the ‘implicit indirect links’.
————————————————————
A. - THE SCENARIO
————————————————————
• You open up a sentence page and you see the bold faced source sentence with 50+ linked sentences listed beneath
• About 6 of them are marked with a fat blue arrow
• 2 more are marked with a fat blue hyphen only (without the pointing arrow part)
• Then there are those 40+ gray links
• First the ones marked with a gray arrow, maybe 25+
• then the ones marked with a gray hyphen
This is exactly what you see in the current UI - except that neither the blue marked direct links nor the gray marked indirect links are divided into an ‘arrow’ group and a ‘hyphen’ group. But everything else is unchanged!
Today you wanna link some sentences because you know that the system is adding a lot of indirect links to the list every time you create a direct link, and many of them are likely to be potential candidates for direct links too.
• So you look up the sentences in the languages you are specialized in
• and you find 3 in the ‘blue block’ and 3 in the ‘grey block’
• You are of course interested in the ‘implicit indirect links’ marked with gray arrows
• and of course you have to read them sequentially
• You read the first sentence marked with a gray arrow and decide that it is a candidate for a direct link
• You click on the chain icon and choose the option ‘Direct Link’
• The gray arrow turns into a blue arrow instead
• and gets shifted up to the other ‘blue’ sentences immediately
• You read the next sentence and find it to have a similar meaning but not being eligible for a direct link
• So you click on the chain icon and choose ‘Indirect Link (explicit)’
• The gray arrow turns into a gray hyphen indicating that it is registered as not being eligible for a direct link anymore
• and gets immediately shifted down in the group of other sentences with gray hyphens
• Reading the third sentence you are not sure whether it is eligible for a direct link or not, so you simply leave it as is
• You do this for all the languages that you are confident of being enough experienced in.
Sometimes later someone else has the same idea of direct linking some sentences and comes across the same sentence. Having a similar language expertise this someone will only find the sentences you couldn’t decide upon in the list of gray arrows.
Nobody will redundantly be confronted with the already gray-hyphen marked sentences over and over again.
————————————————————
B. - SHORT COMMENT
————————————————————
> 1. ‘Indirect Links’ - their prominence, usefulness but (non-)essentiality
Look at our sentence page from above
• 1 source sentence (slightly bold faced)
• 8 sentences marked with blue arrows
• 40+ sentences marked with gray arrows!!!
I don’t buy in in the argument of non-essentiality when about 75% of the page is filled with sentences marked with gray arrows, especially not as a consumer of the corpus.
————————————————————
> 2. Cognitive load - screen real estate - computational complexity
As you have seen in the SCENARIO above, the interface has not changed at all besides compartmentalizing and displaying the former gray arrow section in two groups (arrows, hyphen) to distinguish between implicit and explicit indirect links
• implicit links being deduced from two-hops in the LINK dataset
• explicit links derived from human evaluation and input (LINK2 dataset)
The chain symbol now lets you choose your linking option.
So I can’t see any bad influence in regards to cognitive load or screen real estate issues.
Computational Complexity has to be assessed by the developer team.
————————————————————
> 3. The effort of marking up links in such a way feels like clearing a beach of sand with a teaspoon.
In the current interface, if you are reading a sentence in the indirectly linked section and you decide to move it over to the directly linked section you have to link it by clicking on the chain symbol. That’s according to you the whole purpose of displaying the indirectly linked sentences anyways.
But if you already have read the sentence anyways and found it not eligible for a direct link you might as well explicitly link it ‘indirectly’ - in the same manner, in one go.
All it requires is to have the chain symbol present a little option call out to choose between ‘direct and indirect link’ (instead of triggering linking directly).
There is almost zero overhead involved for the first contributor but every subsequent contributor would greatly benefit from not having to assess the whole list of already read and evaluated entries again, just because an earlier human assessment was not stored properly.
In addition you could easily check all explicit links for linking errors because they are nicely grouped together.
One quick look tells you how many “unstable” system deduced indirect links you have that are ready for being converted to direct links or ‘stable’ explicit indirect links.
————————————————————
> 4. Who would do all this markup, given that we have a limited number of people, each of whom is knowledgeable in a limited number of language pairs?
Well I guess bullet 3 already gave away the solution.
When you read a sentence for the purpose of linking then link it in either case, according to its eligibility...
————————————————————
C. - SOME ADDITIONAL THOUGHTS
————————————————————
> 1. ‘Indirect Links’ - their prominence, usefulness but (non-)essentiality
Why I am relatively concerned with indirect links is because even taking into consideration their originally intended use and the history of the structure of the corpus, the gray arrows have become very prominent in the UI and this infers a certain ‘importance’ to the user of the corpus, who subsequently expects a certain standard of correctness with regards to the assignment to the ‘direct’ or ‘indirect’ group of sentences. If they find a lot of obvious direct links marked with gray arrows only, they might think, why bother at all about a distinction.
It’s not only the contributor who sees the UI but also the user this corpus is intended for. And as consumer they might not see the gray block merely as a springboard for a streamlined creation of direct links but rather as a source of additional information and inspiration. And as long as it is also a UI for data consumption I think the displayed information deserves the highest possible level of accuracy.
In addition I find it a very conservative approach to refrain from upgrades in functionality (even if it sometimes requires a little paradigm shift) just because of clinging to some legacy conventions.
Rising from a mere convenience existence to a 1st class member of the data structure with relatively little effort (IMO) could be a good thing for indirect links and have positive consequences on the quality of the overall service.
————————————————————
> 2. Cognitive load - screen real estate - computational complexity
The division of the ‘blue” group into blue arrows and blue hyphen is just hinting to a possible extension of the ‘gray indirect link model’ over to the blue direct links group - as shortly mentioned in the FURTHER IDEAS section in the original post above. This is music of the future so lets focus on the gray indirect links.
————
CONCLUSION
————
The UI is the mirror to the soul of the service. And you have to like it to do loads of tedious work in it. Every improvement goes a long way in attracting contributors who eventually keep the whole thing going. No contributors/users - no need for a service.
Being able to display the results of a query as condensed as possible without too much noise can boost productivity. That’s why I am trying to bring little things to your attention
• https://tatoeba.org/eng/wall/sh...#message_35275
• https://tatoeba.org/eng/wall/sh...#message_35171
Arguments like ‘Please take into account that your focus and workflow may not match other people's’ are some nice pieces of advice, however, as long as they are not based on metrics or measurements they are not very helpful. A handful of people discussing -with their own preferences in mind - are very unlikely a good representation of what is really going on in the wild.
I recently talked to @deniko and he said ‘Well, one of my favorite things to do on Tatoeba is linking sentences.’ So, who knows what is really needed. There are obviously enough sentences being linked, which means they must have been read before. So chances are that 50% have been read and temporary knowledge about them has been discarded instead of being stored.
An argument like ‘It's also worthwhile to balance it against all the other bugs that need to be fixed and features that could be implemented’ of course must be accepted and can’t be reasonably argued against.
The Advanced Search offers a possibility to find indirect translations:
for example: German sentences containing the word "Boot" with indirect translations in French:
https://tatoeba.org/eng/sentenc...&sort_reverse=
You could then easily turn these into direct translations where appropriate.
(Unfortunately, the search doesn't display more than 1000 sentences - that's the reason why I choose "Boot"-sentences).
Or you could regularily go through all the recently added German sentences and see if they have indirect links to French and vice versa.
I know it's not what you proposed.
I feel the same as Alan - not many members will be particulary keen to focus on linking. Adding sentences, translating sentences, even correcting sentences involves more creativity. It's just more fun.
Also, I noticed that linking is relatively error-prone. People often do it on the fly, maybe with languages they don't know so well.
Good point, brauchinet. I hadn't thought about the fact that we already provide searches that display this information.
Two more points:
(1) Every time a new table (like the table of indirect links that mramosch proposed) is added, it now needs to be reviewed whenever anything it refers to changes. That means that every time that either of a pair of linked sentences is modified, or deleted, the table would need to be revisited.
(2) People will have different opinions on whether two sentences should be linked. It's common enough that person A would be reluctant to link two sentences, but wouldn't protest if person B did it, provided that person B had a good justification. With the approach that mramosch is proposing, person A would have to decide between:
- making a direct link
- blocking a link for everyone (which would require some kind of override/undo mechanism if people decided that this was not justified)
- doing nothing (which would be like what we're doing now, but doesn't conform to the model of giving each direct link a thumbs-up or thumbs-down vote that mramosch is trying to achieve)
(1) As it is a table of links it follows the same rules and suffers the same problems as the already existing LINKS table that correlates sentences with translations.
Changing code upstream may break code downstream.
Mechanisms like blocking sentences after audio has been assigned is an example of protection against such cases.
The actual implementation has to be decided by the developer team, that’s not my main point. Be it a link table or any other database record field.
I just figured that the link table is as generic as possible and wouldn’t interfere or mess with the existing data structure, just add on.
(2) There is never any blocking of a link going on.
Clicking on the chain icon of an ‘explicit indirect link’ lets you always choose between
• Direct link
• Indirect link (implicit)
which simply deletes the link in the new dataset and, in the case of ‘Direct link’ also creates a new link in the existing LINK file.
Just like breaking and creating links works with regular direct links.
And doing nothing just means you are leaving it for another person to decide whether a sentence eventually is a ‘direct link’ or an “explicit indirect link”.
Both are stable states, evaluated and executed by humans.
An implicit indirect link is always an unstable decision made by the machine and should be escaped from as soon as possible.
> An implicit indirect link is always an unstable decision made by the machine and should be escaped from as soon as possible.
This sentence sounds really strange to me.
You aren't familiar with graphs, are you?
Consider the following graph:
...A
../
.B
..\
...C
Here C is indirectly linked to A. Now when you add a direct link between A and C you get:
...A
../.|
.B.|
..\.|
...C
Now A and C are both directly and indirectly linked. Adding the direct link doesn't remove the indirect link. We just do not show it anymore in the UI (as we don't show "indirectly-indirectly-linked" sentences (i.e. "3-hop-links") and so on).
As long as there is a direct link between B and A and B and C there is also a indirect link between A and C independent of all the other links in the database. I don't see any "unstable decision made by the machine" here.
Edit: Unfortunately whitespace isn't preserved when showing a wall message. You can ignore the dots in my ASCII art, they are only there to align the rest. (Note to myself: we should probably fix this)
> Now A and C are both directly and indirectly linked. Adding the direct link doesn't remove the indirect link. We just do not show it anymore in the UI
We already have discussed this with Trang in another message, I am totally aware of this fact.
By “unstable” I am not referring to data integrity but rather to the fact that it is not established yet, whether it actually is a direct translation or just an indirect one for real.
By making it explicitly ’direct’ we establish its ‘direct’ status. By making it explicitly ’indirect’ we establish its ‘indirect’ status. But leaving it ‘implicitly indirect’ both status that matter in the real world are still possible. That’s why I said the machine made an ‘unstable’ decision.
> I feel the same as Alan - not many members will be particulary keen
> to focus on linking. Adding sentences, translating sentences, even
> correcting sentences involves more creativity. It's just more fun.n the on ono
Well, you have to widen your mind a little bit ;-)
I think you are not aware of the impact and consequences this approach has on other parts of Tatoeba.
• When you decouple a sentence you do not loose all the indirect links anymore just because they got deduced from the link you just broke. The ones that were made explicit will still populate your list.
And what’s even more amazing and crazy is the fact that you can deduce another ‚two-hop-relation’ with the explicit-LINK-table.
That means when you link two sentences the system populates the list of either one not only with
• (1) translations (direct link)
• (2) translation-of-translation (implicit indirect link)
but also with
• (3) all explicit indirect links from the direct links (two-hop)
which can immediately be used to be turned into direct links e.g.
So all the work that was done in the past can be leveraged even more and in different places.
And because (3) is deduced exactly the same way as (2) - just from a second LINK list - there is no hard-linking involved, which means breaking a link is clean and has zero side-effects ;-)
Mahdollisuus merkitä suora linkki huonoksi auttaisi toisaalta siltä kantilta, että se korvaisi nykyisen epäsymmetrian linkkien poistamisen ja lisäämisen välillä. Tulisi symmetrinen tilanne linkin lisäämisen ja kieltämisen välille.
> As an additional bonus we would also be able to create indirect links to new sentences that have no translations yet,
I'm still interested in a concrete example (preferably from the current corpus) for this use case.
Don’t ask me how this UI interface would look like for this application, because AFAIK there is even no dedicated interface for directly linking two sentences.
You can
• turn ‘implicit indirect links’ into ‘direct links’
• turn ‘explicit indirect links‘ into ‘direct links’ (hopefully soon ;-) - just joking...
or
• create a redundant new copy of an already existing sentence because your link partner doesn’t show up in the indirect links list and hope that you made no typo and the bot script cleans everything up properly.
As long as you consider indirect links only as translations-of-translations and a springboard for linking this may not be attractive for you, but if you consider them being similar sentences that are worth being present in the context of your source sentence then the following situation is easy to imagine
You enter a new sentence (A), and by default it has no links. And you know about a sentence (B) that is similar but not eligible for a “direct link” but you still want it to show up under your base sentence as indirect link.
You’d have to find a common friend (C ) that happens to be a direct translation of the sentence you want to add (B). And than with the hacks from above link (A) and (C ).
Now (B) is two hops away from (A) and will be shown in the list as indirect link.
Which essentially means - without (C ) no indirect connection between (A) and (B).
With the introduction of ‘explicit indirect links’ you don’t need this whole dance of finding and linking other sentences just in order to connect (A) to (B).
> Don’t ask me how this UI interface would look like for this application,
I'm not asking about the UI.
What I would like to get from you is a concrete example of two sentences which you want to indirectly link, e.g. "This house is green" should be indirectly linked to "Pierre habite à Paris."
> As long as you consider indirect links only as translations-of-translations and a springboard for linking this may not be attractive for you, but if you consider them being similar sentences that are worth being present in the context of your source sentence then the following situation is easy to imagine
Are you speaking of indirectly linking sentences in the same language? Have you read already https://github.com/Tatoeba/tatoeba2/issues/1902?
> However, when we assess it to be a worthy candidate and we link it to the
> base sentence on top of the list, we completely ignore the fact that the
> remaining already checked indirect links - the non eligible candidates - ARE
> in fact non-eligible. This information is nowhere to be stored!
This issue (or at least a similar one) has been reported already:
https://github.com/Tatoeba/tatoeba2/issues/1980
I think the hardest part is to design the UI. If you have ideas on that, please draw them :) A picture is worth a thousand words.
In any case I don't consider this a high priority. If the goal is to optimize the workflow of linking, then it would be too early to optimize. We still have a relatively efficient way to link, mentioned by brauchinet and also documented here:
https://en.wiki.tatoeba.org/art...uickly-linking
As long as you can easily find sentences to link from this method of linking, there's no real need need to store which sentences are not translations of each other. When you get to point where 50% of the results are sentences you cannot link, then we can start thinking about how we can optimize.
The goal is not only the optimization of the linking workflow but much more importantly
https://tatoeba.org/eng/wall/sh...#message_35346
which leaves us with even more sentences that can be linked, and in even different places.
And for the UI - as you can see in the SCENARIO above
https://tatoeba.org/eng/wall/sh...#message_35342
the interface has NOT to be changed at all besides displaying the currently gray arrow sentences in two flavors - arrows and hyphen - and group them accordingly, just as an obvious distinction between implicit and explicit indirect links.
The chain symbol lets you select your linking option
• for gray arrows: direct link vs. explicit indirect link
• for gray hyphen: direct link vs. implicit indirect link
• for blue arrows: decouple/de-link vs. explicit indirect link
And as a bonus addition you can display all those new deduced ‘explicit indirect links’ in the list of EVERY directly linked sentence
• e.g. with a gray big dot, instead of arrow and hyphen
which makes the list even more complete and fertile for further linking, translating or simply consuming and enjoying.
> which leaves us with even more sentences that can be linked, and in even
> different places.
We don't need create "negative links" in order to find more sentences to link. We can use the translations of the indirect translations, and their translations, etc.
The limitation of our current system is that we are using a relational database and this is not optimize to calculate the whole graph around a sentence. We can only read the translations of translations. After that, it's way too slow. With another type of database, we could read the whole chain of translations and suggest people to link sentences that are more than 2 hops away from each other.
> And for the UI
The design you have in mind would not be a good design because it would require twice the amount of clicks for a contributor to link sentences.
Well, if the refinement into gray arrow-hyphen-dot groups is already almost indistinguishable from the current gray arrow-only design, then I guess it shouldn’t be that hard to find a solution for the remaining little chain symbol issue too. I am sure you’ll easily come up with something adequate, like click/double-click, two buttons etc. to avoid the additional click ;-)
> As long as you can easily find sentences to link from this method of linking, there's no real need need to store which sentences are not translations of each other. When you get to point where 50% of the results are sentences you cannot link, then we can start thinking about how we can optimize.
It seems that you are primarily concerned with the contributor perspective, my approach is also focused on the UX. As a consumer being able to assess the whole record with a single gaze (and as a contributor knowing immediately where to start work and where to put effort in) only because of a clever, structured presentation and the knowledge that e.g. a gray arrow means
• undefined status - yet to be defined
but the rest (gray hyphen, gray dot or blue arrow) means
• defined status - already checked by a human
is paramount because it gives me confidence in the accuracy of the service.
Seeing what extent of work has already been put into the record and assess its integrity just by the ratio of implicit:explicit (because everything essentially starts out as implicit without user involvement) gives me an idea of where to look best for reliable information and where to contribute improvements.
Thanks anyways for reading.
> It seems that you are primarily concerned with the contributor perspective
Because the feature needs contributors to perform the linking. It would be useless if you make it inconvenient and no one wants to link anymore.
Is there a quick way for you, to retrieve the following information from the database?
Not counting the automatic link that is implicitly created for free when a new translation gets created, what is the monthly %-ratio between
• New translations
• New original sentences
• Link/Delink actions performed on already existing records
e.g.
• 48:13:39 — by 283:167:45 users (May)
• 50:10:40 — by 419:199:71 users (April)
for the last year (or at least the last six month).
It would really be interesting how much of the contributors work is going into which department, especially how much focus and effort is actually put in the linking part and by how many different contributors.
> The design you have in mind would not be a good design because it
> would require twice the amount of clicks for a contributor to link sentences.
Simply use an identical clone of the sentence page that (for clarity of intent) has a slightly modified chain symbol that on click offers this two-step process for selecting the target.
Contributors can switch back and forth between these two pages depending on the workflow they prefer for the task at hand.
Similar to switching between Normal/Edit Mode.
Perhaps to clarify: I think the UI design is difficult because I don't think we can build this feature on top of our legacy design.
I mean, of course we can try to squeeze one more button/option in the sentence component, but this strategy won't result in a feature that makes contributors want to link more.
I have ideas on how to implement this but it requires a complete shift on how the website is overall designed and structure. That's why I think it's difficult.
Well, you have a much more complete insight into the workings under the hood to judge and I am sure you will be finding and implementing the best solution possible for all of us.
Thanks for caring so much about the rest of us :-)))
**Reviews in new sentence design**
The reviews feature is ready to be tested on the dev website and as usual, we will need some people to test and report issues.
https://dev.tatoeba.org/
This is the last feature that needs to be implemented before we can switch to the new sentence design.
Note that this feature is not enabled by default. You have to enable it in your Settings with the option "Activate feature to review sentences".
Thanks!
It works fine, thank you. I just want to say two things.
- Deleted sentences still show up on reviews/collections page, and it's not possible to remove/unmark them.
https://i.imgur.com/NRyX0aX.png
- The default view of the edit bar is minimized. To rate sentences in the list view, we need to expand the bar on each sentence. If we had an option to change the default view of the edit bar, it would be more practical for proofreading and linking.
https://streamable.com/vg9w4a
Thanks for testing.
> Deleted sentences still show up on reviews/collections page
This is a known issue: https://github.com/Tatoeba/tatoeba2/issues/1795
> The default view of the edit bar is minimized.
There's a button in the green toolbar which will expand the menu for all sentences and keep it expanded as you go from a page to another.
> There's a button in the green toolbar which will expand the menu for all sentences and keep it expanded as you go from a page to another.
Thanks. I didn't see that button. It's indeed available on these pages.
https://dev.tatoeba.org/eng/sen...ists/show/8909
https://dev.tatoeba.org/eng/sen...ll_in/eng/none
But it isn't available on this one as there's no green toolbar.
https://dev.tatoeba.org/eng/act...of/soliloquist
> But it isn't available on this one as there's no green toolbar.
>
> https://dev.tatoeba.org/eng/act...of/soliloquist
Indeed. There's no toolbar yet on this page because the title is too long to fit in one line and it wouldn't be properly displayed in the toolbar.
I'll think of how to re-title this page when taking care of this issue:
https://github.com/Tatoeba/tatoeba2/issues/2074
The tooltip should say "Show fewer features" rather than "Show less features".
Also, the name of the owner of the sentence is extremely important information to me, and the fact that it is no longer displayed without my having to visit the sentence itself will disrupt my workflow. I use the owner's name in many different situations. For instance, I use it when correcting sentences (since I've learned which users are no longer active and thus are unlikely to see my comments, which users have a high error rate, etc.). But I also use it when looking up sentences for my own education. For instance, if I want to look up word X in Russian, it's important to me to see who contributed the matching sentences because their names serve as a quick index to the styles that I've become acquainted with.
It's true that this information would be less useful to a first-time visitor, but I really hope there's a way to provide it up front for those who use it all the time.
> The tooltip should say "Show fewer features" rather than
> "Show less features".
Thanks, I will correct this.
> Also, the name of the owner of the sentence is extremely important
> information to me, and the fact that it is no longer displayed without
> my having to visit the sentence itself will disrupt my workflow.
The owner of the sentence should be displayed. Perhaps you are experiencing this bug (or a similar one):
https://github.com/Tatoeba/tatoeba2/issues/2221 ?
I meant what CK mentioned below: the user name disappears in "display more" mode, and I don't want to have to keep switching modes.
I have created an issue for this:
https://github.com/Tatoeba/tatoeba2/issues/2326
I deployed on the dev website the changes for the menu to be displayed above the sentence block when expanded.
Could you test it and let me know if this works for you?
Yes, it looks good now. Thank you!
> Also, the name of the owner of the sentence is extremely important
> information to me, ...
I agree with this.
>> There's a button in the green toolbar which will expand the menu for all sentences and keep it expanded as you go from a page to another.
While we see the the owner's name in the "show less" version, when browsing while showing all the things we need using the "show more" version, we don't see the owners' names, which means we still need to constantly toggle between the two.
https://dev.tatoeba.org/eng/sen...ll_in/eng/none
Would it be possible to add a line above the tools, moving the sentence number and owner's name there, and always show all the tools?
This might likely solve some of the problems brought up by other members.
Also, since adding OK ratings to sentences is something I often do, I would like to have the full toolbar shown all the time instead of in a collapsed mode.
The way it is now, I have to click to expand to either add a rating, or to see if I've already rated it or not. That's a lot of extra clicking.
I hope that you don't force us to use the new design until some of these issues are resolved.
> The way it is now, I have to click to expand to either add a rating,
> or to see if I've already rated it or not. That's a lot of extra clicking.
There is a button in the toolbar to expand all the menus:
https://imgur.com/cDinvJe
> I hope that you don't force us to use the new design until some of these
> issues are resolved.
As mentioned back in April:
"We will still keep the possibility to switch back to the old sentence design via an option in the settings. This option will be available for a few weeks only, just enough time for us to ensure the features of the old sentence design have been covered properly in the new design. Then we will completely remove the old design."
https://tatoeba.org/eng/wall/sh...#message_34750
It is impossible to ensure that the new design will be perfect, but the goal is that it is usable enough. If you have other issues with the new design that heavily impacts your workflow, please report them.
I think that you shouldn't disable the traditional sentence design and force members to use the new sentence design until the website is fully mobile-friendly.
I know that one of the reasons that you haven't yet made tatoeba.org mobile-friendly is that you wanted to complete the new sentence design first.
My wish would be that you never disable the traditional sentence design, or at least delay disabling it for a year or so.
What exactly blocks you from using the new design?
I'm proofreading a user's sentences right now. Display 100 sentences a page.
1. When I clicked the "Show more features for all sentences", it took several seconds to change.
2. When I move my mouse over a translation or a translation of translation, the grey color takes some non-negligible time to appear. I mean by that that the human eye clearly see that it's not instant.
3. When I hover the copy icon, there is a tooltip, but no "hovering change of style". Doesn't really matter. However, when I click the button, during the time it takes to link the sentence, I have no indication that things are processing. Same for unlinking, so if I'm impatient, I click several time and I may unlink another sentence, that I will have to relink again.
I don't know if my browser has some responsibility in it, I don't think so, but all together, that gives a very laggy experience.
1. That's optimization issues. Angular is very slow at rendering after a certain amount of items in ng-repeat :/
2. I suppose you moved your mouse over a translation shortly after clicking the button to expand the menus? As long as the menu are not rendered, other interactions with the UI have to wait. That's why the grey background appears only after some time.
3. None of the icons have a hovering style. They all have a tooltip though. That should be enough(?). If we decide to change the color on hover for the copy icon, we have to do it for all icons.
As for the progress indicator, I suppose you're talking about the link/unlink icons and not the copy button. For this, I have updated the code so that every icon that involve an HTTP call have a loading animation. You can test it on dev.
IMHO this is really a step backwards. When I'm proofreading sentences, e.g. through the menu item "Browse by language", I don't see the 3 review icons. Everytime, sentence after sentence, I have to click on "Show more features" in order to see them. Or am I missing something obvious?
P.S. Just now I see this comment:
> There's a button in the green toolbar which will expand the menu for all sentences and keep it expanded as you go from a page to another.
Where? I dont find it.
>> There's a button in the green toolbar which will expand the menu for all sentences and keep it expanded as you go from a page to another.
> Where? I dont find it.
See https://imgur.com/cDinvJe
It's the icon on the right side with the upward and downward arrows.
Ok, Thanks, Rumpelstilzchen! Now I found it. But that button appears only in the "Browse by language" menu. It does not appear in "Latest contributions" or in the "Browse by tag", which is rather important for corpus maintainers browsing through sentences with the tags @change, @check etc.
> It does not appear in "Latest contributions" or in the "Browse by tag"
This button wouldn't have any use in the "Latest contributions". Or maybe I don't understand which page you mean. Do you mean this page:
https://tatoeba.org/eng/contributions/latest ?
For the "Browse by tag" page, it was forgotten and can be added for next week.
>>It does not appear in "Latest contributions" or in the "Browse by tag"
>Do you mean this page:
https://tatoeba.org/eng/contributions/latest ?
Yes, but you are right. There it's not much of importance.
>For the "Browse by tag" page, it was forgotten and can be added for next week.
Thanks!
When I look at the sentences I've reviewed:
https://dev.tatoeba.org/eng/reviews/of/AlanF_US
there's a box "Filter" in the upper right-hand corner. Within that box, the items "Sentences marked as 'OK'", "Sentences marked as 'unsure'", and "Sentences marked as 'not OK'" are preceded by the checkmark, question mark, and exclamation mark icons. However, the icons are in gray. It would make more sense for them to be in green, orange, and red, as they are next to the sentences.
I created an issue in GitHub:
https://github.com/Tatoeba/tatoeba2/issues/2333
Thanks!
+1
Color icons are much faster to recognize, even if only by a micro-second.
I think it might even be a good idea to add color into the icons on the tool bar of the new design for some of the tools.
"Search list or enter new list name"
This has a button that says "Create" which doesn't match the "search" option.
I accidentally created a new list in the following manner.
After searching for the list by entering a partial word, I clicked the checkbox in front of the list's name, then clicked the only visible button on the page to submit it to the list.
I realize that I should have been more careful, but I wonder if this will happen to others, too, who don't realize that you need to scroll to the "close" that may be off screen. (It was for me.)
I've created an issue on GitHub:
https://github.com/Tatoeba/tatoeba2/issues/2337
Deselecting "Display a link to expand/collapse translations when there are too many translations" doesn't seem to have any effect. I still see strings like "Show 1 more translation" next to a down-arrow. This is true even when I close the browser and come back. I'm using Firefox on Windows.
What's New on Tatoeba? - Your weekly recap °18
UPDATES
※ gillux reworked and improved the code related to the search feature. You want see any difference but it will allow developers to more easily improve the search feature, something I'm sure a lot of people can't wait to see happening. That's a huge work so let's give a warm round of applause to gillux.
※ The space to type a sentence is now multiline on all designs, making it easier to contribute long sentences. Thanks to Ricardo14 for adding this.
※ A settings allowing users that can choose the license of their contributions to choose the default license has been added. If you'd like to contribute under CC0, you can refer to this article https://en.wiki.tatoeba.org/art...-contributions
ON THE WALL
※ sharptoothed and CK created some charts about the most used languages on Tatoeba https://tatoeba.org/eng/wall/show_message/35208
※ Ricardo14 gave and impressive list of resources to learn languages https://tatoeba.org/eng/wall/show_message/35244
※ CK updated his list of native speakers with contributions https://tatoeba.org/eng/wall/show_message/35315
CONTRIBUTIONS AND LANGUAGES
※ 18 424 sentences have been added this week.
※ On Kimogol's request, Rendille has been added to Tatoeba, bringing the number of supported languages to 365 https://en.wikipedia.org/wiki/Rendille_language
※ As usual, thanks to all the members who helped translating 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: https://github.com/Tatoeba/tatoeba2
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...ce-translation
----------
Fun fact: Lake Malawi, located between Malawi, Tanzania and Mozambique, has more fish species than any other freshwater system on earth.
Last week recap: https://tatoeba.org/fra/wall/show_message/35221
See this recap on the blog: https://blog.tatoeba.org/2020/0...-recap_27.html
Is there a way to force an “upper case sensitive search’ for a word? This would - in German - reduce the amount of false positives considerably when searching for a noun that distinguishes itself from the verb just because of capitalization/case sensitivity?
e.g. Das Mitbringen...
There is no way to do this via our search, but you can do an ordinary case-insensitive search and use your browser (for instance Ctrl-F in Firefox) to search case-sensitively on the page.
As we have things set up, there is a single index for each language, which is case-insensitive for all languages that have capitalization. Using a case-sensitive index would require users to type capital letters when they need them, which would mean extra work. Furthermore, the fact that words are capitalized at the beginning of the sentence, irrespective of whether they are acting as a noun, could cause either false positives or false negatives.
In the case of "mitbringen/Mitbringen", I see 61 hits, none of which is capitalized. Those 61 results fit on a single page (if you have things configured so that you have 100 results per page), so a case-sensitive search is very quick.
‚mitbringen/Mitbringen’ was just the sentence that made me decide to ask for this option but I had other occasions where 1 single case was hiding in hundreds of counterparts, and that was difficult to trace as you can imagine.
I was rather thinking of something in the lines of adding a specifier (in the way ‚=‘ is used) right before the ‚word at hand‘ to request a separate case sensitive search for this word only but in the context of an entire phrase...
If you know how to do it, the easy way would be to download the exported files and do case-sensitive searches offline.
Thanks, but...
I wanted to do the search on the most recent data possible and I wanted to do it inline, right in the place where I am working on something...
Adding a specifier won't help unless the index stores information in the way you want to search it. Since the index is stored case-insensitively, the search will find case-insensitive matches. The equals sign (=) indicates that you want to match the word as spelled rather than perform stemming on it (removing likely suffixes before doing the comparison). It ignores capitalization.
Yeah, that‘s also how I understood the ‚How to Search for Text‘ wiki.
That‘s why I said ‚similar to the = specifier‘.
That using the current indexing is no option is also understood.
I thought maybe a second pass over the already filtered set that uses the first pass‘ indexed search result and does a case sensitive query on the remaining ‚real’ sentences. Like one does with the search function in the browser you recommended above but just done automatically without needing an explicit action invoked by the user.
And because a new specifier would not be part of the basic daily search routine and is not suited for languages without case sensitivity anyways it might not put too much additional load on the server most of the times, when used in these special occasions only.