[CWS] Translation for precompiled answer

[myungwoo]

There are five pre-compiled answers.

1. "Yes"
2. "No"
3. "Answered in task description"
4. "Invalid question"
5. "No comment"

In the past, they only view in English, itself, at ContestWebServer. This commit makes them show on each localizations.

---

This change is 

[myungwoo]

Review status: 0 of 4 files reviewed at latest revision, 1 unresolved discussion.

---

cms/server/contest/handlers/communication.py, line 56 at r2 (raw file):

    @multi_contest
    def get(self):
        # Call translate function for precompiled answer
        self._("Yes")
        self._("No")
        self._("Answered in task description")
        self._("Invalid question")
        self._("No comment")

Is this the best way? Please suggest better one.

---

Comments from Reviewable

[lw]

While I see what you're trying to achieve, I'm not sure I like this change. These pre-compiled answers are just suggestions for the admins so that they can type less. The field they are for is otherwise free-form text, and so is the full message. If admins were actually to provide custom answers they would have to enter them in an already localized form. This would mean that the same database field will contain two different types of data, which I find improper.

From a more user-centric point of view, I see a few risks with this change. In a multi-language contest some contestants may be able to see these messages in their locale (because it is supported in CMS) while others may have to see them in English: this may cause fairness concerns. On the other hand, translations may not be perfectly accurate and contestants may misinterpret their meaning. Finally, there could be a weird scenario where admins give a localized answer that turns out to be a valid English expression, which CMS may have a translation for and which would then be "doubly" localized, possibly changing its meaning.

[stefano-maggiolo]

I like the change :) Admittedly it's not perfect, but status quo is not perfect either.

• For IOI-like contests (lots of contestant languages, most not supported by CMS) it is customary to remove translations to avoid the fairness problems Luca mentioned (which extends way more than precompiled answers).
• For national contests, currently there is no way to have precompiled answer in a CMS-supported local language (which would be the only or one of the few used), and this would give that opportunity.

The possibility of having the same string is a bit scary but also far-fetched. I hear your argument about having a field with two meanings in the DB, but that's already the case! If in language X "Yes" means "No" in English, how is a student speaking language X supposed to understand if "Yes" they receive is written in English or X?

One possible way to clarify (still think it's a bit overkill) would be to write "<No as written in language X> (untranslated: Yes)" or something along this line.

[lw]

An alternative to this change, that should still achieve the desired effect but that would solve all my concerns, is to have the admin interface propose as pre-compiled answers the ones we currently have already translated in the user's default language. What do you think?

On Mon, Aug 14, 2017, 06:14 Stefano Maggiolo [email protected] wrote:

I like the change :) Admittedly it's not perfect, but status quo is not perfect either.

• For IOI-like contests (lots of contestant languages, most not supported by CMS) it is customary to remove translations to avoid the fairness problems Luca mentioned (which extends way more than precompiled answers).
• For national contests, currently there is no way to have precompiled answer in a CMS-supported local language (which would be the only or one of the few used), and this would give that opportunity.

The possibility of having the same string is a bit scary but also far-fetched. I hear your argument about having a field with two meanings in the DB, but that's already the case! If in language X "Yes" means "No" in English, how is a student speaking language X supposed to understand if "Yes" they receive is written in English or X?

One possible way to clarify (still think it's a bit overkill) would be to write " (untranslated: Yes)" or something along this line.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/cms-dev/cms/pull/788#issuecomment-322153297, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHX6iDCL17d10sSVPkqnFHnQFMIn_z-ks5sYB3ogaJpZM4OpIqf .

[stefano-maggiolo]

SG, @myungwoo would this be ok to you?

[myungwoo]

Sorry for the late reply. The only case I thought was the yes/no problem which @stefano-maggiolo mentioned. The solution of the problem is adding a new pre-compiled answer like "Do not ask question in negative sentence".

I don't really understand the proposal of admin interface. Is it the option for contest like "Allow user tests" or just warning for translation?

[stefano-maggiolo]

The idea would be to keep the interface not-translated in CWS, and instead add a new set of precompiled answers to AWS in the locale of the user we are responding to. It will both allow admins to have a precompiled way of answering in the local language, and avoid the potential problems with unexpected translations.

[myungwoo]

Okay, it sounds good. So a new set of precompiled answers would be add to master branch? or just for local change? The latter means no change for this topic, however the former solution need many answers to add.

[stefano-maggiolo]

Yes, we can add this change to master. Just the new set of precompiled answers will need to be retrieved from code, it cannot be hardcoded like the current one.

[andreyv]

I agree with https://github.com/cms-dev/cms/pull/788#issuecomment-322153297:

• If fairness is important, then the admins will want to use one localization for all contestants. This applies to both international contests (English) and national contests.
• For online/training competitions where admins want to allow all localizations, there is no problem and actually a benefit of having precompiled answers translate to each user's language.

Regarding the last proposed solution, how would this look in the admin interface? I think some special cases could be considered:

• What if the admin doesn't know the user's language (see case 2 above)?
• What would happen if the user switches the language mid-contest (e.g., started with English and noticed the language selector later)?

[stefano-maggiolo]

@andreyv I was thinking of using preferred_languages - using the one they selected in CWS would require a lot of work to send the info to the server and store it somewhere. Admittedly this limits the usefulness to contests where this information is known beforehand.

Maybe going back to @myungwoo original patch and @lerks initial observation, we could mark canned answers in the schema, and keep the client side translation only for subjects of canned answers. WDYT?

[myungwoo]

Sorry for the late reply. It was a very busy week to me. Actually, I don't get the new solution. Could you tell me more specifically? (Sorry about my bad English understanding 😢)

[stefano-maggiolo]

Hi @myungwoo, no worries! The current proposal (that also @lerks likes!) is to keep your current commit, and add a field to the Question table in the database. The field, "is_reply_subject_canned" (canned means chosen from a default set of answer) will be default to False, and True when the admin picks one of the proposed answers. If that field is true, the subject will be translated in CWS, otherwise it won't.

[myungwoo]

Thank you for your kind reply :) I have an additional question to take my confusion away. Does "is_reply_subject_canned" work same as "is_reply_translated"?

[stefano-maggiolo]

is_reply_subject_canned has the same meaning as can_reply_subject_be_translated (it won't necessarily be translated, depending on the locale of the contestant)

[myungwoo]

Is the situation you meant because of language which doesnt support translating precompiled answer?

Thank you!

[stefano-maggiolo]

Correct! It's not indicating if it is translated, but if it CAN be translated.

[myungwoo]

Okay. I'll work and update PR with this. What is the best variable name of this option? is_reply_subject_canned or is_reply_can_be_translated? I prefer the latter one.

[stefano-maggiolo]

Ok, but I'd use "is_reply_subject_translatable" (the text of the reply is never translatable)

[myungwoo]

Actually precompiled answer always has no content but only subject. Reply with custom sentence has no subject but only content.

So subject translatable may cause confusion to contest admin. How do you think? :)

[stefano-maggiolo]

I was suggesting that because the db schema has subject and text, and contest admin will never see that wording (it is inferred from whether they used the precompiled answers or wrote one themselves). Anyhow, I don't feel strongly about that, if you prefer using is_reply_translatable is fine (just maybe comment on the field that it refers to the reply subject). Thank you!

[myungwoo]

I've updated the PR. Please check and comment. Thank you very much!

[stefano-maggiolo]

Uhm... sorry, I think there was a misunderstanding: the new field (is_reply_translatable) should be per-question, and automatically set to true when the reply is chosen from the precompiled set, and to false when not.