Yes, they were marked as spam. The problem is solved. Thank you very much.

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.

I also wonder why it's necessary to hide translations at all on a sentence's page.

All the data is downloaded anyway, so why not just show it by default.

The plain html page for the above sentence was 643 KB when I downloaded it to check.
This doesn't count the external files, but many if not all, will likely be cached on the user's device.,

I can understand why it might be desirable for pages of sentences like what you get when you browse by language or do a search, since some people doing searches may not be so interested in seeing all the translations.


Experimenting ...

For comparison, in the old layout, when downloaded, the plain html file was 1.1 MB. I assume that the extra filesize has a lot to do with all the lists that are part of the page's code. I have a lot of lists, plus all collaborative lists add even more.

In the new layout's page, I changed every occurence of " to " and the file size went down to 469 KB (72% of the original). Perhaps the code will work as well with this, perhaps not.

I also wonder whether you could cut out some of the data that is being sent to perhaps speed things up and to require less bandwidth for those who don't have unlimited bandwidth internet plans.

Here is one of a lot of sentences on that page.

{"id":499788,"text":"Estoy enamorado de ti.","lang":"spa","correctness":0,"script":null,"transcriptions":[],"audios":[],"lang_name":"Spanish","dir":"ltr","lang_tag":"es"},

Is this necessary?
"lang_tag":"es"

Also, couldn't the following be generated easily enough from the "lang":"spa" part.
"lang_name":"Spanish"

All it would take is a 2-field external Javascript file and a bit of code. I can send you an example if you need one. The Javascript file would likely get cached, so there would be less being loaded each time from tatoeba.org.

The issue about the vocabulary count is independent from the new design.

For the other issues I will reply in the comments over there.

Not forever. Keeping it has maintenance cost.

I, too, would like to see the old design stay in place for a while.
I think it should definitely stay in place until the website has been converted over to mobile-friendly, which I think was the main purpose for changing this layout.

For the favorite button, you would have to use the feature to expand all menus. You would then see all buttons all the time.

The collapsed menu can only support 3 buttons and the (arbitrarily) chosen features were:
- translate
- edit
- list

If we display more, the username will sometimes be hidden for people who have long usernames. Unless you can justify that the favorite button is more often used than "translate", "edit" or "list", then it will have to remain in the hidden buttons.

The option to prioritize which language to display first in the list of translations has been discussed before, yes. I don't think it will be implemented before we switch to the new design though, it's not a very easy feature to implement.

To link sentences, you would now have to make use of the mechanism to auto-detect duplicates.
1) You copy the text of the sentence you want to link.
2) You add it as a translation of your current sentence.

Editing a sentence requires the same steps as before:
1) Clicking the edit button.
2) Changing the text in the input.
3) Pressing enter or clicking save.

Changing the language requires only one more step:
1) Clicking the edit button (as opposed to clicking the flag).
2) Selecting the language.
3) Clicking the save button.

If any corpus maintainers has to fix languages so often that it is needed to eliminate the 3rd step, I'd like to know how frequently it happens and why it happens (because it really shouldn't happen often).

Thanks for replying. Sad news, I guess.

Looks like it has been fixed. It's not happening anymore. I was using Chrome browser on my iPhone 6. It's the same search box where you would type in the text string that you want to search. When the results are displayed, that search box should retain the search string you had typed, but it was missing. Anyway, it seems that it is no longer exhibiting this behavior.

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

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.

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)

> 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 ;-)

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).

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.

> 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.

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.

What exactly blocks you from using the new design?

>> 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.

I created an issue in GitHub:
https://github.com/Tatoeba/tatoeba2/issues/2333

+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.

I've created an issue on GitHub:
https://github.com/Tatoeba/tatoeba2/issues/2337