kleros/linguo

Linguo user interface.

Kleros

Kleros core smart contracts.

Get Started

1. Clone this repo.
2. Run yarn to install dependencies and then yarn run build to compile the contracts.

Scripts

• yarn run prettify - Apply prettier to the entire project.
• yarn run lint:sol - Lint the entire project's .sol files.
• yarn run lint:js - Lint the entire project's .js files.
• yarn run lint:sol --fix - Fix fixable linting errors in .sol files.
• yarn run lint:js --fix - Fix fixable linting errors in .js files.
• yarn run lint - Lint the entire project's .sol and .js files.
• yarn test - Run the truffle tests.
• yarn run cz - Run commitizen.
• yarn run build - Compile contracts.

Contributing

See CONTRIBUTING.md.

Learn how to develop arbitrable and arbitrator contracts here.

linguo's Issues

Create Evidence Display Interface.

Create Evidence Display Interface specific for Linguo.

Create social media profiles for Linguo.

• Create twitter account

Crash after creating task

Steps that caused the issue:
1- I created a translation request from english to portuguese.
2- Navigated to "Work as a translator" (https://linguo-beta.netlify.app/translator?filter=inReview&secondLevelFilter=toReview)
3- Crash.

At this point opening a new tab and navigating to https://linguo-beta.netlify.app/translator?filter=inReview&secondLevelFilter=toReview crashes.

Cannot disable the "now" button for deadline input in translation request form

Context

When creating a translation request, the user must set a deadline for the translation.
The Linguo smart contract enforces that the deadline must be in the future, otherwise a translator wouldn't have the opportunity to work on it.

Currently we are using Ant Design DatePicker component for that:

//...
function isTodayOrBefore(current) {
  return current && dayjs(current) < dayjs().endOf('day');
}
// ...
<DatePicker
  size="large"
  placeholder="Deadline"
  disabledDate={isTodayOrBefore}
  showToday={false}
  showTime={{
    defaultValue: dayjs('00:00:00', 'HH:mm:ss'),
    showNow: false,
    use12Hours: false,
  }}
  format="DD MMMM YYYY HH:mm:ss [(Local time)]"
/>

This will enforce that the deadline will be at least the beginning of next day.

The Problem

Currently the component is rendered like this:

Notice that while the day that represents the current date in the calendar (circled in red) is disabled, however, the Now button is enabled and if clicked will populate the input, even though the current date falls into the range of disabledDate.

This is related to ant-design issue #21159.

Workaround

Currently I added a custom validation rule to the respective Form.Item, enforcing that if the user selects an invalid date, (s)he won't be able to submit the form.

Wording "Bounty", not "deposit"

Set a limit for the size of translation tasks

For the cryptoeconomic models created by @whwgeorge to work properly as the smart contract is implemented today, it's important that tasks can't vary too much in difficulty, so we will set a hard limit for the amount of words in a translation task.

notification mails not received

Whenever a translation gets approved and the payment is sent, although in the UI the notification is shown, the email notification is not sent.
I don't know if this problem is extensive to the other notifications.
I've checked this issue with another translator and he is experiencing the same issue.

Migrate to TheGraph network

Affected code:

linguo/src/app/MainRouter.jsx

Line 47 in 92f7d6f

value={{ fetcher: fetcherBuilder(`https://api.thegraph.com/subgraphs/name/${SUBGRAPH_NAMES[chainId]}`) }}

Update the environment variable on Netlify

Resolves kleros/builder-baseline#22

Unable to upload evidence in `Evidences` section

Do not show an error message if the user doesn't sign.

A user not signing is not an error, it's most of the time a user wanting to see what this would do (which contract, which function, which gas cost, etc)
If the tx isn't signed, we shouldn't do anything.

UI does not refresh or redirect when submitting a translation request

In the requester flow, the webpage doesn't refresh or lead back to the Requester Dashboard after submitting a new task.

Error to access documents: Failed after many retries

Original @web3-react/fortmatic-connector does not work properly with Linguo

Context

@kleros is improving the way we onboard users.

Instead of simply throwing a Metamask popup on the user's face as soon as (s)he visits our dapps, we will eventually move to an opt-in approach: the users will be asked for a wallet only when needed. Furthermore, the (s)he will also be able to choose a wallet provider.

Right now, beyond Metamask, we are trying to add support to Fortmatic.

To make things easier, we decided use web3-react, because of its concept of connectors, which allow for easily switching different wallet providers, and the fact that it already has built-in connectorn for both Metamask (what they call InjectedConnector) and Fortmatic.

The Problem

As this project is setup today, @web3-react/fortmatic-connector is broken. It fails to properly import the fortmatic module which it depends upon.

The issue seems to happen here:

const { default: Fortmatic } = await import('fortmatic')

What they expect is the fortmatic package to export an ES module, but I checked the tarball of [email protected] and it exposes only a CJS module.

Apparently, when dynamic importing a CJS module with the current Linguo setup ([email protected] + [email protected]), instead of wrapping it into an ES module that would look like export default module.exports, it simply imports the CJS module as is.

Current Workaround

The solution for the FortmaticConnector was not to use the provided @web3-react/fortmatic-connector, instead, roll my own. In fact, it's basically a CTRL+C/CTRL+V of the original package code, the only difference was the way the import to fortmatic is made.

// ...
-const { default: Fortmatic } = await import('fortmatic');
+const Fortmatic = await import('fortmatic');
// ...

Actually, to support both cases, I have:

let Fortmatic = await import('fortmatic');
Fortmatic = Fortmatic.default || Fortmatic;

Reproducing The Problem

1. Clone this repo: git clone https://github.com/kleros/linguo.git

2. Install dependencies: yarn install

3. Go to connectors.js file.

4. Change the import of FortmaticConnector:

   @@ -1,5 +1,5 @@
    import { InjectedConnector } from '@web3-react/injected-connector';
    import { NetworkConnector } from '@web3-react/network-connector';
   -import { FortmaticConnector } from '~/adapters/web3-react/FortmaticConnector';
   +import { FortmaticConnector } from '@web3-react/fortmatic-connector';
    

5. Run the development server: yarn start;

6. Go to http://localhost:1234

7. Look for the "gear" button to access the app settings, then click in "connect to wallet":

   

8. In the modal that will open, choose Fortmatic:
   

9. You will probably see the following error in the console:

   TypeError: "Fortmatic is not a constructor"
       _temp4 index.ts:34
   web3React.js:17:12
       getErrorMessage web3React.js:17
       WalletConnectionModal WalletConnectionModal.jsx:87
       React 8
       unstable_runWithPriority scheduler.development.js:653
       React 5
       createHandleActivation WalletConnectionModal.jsx:56
   

---

IMPORTANT: I can't reproduce the problem outside the Linguo repo:

• I tried to reproduce that using a codesandbox, but here the original package does work.
• I tried to setup a new local repo with some of the configurations for Linguo (babel, parcel, etc.), but in this case I get only a blank screen, with no error.

Hypotheses

This seems like a problem of CJS/ES modules interoperability. I can think of some reasons:

• A bug within parcel dynamic module importing.
  • Maybe something related to our .browserslistrc.
• A problem with our .babelrc, which is causing the code to not be properly transpiled.
• A bug in babel itself.

General Observations

• I did tried to clean parcel cache and start the dev server again. The results were the same.

Things I observed in the Linguo repo:

• Dynamic importing ES modules that are in the project, but outside node_modules works as expected.
• Dynamic importing CJS modules that are in the project, but outside node_modules works as as described here: the CJS module is not wrapped into an ES module; the promise returned by import() is resolved with the value of module.exports.
  • I'm not sure this is the expected behavior.

UI Does Not Show Info for Time to Complete a Translation

It shows a deadline, which is the last time someone can take a task, but it does not show how much time the translator will have to complete the task.

Upload file with Chinese character in the name

Internal server error.

Integrate 3box.io chat to task details

Link to relevant docs: https://docs.3box.io/api/messaging.

Error to access documents: Failed after many retries

It does allow to open tasks. Error message appears "Failed after many retries"

Deadline Approximation is Not Precise Enough

Change colors of decision outcome box

We could use a different color on the title: (Final Decision...) as well as the 1px outline box.
in case it’s a positive decision we could use #00C42B; in case of a rejection we could use #F60C36

Define parameters for contract deployment.

For Linguo we need to define:

• reviewTimeout
• translatorMultiplier (assignment)
• challengerMultiplier (challenge)
• sharedStakeMultiplier (dispute)
• winnerStakeMultiplier (dispute)
• loserStakeMultiplier (dispute)

Publish contracts on mainnet

• Publish Linguo contracts on mainnet for each supported pair of languages.

Real Time Price Updates for Tasks

This would be interesting for users watching price go up every second.

Case #545 - Prevent User From Uploading Original Text as Translation

https://linguo.kleros.io/translation/0xa3E4348BDDc32AfcedC5e088e0E21FD6154A0180/2

The user mistakenly uploaded the original text file as the translation file. We can prevent this by comparing ipfs hashes of the original text and translated text and warn the user if matches.

Do not ask to sign up to 3D box unless it's required for a particular action

ZIp file is not being accepted in `Submit New Evidence` modal from Windows

Seems like it is due to the fact that Windows uses a different MIME type for zip files.

Updating whitelist for zip:

"application/x-zip",
"application/x-zip-compressed", 
"multipart/x-zip"
...

Improve messages displayed to translators when setting skills

Currently it is a bit confusing to users to understand that they need a certain level in at least 2 different languages to be able to see tasks as a translator.

• Display the alert on Translator Dashboard for Open tasks even if the list is empty (this should probably be the behavior for all filters)
• Warn the user if they try to save the translator skills with only one language declared.

Remove limit on minimum price

A minimum price of 0 is perfectly acceptable and even a common way to start reverse Dutch auctions.

Create bot to automate task lifecycle.

• Automatically mark expired tasks which were not assigned to a translator as Resolved
• Automatically accept translations whose challenge period is over.
• Automatically withdraw fees and rewards for crowdfunders in the event of a dispute being settled.

Create Twitter bot

Create a Twitter bot to provide a livestream of events happening on Linguo.

Create a FAQ page

Some mapped potential questions users might have:

• Q: How does Linguo evaluate translators skills?
  A: Short answer: we do not. Translator skills are self-declared.
• Q: If there is no evaluation process, how can I be sure the translator is qualified enough for the job?
  A: Linguo uses cryptoeconomic incentives. Translators are required to provide a deposit when they assign to a task. After the translated text is submitted, there will be a period for review. During this time, anyone (including yourself) could look for potential flaws in the translation and raise a challenge. Then a case will be created in a specialized Kleros court which will judge whether or not the translation fulfills the requirement. If the challenger wins the case, the translator will lose the initial deposit, which will be sent to the challenger as a reward for his work. This way we incentivize that translators will only assign to tasks they think they are qualified enough to translate, otherwise they will incur in financial losses.
• Q: Why does Linguo only support translations from and to English?
  A: Currently it is too hard to find specialized jurors to evaluate a translation between an arbitrary pair of languages (e.g.: Korean <-> Russian). For that reason, we use English as the "pivot" language, so there can be enough jurors.
• Q: I need a translation between two languages other than English. What do I do then?
  A: Let's say you want a translation Korean -> Russian. You should first create a translation task for Korean -> English. Then, this intermediate translation is delivered, you can create another one for English -> Russian.
• Q: Why do I need to set a minimum and a maximum price?
  A: From the moment you create the translation task to the moment some translator assigns to it, the price will increase linearly. The higher the payout, the more working in your task looks interesting to translators. At some point they might decide that the task deserves their time. This will help you discover the right prices for your tasks.
• Q: What happens to my deposit if a translator assigns to the task before it reaches the maximum price?
  A: In the exact moment a translator assigns to the task, the remaining of your deposit, that is, the maximum price minus the current price, is sent right back to your wallet. This is done automatically, you do not need to do anything.
• Q: Is there a limit in the size of translations tasks I can request?
  A: While there is no hard limit, when a task is too long, reviewers will probably try to optimize their work and evaluate only some samples of the whole text. If there is a flaw in some excerpt of a long text, a challenge might not be raised because the reviewer overlooked it. Most of the time you should expect that reviewers will be efficient enough to find issues (as they profit if they do), however if the translation is critical, you should also take extra care and review it yourself.
• Q: Should I break large translation tasks into several smaller ones?
  A: You can definitely do that, however there is no guarantee that all individual tasks will be assigned to the same translator, as anyone with the required skills could assign to them at any time.

Show translation challengers the potential payout for the task if they win the case

As @whwgeorge pointed out on Slack:

Regardless, in the box on the Review Translations page, where it says "During review you can challenge the translation if you think it does not fulfill the quality requirements. To do so, you need to send a challenge deposit. If the jurors decide to not approve the translation you receive your challenge deposit back + the deposit of the translator (minus arbitration fees). If the translation is approved by the jurors your challenge deposit goes to the translator.", it would probably be helpful to give potential challengers more information about how much they can win if successful.

Add prices in USD for tasks

We should display the aprox. value in USD for any currency-related values in Linguo.

Automatically prefill the number of words for common text formats

Automatically count the number of words in the document and prefill it (while still allowing it to be overwritten) for common formats (.txt, .md. json, etc).

Allow challenger to provide a corrected version of the translation

As suggested by @fnanni-0 here:

I think it would be great if the challenger could submit a translation with the corrections and claim the task price too. If the challenger wins, not only the translator is punished and the challenger is rewarded, but the requester gets the translation he requested instead of losing time and money.

This could improve requester's UX and potentially increase the payout of challengers.

Currently challengers can profit by finding a single issue with the translation which would make it non-compliant with the required quality tier. One can optimize this task by scanning for common sources of mistakes, for example.

With this change, if the challenger decides to put some additional effort into the task to provide a fully compliant translation, beyond getting the requester deposit, he would also be rewarded with the escrow payment from the requester.

The requester benefits because she would get the translation done. Currently she gets refunded of her initial escrow deposit, but will spend both money with gas and time waiting for the task. If she has a deadline, this might be a deal-breaker.

Some challenges remain on how to actually implement this:

• Should we extend the current flow to allow the challenger to become the translator?
  • How much complexity would that bring to the smart contract?
  • Should we allow this process to be recurrent (a 4th party to challenge the original challenger's corrected translation)?
    • How to prevent and endless cycle of challenging that would keep the requester's escrow deposit locked in the contract for a long period of time?
• Should we change the dispute ruling options to be non-binary and give jurors the ability to choose to accept the challenger's translation instead of the original translator's? (Suggestion made by @fnanni-0)

Add pagination to Translator Dashboard

Currently, the TaskPage query has a hardcoded number of tasks set to 300.
To improve the user experience, pagination needs to be implemented at the TaskListFetcher component level.

Do not show a pop under about word count

It's annoying users and inspire distrust.

Default RPC endpoint for XDAI is outdated

Guys, since Linguo is not being maintained in a while, it seems like a couple of thinks have broken.

The most important thing is that after being acquired by Gnosis, xDAI Chain was rebranded into Gnosis Chain. The old endpoints worked for a while, but they have been disabled.

Someone with access to the Netlify account making the Linguo builds need to update the JSON_RPC_URLS variable with the information from this page.

Please not that JSON_RPC_URLS is a JSON-stringified version of something like this:

{
  1: 'https://mainnet.infura.io/v3/<INFURA_KEY>',
  100: 'https://rpc.xdaichain.com/',
  // ...
}

Just replace the https://rpc.xdaichain.com/ with https://rpc.gnosischain.com/ and the issue of tasks not being loaded by default will be fixed.

Payment with KPNK throws

After unlocking permanently PNK, I am unable to request the payment:

My address with KPNK: 0xdC8C1a8CB38F27C188a43CE0eBBC8e42e393D0d3

I went ahead and created it with ETH without problems: https://linguo-beta.netlify.app/translation/0x0825f16598AcB518851f8959b8267EF296c57f81/30

When navigating to Linguo from Court the translation never loads

Using the >> Go to the Arbitrable Application from Court the Linguo interface fails to load the translation with the error in the console:

src.7607e5c4.js:1 Uncaught (in promise) Error: Linguo API not properly initialized

I tested on multiple browsers and with accounts that have done Linguo onboarding and those that haven't and it errors with all.

Replace Sokol by Chiado as Gnosis Chain testnet

Linguo still using Sokol as Gnosis Chain testnet, however the offical post-merge testnet is Chiado.

Linguo contracts need to be deployed on Chiado and all references to Sokol must be relpaced in the dapp.

Prices in mxDai

This is not a well-known unit, thus confusing. Let's go with 0.001 xDai instead.

Subgraph Integration

This issue is related to integrating a subgraph and refactoring the API data layer

• Integrate Subgraph
• Refactor API data layer
• Fetch & display details
  • All tasks
  • Single task
  • Evidences
  • Disputes
  • Appeals
• Deploy contracts and subgraph to Goerli network
• Implement contract interaction handlers
  • createTask
  • assignTask
  • submitTranslation
  • acceptTranslation
  • challengeTranslation
  • reimburseRequester
  • submitEvidence
  • fundAppeal
  • batchRoundWithdraw
• Refactor translator skills setting
• Refactor task filters

Evidence is not currently being submitted as "evidence.json"

I submitted evidence before and the _evidence field of the Evidence event was linguo-evidence-ikSDT7RQuo.json instead of just evidence.json
All other Kleros dapps are currently using evidence.json, so for consistency + gas savings, the filename should just stay as evidence.json, unless there's a reason I haven't caught up yet.