clear
{{language.name}} Nenhum idioma encontrado.
swap_horiz
{{language.name}} Nenhum idioma encontrado.
search

Mural (5.871 tópicos)

Dicas

Antes de fazer uma pergunta, certifique-se de que tenha lido o FAQ - Perguntas Frequentes.

Nós almejamos manter uma atmosfera sadia para discussões civilizadas. Por favor, leia as nossas regras contra mal-comportamento,

Últimas mensagens feedback

mramosch

há uma hora

subdirectory_arrow_right

mramosch

há 2 horas

feedback

DostKaplan

há 3 horas

subdirectory_arrow_right

CK

há 11 horas

feedback

Aiji

há 12 horas

subdirectory_arrow_right

AlanF_US

há 12 horas

subdirectory_arrow_right

AlanF_US

há 12 horas

subdirectory_arrow_right

TRANG

há 13 horas

subdirectory_arrow_right

TRANG

há 13 horas

subdirectory_arrow_right

mramosch

há 23 horas

mramosch mramosch há uma hora 28 de maio de 2020 12:32 link Permalink

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.

mramosch mramosch Criada em há 2 dias, editada em há 2 dias Criada em 25 de maio de 2020 15:36, editada em 25 de maio de 2020 15:55 link Permalink

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.

{{vm.hiddenReplies[35336] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
AlanF_US AlanF_US Criada em há 2 dias, editada em há 2 dias Criada em 25 de maio de 2020 17:27, editada em 25 de maio de 2020 17:30 link Permalink

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

{{vm.hiddenReplies[35337] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
mramosch mramosch Criada em há 2 dias, editada em há 2 dias Criada em 26 de maio de 2020 01:03, editada em 26 de maio de 2020 02:21 link Permalink

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.

brauchinet brauchinet Criada em há 2 dias, editada em há 2 dias Criada em 25 de maio de 2020 18:03, editada em 25 de maio de 2020 18:10 link Permalink

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.

{{vm.hiddenReplies[35338] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
AlanF_US AlanF_US há 2 dias 25 de maio de 2020 20:42 link Permalink

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)

{{vm.hiddenReplies[35340] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
mramosch mramosch Criada em há 2 dias, editada em há 2 dias Criada em 26 de maio de 2020 01:42, editada em 26 de maio de 2020 12:38 link Permalink

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

{{vm.hiddenReplies[35343] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
rumpelstilzchen rumpelstilzchen Criada em ontem, editada em ontem Criada em 26 de maio de 2020 20:07, editada em 26 de maio de 2020 20:18 link Permalink

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

{{vm.hiddenReplies[35347] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
mramosch mramosch Criada em ontem, editada em ontem Criada em 26 de maio de 2020 20:45, editada em 26 de maio de 2020 22:51 link Permalink

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

mramosch mramosch Criada em ontem, editada em ontem Criada em 26 de maio de 2020 19:50, editada em 26 de maio de 2020 19:57 link Permalink

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

Thanuir Thanuir há 2 dias 25 de maio de 2020 19:18 link Permalink

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.

rumpelstilzchen rumpelstilzchen ontem 26 de maio de 2020 19:33 link Permalink

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

{{vm.hiddenReplies[35345] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
mramosch mramosch Criada em ontem, editada em ontem Criada em 26 de maio de 2020 20:32, editada em 26 de maio de 2020 20:35 link Permalink

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

{{vm.hiddenReplies[35348] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
rumpelstilzchen rumpelstilzchen ontem 27 de maio de 2020 03:13 link Permalink

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

TRANG TRANG ontem 26 de maio de 2020 20:37 link Permalink

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

{{vm.hiddenReplies[35349] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
mramosch mramosch Criada em ontem, editada em ontem Criada em 26 de maio de 2020 21:31, editada em 26 de maio de 2020 21:34 link Permalink

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.

{{vm.hiddenReplies[35351] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG ontem 26 de maio de 2020 22:27 link Permalink

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

{{vm.hiddenReplies[35352] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
mramosch mramosch Criada em ontem, editada em ontem Criada em 27 de maio de 2020 00:49, editada em 27 de maio de 2020 00:58 link Permalink

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.

{{vm.hiddenReplies[35353] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG ontem 27 de maio de 2020 13:27 link Permalink

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

{{vm.hiddenReplies[35368] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
mramosch mramosch há 2 horas 28 de maio de 2020 10:59 link Permalink

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.

mramosch mramosch Criada em ontem, editada em ontem Criada em 27 de maio de 2020 11:26, editada em 27 de maio de 2020 11:28 link Permalink

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

{{vm.hiddenReplies[35357] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 23 horas 27 de maio de 2020 13:54 link Permalink

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.

{{vm.hiddenReplies[35371] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
mramosch mramosch há 23 horas 27 de maio de 2020 14:17 link Permalink

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

DostKaplan DostKaplan há 3 horas 28 de maio de 2020 09:52 link Permalink

Bug :-(

After entering and submitting a search string, on the results page that follows, the search string is missing in the search box.

TRANG TRANG há 22 dias 5 de maio de 2020 18:16 link Permalink

**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!

{{vm.hiddenReplies[35102] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
soliloquist soliloquist há 22 dias 5 de maio de 2020 19:57 link Permalink

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

{{vm.hiddenReplies[35105] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 22 dias 5 de maio de 2020 20:27 link Permalink

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.

{{vm.hiddenReplies[35108] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
soliloquist soliloquist há 22 dias 5 de maio de 2020 21:00 link Permalink

> 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

{{vm.hiddenReplies[35109] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 17 dias 10 de maio de 2020 20:23 link Permalink

> 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

{{vm.hiddenReplies[35142] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
AlanF_US AlanF_US há 16 dias 11 de maio de 2020 21:19 link Permalink

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.

{{vm.hiddenReplies[35152] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 16 dias 11 de maio de 2020 22:15 link Permalink

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

{{vm.hiddenReplies[35154] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
AlanF_US AlanF_US há 16 dias 12 de maio de 2020 12:16 link Permalink

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.

{{vm.hiddenReplies[35160] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 12 dias 15 de maio de 2020 23:05 link Permalink

I have created an issue for this:
https://github.com/Tatoeba/tatoeba2/issues/2326

TRANG TRANG há 13 horas 27 de maio de 2020 23:49 link Permalink

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?

{{vm.hiddenReplies[35374] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
AlanF_US AlanF_US há 12 horas 28 de maio de 2020 00:46 link Permalink

Yes, it looks good now. Thank you!

CK CK Criada em há 16 dias, editada em há 16 dias Criada em 12 de maio de 2020 01:22, editada em 12 de maio de 2020 03:46 link Permalink

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

{{vm.hiddenReplies[35156] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
CK CK Criada em há 10 dias, editada em há 10 dias Criada em 18 de maio de 2020 01:40, editada em 18 de maio de 2020 02:04 link Permalink

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.

{{vm.hiddenReplies[35214] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 13 horas 28 de maio de 2020 00:08 link Permalink

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

CK CK Criada em há 22 dias, editada em há 22 dias Criada em 5 de maio de 2020 20:01, editada em 5 de maio de 2020 20:02 link Permalink

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.

{{vm.hiddenReplies[35106] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 22 dias 5 de maio de 2020 20:17 link Permalink

What exactly blocks you from using the new design?

{{vm.hiddenReplies[35107] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
Aiji Aiji Criada em há 20 dias, editada em há 20 dias Criada em 8 de maio de 2020 09:58, editada em 8 de maio de 2020 10:08 link Permalink

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.

{{vm.hiddenReplies[35128] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 17 dias 10 de maio de 2020 20:16 link Permalink

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.

PaulP PaulP Criada em há 17 dias, editada em há 17 dias Criada em 11 de maio de 2020 11:55, editada em 11 de maio de 2020 11:59 link Permalink

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.

{{vm.hiddenReplies[35146] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
rumpelstilzchen rumpelstilzchen há 16 dias 11 de maio de 2020 16:28 link Permalink

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

{{vm.hiddenReplies[35147] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
PaulP PaulP há 16 dias 11 de maio de 2020 16:39 link Permalink

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.

{{vm.hiddenReplies[35148] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 16 dias 11 de maio de 2020 19:38 link Permalink

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

{{vm.hiddenReplies[35150] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
PaulP PaulP há 16 dias 12 de maio de 2020 05:53 link Permalink

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

AlanF_US AlanF_US há 16 dias 11 de maio de 2020 21:53 link Permalink

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.

{{vm.hiddenReplies[35153] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 11 dias 17 de maio de 2020 11:15 link Permalink

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

{{vm.hiddenReplies[35202] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
AlanF_US AlanF_US há 10 dias 17 de maio de 2020 14:36 link Permalink

Thanks!

CK CK Criada em há 11 horas, editada em há 10 horas Criada em 28 de maio de 2020 02:31, editada em 28 de maio de 2020 02:34 link Permalink

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

CK CK Criada em há 10 dias, editada em há 10 dias Criada em 18 de maio de 2020 02:01, editada em 18 de maio de 2020 02:10 link Permalink

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


{{vm.hiddenReplies[35216] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 9 dias 18 de maio de 2020 15:15 link Permalink

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

AlanF_US AlanF_US há 12 horas 28 de maio de 2020 00:55 link Permalink

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.

Aiji Aiji Criada em há 12 horas, editada em há 12 horas Criada em 28 de maio de 2020 01:13, editada em 28 de maio de 2020 01:14 link Permalink

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

mramosch mramosch Criada em ontem, editada em ontem Criada em 27 de maio de 2020 08:37, editada em 27 de maio de 2020 08:43 link Permalink

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

{{vm.hiddenReplies[35355] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
AlanF_US AlanF_US ontem 27 de maio de 2020 11:29 link Permalink

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.

{{vm.hiddenReplies[35358] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
mramosch mramosch Criada em ontem, editada em ontem Criada em 27 de maio de 2020 11:40, editada em 27 de maio de 2020 11:41 link Permalink

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

{{vm.hiddenReplies[35360] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
CK CK ontem 27 de maio de 2020 12:03 link Permalink

If you know how to do it, the easy way would be to download the exported files and do case-sensitive searches offline.

{{vm.hiddenReplies[35366] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
mramosch mramosch ontem 27 de maio de 2020 12:12 link Permalink

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

AlanF_US AlanF_US há 23 horas 27 de maio de 2020 13:42 link Permalink

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.

{{vm.hiddenReplies[35369] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
mramosch mramosch há 23 horas 27 de maio de 2020 14:09 link Permalink

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.

mramosch mramosch há 4 dias 24 de maio de 2020 11:12 link Permalink

Clicking a ‚linked‘ entry in the log of a sentence highlights the actual sentence in the list of translations. A very hidden feature but I‘m glad I found it ;-)

When unlinking a sentence the ‚linked’ entry still remains in the log and an additional ‚unlinked‘ entry appears in the list.

Having gotten used to the highlighting feature I really miss the same behavior for the ‚unlinked‘ log entries, provided the unlinked sentence is still in the list of translations as an indirect link, of course.

And even highlighting the indirect link when pressing an outdated ‚linked‘ entry would be useful for my workflow.

Needless to mention that
-> clicking on a sentence in the translation list causing the highlighting of all relevant entries in the log - or at least the last relevant ‚linked‘ respectively ‚unlinked‘ log

would be excellent, provided the UI and automatic scrolling allows for that feature.

{{vm.hiddenReplies[35318] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
AlanF_US AlanF_US há 23 horas 27 de maio de 2020 13:50 link Permalink

Have you considered getting an account on GitHub and joining the Tatoeba/tatoeba2 project there? Then you could post your enhancement requests as issues. That would be the best place, since you could carry on an extended discussion there without worrying about monopolizing the Wall, or having your suggestions get lost without being considered. You'd also be able to communicate with developers more easily there. Try this link:

https://github.com/Tatoeba/tatoeba2

which can also be found at the bottom of any Tatoeba page.

mramosch mramosch Criada em ontem, editada em ontem Criada em 27 de maio de 2020 10:38, editada em 27 de maio de 2020 10:39 link Permalink

Every now and then I see comments regarding some audio problems and people pinging @CK to help out, but at the same time I am told that CK has deactivated all notifications to his account and won’t see them.

Is there any official user/pseudo-user account like @audio where audio issues can be directed to without getting lost in oblivion?

{{vm.hiddenReplies[35356] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
AlanF_US AlanF_US ontem 27 de maio de 2020 11:37 link Permalink

You can send him a private message. While you're at it, you can ask him to turn on e-mail notifications so this kind of thing doesn't happen in the future. It wouldn't be the first time he's gotten that request.

No, there is no account called "audio". If there were, CK would still have to check it, since he's the one who deals with issues that need to be resolved by working with the audio. (Other admins can resolve issues that pertain to text.)

Seeing that you are an advanced contributor and can leave a tag, it's a good idea to leave a tag like "@change", since sentences with this tag are reviewed frequently.

{{vm.hiddenReplies[35359] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
mramosch mramosch Criada em ontem, editada em ontem Criada em 27 de maio de 2020 11:56, editada em 27 de maio de 2020 11:58 link Permalink

I am only involved in some comment-discussions because of the small amount of contributions I have delivered yet and am already drowning in e-mail notifications.

I can imagine what it means to be in CK‘s shoes, so I won‘t bother him on this one. I do it often enough for other issues... ;-)

I‘m just hinting that at least official administrative tasks should have a maintainer with some functioning channel of communication. I guess that’s what commenters are expecting from a comment section by default instead of having (for every request) to look up names of responsible persons, because they might change along the way,

CK CK Criada em ontem, editada em ontem Criada em 27 de maio de 2020 11:41, editada em 27 de maio de 2020 11:41 link Permalink

You can tag the sentence with "@change audio" and leave a comment explaining exactly what needs to be done.

If these don't get fixed in a reasonable amount of time, send me a private message.

There are a number of items tagged @change audio that are hard to deal with, since there are no clear explanations about what needs to be done.

{{vm.hiddenReplies[35361] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
mramosch mramosch ontem 27 de maio de 2020 11:42 link Permalink

But is everybody eligible for using tags?

{{vm.hiddenReplies[35362] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
CK CK ontem 27 de maio de 2020 11:56 link Permalink

No, but every logged in member can leave a comment asking for someone to tag a sentence.

{{vm.hiddenReplies[35363] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
mramosch mramosch Criada em ontem, editada em ontem Criada em 27 de maio de 2020 12:00, editada em 27 de maio de 2020 12:07 link Permalink

Well, if that’s not redundant and complicated then what...? ;-)

Yesterday I filed about 15 requests after listening and digging through 1000 of entries in an audio list, I don‘t wanna do these redundant steps of asking anybody else to ask some friend of a friend of a friend - over and over again...

sharptoothed sharptoothed há 3 dias 24 de maio de 2020 19:50 link Permalink

** Stats & Graphs **

Tatoeba Stats, Graphs & Charts have been updated:
https://tatoeba.j-langtools.com/allstats/

{{vm.hiddenReplies[35329] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
Ricardo14 Ricardo14 há 2 dias 25 de maio de 2020 21:12 link Permalink

Thank you :D

Guybrush88 Guybrush88 há 2 dias 26 de maio de 2020 07:15 link Permalink

thanks

deniko deniko há 7 dias 21 de maio de 2020 13:14 link Permalink

Not sure whether it has been discussed before - sorry if it has - but it looks like if you're using the new interface you can only change the flag to a language that is listed in your profile. As a corpus maintainer I change the flag to something that is not listed there, and I do it quite often - obviously, confirming which one it should be, if I'm unsure. Is it possible to list all the languages in the drop down menu, similar to the old interface? I guess it's a useful feature for everyone, not just for corpus maintainers.

{{vm.hiddenReplies[35261] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 6 dias 21 de maio de 2020 14:10 link Permalink

It has not been discussed here on the Wall but I had sent some time ago a message to the corpus maintainers group in Gitter. I don't think a lot of people received it though because no one answered.

It has been originally mentioned by Aiji and CK in GitHub:
https://github.com/Tatoeba/tatoeba2/pull/2077

My questions would be:
- Is there a reason why you don't want to list the languages in your profile?
- Can you describe the usual situations where you'll change the language?
- How often exactly does it happen?

{{vm.hiddenReplies[35264] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
deniko deniko Criada em há 6 dias, editada em há 6 dias Criada em 21 de maio de 2020 14:18, editada em 21 de maio de 2020 14:19 link Permalink

> Is there a reason why you don't want to list the languages in your profile?

For example, because I don't speak them?


> Can you describe the usual situations where you'll change the language?

For example:

#8724171

I asked the user to change the flag. if they don't change it in 6 more days (2 weeks after I noticed it's wrong), I'll confirm with Lisa or someone else it's Japanese (which is my guess) and change it to Japanese.

> How often exactly does it happen?

Not too often, but I guess at least 1-2 times a month.

{{vm.hiddenReplies[35266] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 6 dias 21 de maio de 2020 14:51 link Permalink

> For example, because I don't speak them?

In this case, it would be better to let someone who speaks the language handle the change, wouldn't it?

On your side, when you can identify that a sentence has the wrong language, but you're not sure what is the correct language, you can change ASAP the language "Other language" so that it doesn't pollute the corpus for the languages that you speak.

Then you can leave a comment, where you can even ping directly some corpus maintainers: "This sentence was wrongly flagged as Ukrainian. I think it's Japanese. @small_snow @bunbuku @Pfirsichbaeumchen"

Then one of them will change it when seeing your comment if it is indeed Japanese.

{{vm.hiddenReplies[35267] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
deniko deniko há 6 dias 21 de maio de 2020 14:56 link Permalink

> In this case, it would be better to let someone who speaks the language handle the change, wouldn't it?

I don't believe so. If the task is as simple as changing the flag, I can ask a speaker of this language to confirm the flag. If the speaker is a corpus maintainer or an admin they can fix that themselves, sure, once I bring it to their attention, but if they're not? It's not like I edit those sentences or something.

So what if it's say Slovak? I don't speak it, I can make a reasonable guess it is Slovak, I know who to confirm it with, but I don't know any corpus maintainer/admin who has it listed to ask them to change the flag.

{{vm.hiddenReplies[35268] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 6 dias 21 de maio de 2020 17:02 link Permalink

> It's not like I edit those sentences or something.

But I'd argue that changing the language of a sentence can be just as important as editing the sentence itself.

> So what if it's say Slovak? I don't speak it, I can make a reasonable guess
> it is Slovak, I know who to confirm it with, but I don't know any corpus
> maintainer/admin who has it listed to ask them to change the flag.

In that case would there be any issue for you to just add Slovak to your list of languages?

{{vm.hiddenReplies[35269] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
deniko deniko há 6 dias 21 de maio de 2020 17:11 link Permalink

> But I'd argue that changing the language of a sentence can be just as important as editing the sentence itself.

Well, it's all up to you. I find it very safe to do so. I can do it anyway by adding Japanese to the list of my languages although I don't understand it at all, so I still don't see the point of making the task more complicated than it is now.

> In that case would there be any issue for you to just add Slovak to your list of languages?

Well, I'd have to list all Slavic and Romance languages there in this case... And some Germanic just because they're relatively easy to understand in their written form through the languages I already know.

I just don't want to make the list too long. I enjoy having a relatively short list of languages I'm interested in because this list is used in some places to facilitate search, etc. Besides, some features were discussed about using this list to prioritize sentences in those languages when you see translations, that would be a sweet feature, but I don't want to prioritize languages that I'm not truly interested.

{{vm.hiddenReplies[35270] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 6 dias 21 de maio de 2020 21:28 link Permalink

> I can do it anyway by adding Japanese to the list of my languages although
> I don't understand it at all, so I still don't see the point of making the task
> more complicated than it is now.

Because by principle, you shouldn't be changing the language of a sentence to Japanese if you don't know Japanese and there is someone else who knows better than you and can perform this change instead of you.

The fact that you can do it anyway is not an intended feature. It is because we don't care much that you can do it anyway, but ideally, we'd rather you don't do it.

> Well, I'd have to list all Slavic and Romance languages there in this case...

No, not necessarily all of them. You would only have to do this for languages that are lacking corpus maintainers and that you are willing to get involved in.

{{vm.hiddenReplies[35277] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
deniko deniko há 6 dias 22 de maio de 2020 08:03 link Permalink

Thanks for the explanation Trang.

gillux gillux há 5 dias 22 de maio de 2020 15:48 link Permalink

What if the sentence is written in a language that has no corpus maintainer?

{{vm.hiddenReplies[35291] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 5 dias 22 de maio de 2020 16:17 link Permalink

The language can always be changed to "Other language" until someone can confidently assign the correct language.

{{vm.hiddenReplies[35292] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
gillux gillux Criada em há 5 dias, editada em há 5 dias Criada em 22 de maio de 2020 16:53, editada em 22 de maio de 2020 16:53 link Permalink

In that case, who would be that "someone"? Only corpus maintainers can change someone else’s sentence flag.

{{vm.hiddenReplies[35293] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 5 dias 22 de maio de 2020 18:00 link Permalink

That someone will be a corpus maintainer most of the time, yes.

But that someone can be an advanced contributor if the owner of the sentence is inactive. Advanced contributors can adopt the sentence and change the language upon becoming the new owner. This case is probably very rare though.

That someone could also be a regular contributor. If the owner of the sentence is inactive and the sentence is adopted by an advanced contributor who then decides to unadopt. This case is probably even more rare.

The most likely situation is that we find a corpus maintainer who has some knowledge in the language or who has taken the time to learn about the language and who is willing to take care of the language.

Among existing corpus maintainers, this would be typically someone like cueyayotl or Ricardo or shekitten who tend to have a broader interest in languages and could be temporary ambassadors for a language that doesn't have yet a native speaker as corpus maintainer.

Otherwise, there could be an advanced contributor who decides to step up and become corpus maintainer in order to take care of that language, seeing that it wasn't getting much love.

{{vm.hiddenReplies[35295] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
gillux gillux há 5 dias 22 de maio de 2020 21:43 link Permalink

I get your point, but I have to disagree. The principle of restricting flag changes only to corpus maintainers having the proper profile language makes sense in theory. But now you are facing 3 corpus maintainers (so far) asking for full flag selection. So maybe that is not so practical after all.

I assume that most (if not all) sentences in need of flag correction are the result of a user mistake (or bad UI) when adding the sentence. In this context, aren’t most flag corrections more about understanding how the mistake happened, what was the original intention of that particular member, rather than knowledge in a particular language?

In your point of view, it looks like the knowledge of a language is the only way one can accurately change someone else’s sentence flag. I disagree. I’d trust any corpus maintainer to change any sentence flag because they are all responsible and trustworthy. I know they will make the necessary research, ask the right person and make the correct decision, because that’s exactly what they are here for. Denying them this ability feels almost like you don’t really trust them after all. I wouldn’t be very happy about that if I were a corpus maintainer.

{{vm.hiddenReplies[35300] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
mramosch mramosch Criada em há 5 dias, editada em há 5 dias Criada em 22 de maio de 2020 22:28, editada em 22 de maio de 2020 22:30 link Permalink

I think, I was the reason that this discussion started because out of ignorance I caused the flag problem that had to be fixed manually by Denis.

I tried to direct-link a sentence by creating an already existing sentence (that only had an indirect link) for a second time in order to change the link from being indirect to being direct. I was told this is the best way of doing it if you don’t have AC permission to do linking with the official linker tool.

Because I recently removed my language information from my profile I only got the options ‚English‘ or ‚Other language‘ when trying to submit the new sentence.

I chose ‚Other language‘ because I was told that the bot would automatically detect and correct everything to eventually be left with one correct version and a direct link.

But all I achieved was the appearance of a flag with a question mark that was stuck and couldn’t be changed anymore.

Maybe this is a bug in the UI or a use case that the UI is not prepared for?

{{vm.hiddenReplies[35303] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
CK CK Criada em há 5 dias, editada em há 5 dias Criada em 23 de maio de 2020 01:04, editada em 23 de maio de 2020 01:06 link Permalink

We have a duplicate-merging script that will merge exact matches together. If the language code (flag) is different, then the 2 sentences won't be merged because they are not an exact match.

CK CK Criada em há 5 dias, editada em há 5 dias Criada em 23 de maio de 2020 01:09, editada em 23 de maio de 2020 01:09 link Permalink

> In your point of view, it looks like the knowledge of a language is the only way one can accurately change someone else’s sentence flag. I disagree. I’d trust any corpus maintainer to change any sentence flag because they are all responsible and trustworthy.

I agree with Gillux.

If there are corpus maintainers that you feel are not responsible and trustworthy then they should be changed back to advanced contributors.

TRANG TRANG há 4 dias 24 de maio de 2020 10:51 link Permalink

I trust corpus maintainers for doing everything with their best intention but I don't think it's reasonable to expect every one of them to be equally competent for every task that corpus maintainers can perform.

For me this is about separation of responsibilities and about transparency. This is about how do we organize ourselves in the best possible way and how to make the features of Tatoeba reflect better this organization.

I know that in many cases it is possible for a corpus maintainer who has no tangible knowledge in a certain language to fix an error in sentence in that language. This includes: setting the correct flag, fixing the punctuation and even fixing very basic mistakes. But in my opinion, if you have the chance to involve another corpus maintainer who has more experience with the language than you have, this should be your default course of action (even if what you need to fix feels obvious to you). And if that is your default course of action, then you don't really need the full list of languages by default.

It doesn't mean you are completely forbidden from making interventions in other languages. If there's a special situation, you can always add the language to your profile at any time, with a low level or unspecified level. Since these situations are supposed to be exceptions, the fact that you have to take these extra steps shouldn't be too much to ask.

I can understand that it's not practical because you may end up with unwanted languages showing up in the dropdown list when adding/translating sentences. But then it's a different problem.

Besides, if you're dealing with a language which seemingly has no corpus maintainer and, as a result, you get in touch with native speakers or/and do some research on the language, then it would be helpful for the community to know it from your profile. The next time there's maintenance to do on other sentences in that language, people could reach out to you and benefit from your past experience instead of asking assistance from a random corpus maintainer.

{{vm.hiddenReplies[35317] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
AlanF_US AlanF_US Criada em há 3 dias, editada em há 3 dias Criada em 24 de maio de 2020 17:53, editada em 24 de maio de 2020 17:54 link Permalink

To me, identifying the language of a sentence belongs to a different category from modifying or deleting the sentence. In order to modify or delete a sentence, you need to know the language pretty well, and once you make the modification or deletion, it can become difficult or impossible to revert the change. But it requires a good deal less familiarity with a language to identify a sentence in it (or a sentence that does NOT belong to it), and in any case, an incorrect language identification is easy to switch later.

With the new UI design, changing language identification is grouped together with other operations on the sentence, so I can see why it might be tempting to require corpus maintainer privileges for all of them. But I don't think that logically or practically they fit into the same category.

{{vm.hiddenReplies[35327] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 3 dias 24 de maio de 2020 21:04 link Permalink

I agree with what you said but the question still remains.

With the new design, a corpus maintainer now only sees the languages in their profile when editing the language of a sentence.

Should we bring back the full list of languages (as it used to be in the old design) or can we keep it restricted to the profile languages?

{{vm.hiddenReplies[35332] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
AlanF_US AlanF_US há 3 dias 24 de maio de 2020 23:39 link Permalink

Sorry, I missed that question. I vote for showing the full list of languages.

{{vm.hiddenReplies[35334] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
Ricardo14 Ricardo14 há 3 dias 25 de maio de 2020 05:16 link Permalink

+1

brauchinet brauchinet há 4 dias 24 de maio de 2020 12:01 link Permalink

This doesn't really belong here - a situation that I often witnessed:
Somebody writes a comment such as "Flag", "Change flag", "Not French!", "French!".
A corpus maintainer comes by and changes the flag.
The owner of the sentence reads the comment and goes "Huh? What?"

A possible solution would be to keep a log for changing flags. Don't know if it's worth it.

{{vm.hiddenReplies[35321] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
Pandaa Pandaa há 4 dias 24 de maio de 2020 13:27 link Permalink

+1

TRANG TRANG há 3 dias 24 de maio de 2020 21:07 link Permalink

> A possible solution would be to keep a log for changing flags.
> Don't know if it's worth it.

We have an old ticket for this already :)
https://github.com/Tatoeba/tatoeba2/issues/533

And yes, I think it would be worth it.

Aiji Aiji há 5 dias 23 de maio de 2020 10:39 link Permalink

> But I'd argue that changing the language of a sentence can be just as important as editing the sentence itself.

> The fact that you can do it anyway is not an intended feature. It is because we don't care much that you can do it anyway, but ideally, we'd rather you don't do it.

What about linking sentences, where there are two languages involved?

Whatever the official guidelines become, in any case, please don't make the maintenance work a complicated ball of unnecessary bureaucracy. Right now, a non-negligible part of corpus maintenance rests on mutual help, both for detecting and correcting potential mistakes. And we sometimes need to trust each others judgment, even (in particular) in languages we aren't fully capable.

A simple, illustrative more than completely exact, example : There is a sentence in Hebrew that I suspect don't correspond to French. I will ask Alan about it. I will ask him to help me confirm the meaning of the sentence in English because that's our best common language. I'm sure that he will not mistake his explanation due to a lack of ability and confident that I will not mistake mine. If Alan can't help me, he may ask somebody else to help, maybe even in Hebrew instead of English, if that's there best common language. At the end, if my suspicion is confirmed, I will unlink the Hebrew from the French, although I don't speak a bit of Hebrew. There might have been a piece of information lost in translation but I trust that my fellow maintainers and I, at the best of our combined ability, did the good choice.

(The fact that Alan understands French somehow goes against my example, but I hope you get the idea I wanted to express).

{{vm.hiddenReplies[35310] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
mramosch mramosch há 5 dias 23 de maio de 2020 11:31 link Permalink

It just looks to me like the half-empty vs. half-full syndrome or in other words

• It is incorrect as long as it is not proven to be correct
vs.
• It is correct as long as it is not proven to be incorrect

and by ‘proven’ I mean something along the lines of e.g. ‘confirmed by a native speaker’ etc.

Perhaps the guidelines on Tatoeba should be a little more clear of which approach is preferable as modus operandi when doing clean up work. I don’t wanna have some other AC or CM constantly having to clean up the mess after me just because I assumed that I have to make my own guidelines because of missing official policies.

It seems that in my first day of linking sentences I have already stepped in some dodo and although having read all those endless threads of near-duplicates, indirect vs. direct links etc. I never really found some conclusion that sounded like a recommendation, even if just a temporary one.

Aiji’s example is a good illustration of the issue, even with only having to deal with languages that are relatively high in the food chain. But imagine less prominent languages, where there is almost no way of gaining traction without relying on second hand guesswork via already existing translations into better distributed languages.

So, is there a general recommendation for the “permissive/prohibitive goes first” problem or does every use case have to be considered carefully in its own domain?

{{vm.hiddenReplies[35311] ? 'expand_more' : 'expand_less'}} ocultar respostas mostrar respostas
TRANG TRANG há 4 dias 24 de maio de 2020 11:26 link Permalink

> So, is there a general recommendation for the “permissive/prohibitive
> goes first” problem or does every use case have to be considered
> carefully in its own domain?

I think every use case should be considered carefully. When in doubt, just ask on the Wall.

TRANG TRANG há 4 dias 24 de maio de 2020 11:12 link Permalink

> What about linking sentences, where there are two languages involved?

When there are two languages involved, you obviously don't have to have both languages in your profile. But you should know one of them.

If you don't know Arabic and don't know Kabyle, you shouldn't be linking Arabic and Kabyle sentences.

> Whatever the official guidelines become, in any case, please don't
> make the maintenance work a complicated ball of unnecessary
> bureaucracy.

There's no guidelines being changed here. The guideline of not making interventions in languages that you have no clue about is not a new thing, is it?