+1 Thank you for voicing it out, Silja.

saeb has talked about how we need the ability to see this kind of information easily. I don't know whether he's planning on implementing this in his Tatoeba rewrite project.

When I'm worried that I might be creating a duplicate sentence, or want to see similar sentences for whatever reason, I generally open another window and perform a search with the main words that it would contain. I know that that's time-consuming, however.

That's a very intelligent question, Silja. It would be great to get such a function.

It's not possible with our current database. By "not possible" I mean that it would be slow as hell, and you'd probably get your information faster by checking manually each indirect sentence.

This is something we've wanted to implement already several years ago (and not just displaying the translations of indirect translations, but the entire translations chain), but it's not exactly easy to do.

Saeb wrote in his GSoC proposal[1]:
"Also, a move towards a graph database or the use of graph algorithms on top of a relational database will greatly reduce server load and enhance page response time."
^ That would allow the feature you're asking for (so be nice with saeb and send him lots of love/fan letters so that he gets the motivation to get this done).

[1] https://dl.dropboxusercontent.c...al-public.html

I was thinking about it, too. Currently I'm just adding my translations, if there are no any indirect translations, and hope for an automatically script. Checking all the indirect translation is too slow. Adding a translation is much faster in most cases.

> Is there any possibility to display all the translations of indirect translations in a specific language when I browse sentences?

No. Not because we can't but because it would be very impractical and would require too much resources that we don't and won't have. The ground work for this is already in my gsoc project though but it's nowhere near usable (read: it's a backend with no interface at this point).

I can go into more details about why it's too impractical but that would probably be more suited to a long blog post or something, but in short: the current database is relational, meaning, it's tables referencing other tables. To get the indirect links you need to first get the direct links (1 lookup) then depending on the number of sentences you get make 1 lookup for each of them or whatever. You can quickly see how the number of lookups explodes the deeper you follow the links. This means one request from you can probably overload the server if the sentences has lots of translations and the translations of those have lots of translations too, etc... Solving this problem needs a complete rewrite of the current schema and lots of domain specific knowledge of graph databases/algorithms, which I think is time consuming and just hard. I don't think I would've volunteered for this if liori hasn't been around and if I didn't already try making it work (as a proof of concept) back in January.