Change Details

A new limit to prevent the publication of fast unreviewed translations (T331023) was created. This is intended to prevent cases where users publish translations at a fast-pace without enough time to review their contents, which has been an issue in some contests and similar events. As mentioned in T331023#10088279, the initial implementation makes the Confirm step (T276221) to become unresponsive after the user taps on the button to start translating. This is produced because (a) checking the data on the previously published translation takes some time, and (b) the wait is not communicated to the users. This ticket proposes to explore how to improve both fronts. Some initial ideas listed below: # Reduce the (perceived) wait - **Move on as soon as possible.** The complete calculation for the limit requires checking the number of paragraphs of the last published article and the time it was started. Given that the maximum waiting period we ask users for is fixed (10min), we can use that to our advantage and move on as soon as we are sure the translation was started earlier. For example, if the start time of the previous translation is more than 10min ago, we don't need to request more data about the translation. Furthermore, if the **published** time for the previous translation is older than 10min, its starting time is also guaranteed to be 10min or earlier. In this way the published time. - **Start the calculation earlier.** As soon as the user gets to the Confirmation step, this calculation can be started. - **Reuse the calculation.** For a user that is allowed to start a new translation, the situation will remain the same as long as the user does not publish a new translation where it has to be reevaluated for new translations. We can avoid making the calculations again when we know the previous result is still valid. # Communicate the waiting - After the user taps the confirmation button, it should become disabled. - If the loading exceeds a few milliseconds, a [Codex Inline Progress bar](https://doc.wikimedia.org/codex/latest/components/demos/progress-bar.html) can be shown attached to one of the parts of the Confirm step. Placement and alternatives to be explored.

A new limit to prevent the publication of fast unreviewed translations (T331023) was created. This is intended to prevent cases where users publish translations at a fast-pace without enough time to review their contents, which has been an issue in some contests and similar events. As mentioned in T331023#10088279, the initial implementation makes the Confirm step (T276221) to become unresponsive after the user taps on the button to start translating. This is produced because (a) checking the data on the previously published translation takes some time, and (b) the wait is not communicated to the users. This ticket proposes to explore how to improve both fronts. Some initial ideas listed below: # Reduce the (perceived) waiting - **Move on as soon as possible.** The complete calculation for the limit requires checking the number of paragraphs of the last published article and the time it was started. Given that the maximum waiting period we ask users for is fixed (10min), we can use that to our advantage and move on as soon as we are sure the translation was started earlier. For example, if the start time (or the publish time) of the previous translation is more than 10min ago, we don't need to request more data about the translation. The published time can be a useful approximation to the start time (since a translation published 10min ago could not have been started more recently). Similarly, as part of the calculations for "Your impact" module in the dashboard that shows the translations published in the last 30 days for the user we can be sure that users with 0 translations published in the last 30 days will be able to start a new one immediately. - **Start the calculation earlier.** As soon as the user gets to the Confirmation step, this calculation can be started. - **Reuse the calculation.** For a user that is allowed to start a new translation, the situation will remain the same as long as the user does not publish a new translation where it has to be reevaluated for new translations. We can avoid making the calculations again when we know the previous result is still valid. # Communicate the waiting - After the user taps the confirmation button, it should become disabled. - If the loading exceeds a few milliseconds, a [Codex Inline Progress bar](https://doc.wikimedia.org/codex/latest/components/demos/progress-bar.html) can be shown attached to one of the parts of the Confirm step. Placement and alternatives to be explored.

A new limit to prevent the publication of fast unreviewed translations (T331023) was created. This is intended to prevent cases where users publish translations at a fast-pace without enough time to review their contents, which has been an issue in some contests and similar events. As mentioned in T331023#10088279, the initial implementation makes the Confirm step (T276221) to become unresponsive after the user taps on the button to start translating. This is produced because (a) checking the data on the previously published translation takes some time, and (b) the wait is not communicated to the users. This ticket proposes to explore how to improve both fronts. Some initial ideas listed below: # Reduce the (perceived) waiting - **Move on as soon as possible.** The complete calculation for the limit requires checking the number of paragraphs of the last published article and the time it was started. Given that the maximum waiting period we ask users for is fixed (10min), we can use that to our advantage and move on as soon as we are sure the translation was started earlier. For example, if the start time (or the publish time) of the previous translation is more than 10min ago, we don't need to request more data about the translation. Furthermore, if the **published** time for the previous translation is older than 10min,The published time can be a useful approximation to the start time (since a translation published 10min ago could not have been started more recently). its starting time is also guaranteed to be 10min or earlier.Similarly, In this way the published timeas part of the calculations for "Your impact" module in the dashboard that shows the translations published in the last 30 days for the user we can be sure that users with 0 translations published in the last 30 days will be able to start a new one immediately. - **Start the calculation earlier.** As soon as the user gets to the Confirmation step, this calculation can be started. - **Reuse the calculation.** For a user that is allowed to start a new translation, the situation will remain the same as long as the user does not publish a new translation where it has to be reevaluated for new translations. We can avoid making the calculations again when we know the previous result is still valid. # Communicate the waiting - After the user taps the confirmation button, it should become disabled. - If the loading exceeds a few milliseconds, a [Codex Inline Progress bar](https://doc.wikimedia.org/codex/latest/components/demos/progress-bar.html) can be shown attached to one of the parts of the Confirm step. Placement and alternatives to be explored.