Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[CWS] Translation for precompiled answer #788

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

[CWS] Translation for precompiled answer #788

wants to merge 2 commits into from

Conversation

myungwoo
Copy link
Contributor

@myungwoo myungwoo commented Aug 1, 2017 •
edited by stefano-maggiolo
Loading

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 Reviewable

@myungwoo
Copy link
Contributor Author

myungwoo commented Aug 1, 2017 •
edited
Loading

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
Copy link
Member

lw commented Aug 6, 2017

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
Copy link
Member

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.

@lw
Copy link
Member

lw commented Aug 14, 2017 via email

@stefano-maggiolo
Copy link
Member

SG, @myungwoo would this be ok to you?

@myungwoo
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Member

andreyv commented Aug 16, 2017

I agree with #788 (comment):

  • 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
Copy link
Member

@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
Copy link
Contributor Author

myungwoo commented Aug 29, 2017 •
edited
Loading

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

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

Thank you!

@stefano-maggiolo
Copy link
Member

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

@myungwoo
Copy link
Contributor Author

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
Copy link
Member

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

@myungwoo
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

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

@stefano-maggiolo
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@myungwoo @lw @stefano-maggiolo @andreyv