Leo: as I mentioned in the related email, could you investigate the feasibility of showing UI language in target language list in this case?

This bug is same as  crbug.com/721178 
We set that bug as WontFix/WAI after discussion in email.
Will we reconsider to allow choosing the target language in the source language list?

Technically, we could do that by adding a few lines in TranslateMenuHelper.java#getMenuList()

I am working on crrev.com/2951963002 which allows choosing target language in the source language list.
And it will dismiss infobar when choosing "English" -> "English".

However, I haven't implemented the following:
- Remember the incorrect language detection and won't show translate infobar again when reloading or continuing navigation.

It is because:
1. in case user accidentally choose "English" -> "English", he/she can still have chance to bring back the infobar by reloading.
2. CLD3's accuracy is ~97% (if I remember correctly) so it is more likely that Chrome will correctly detect the language when continuing navigation. 'Won't show infobar again' may overkill.

Hey Marti, that sounds good to me. One thing to clarify: you say above that the CL "will dismiss infobar when choosing "English" -> "English"." That's just the example right? The infobar will be dismissed for all languages where "language" -> "language"?

Grace - does this solution and logic sound good to you? 

Yes Yana, that's just an example.
Infobar will dismissed whenever source language equals target language.
thx!

Thanks for looking into this. The implemented behavior sounds good.

I was expecting to not see the incorrect infobar for the same site as I have corrected it. In another word, reload should not show the infobar. But continuing navigation may show. This is recommendation, not requirement.

Thanks Grace.
I will get crrev.com/2951963002 commited first.
Then see what I can do for the "reload case".

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f1bc64b52ad0ed1ea64baf2e29e37e0bc4575f59

commit f1bc64b52ad0ed1ea64baf2e29e37e0bc4575f59
Author: martiw <martiw@chromium.org>
Date: Sat Jul 01 07:00:58 2017

Allow choosing target language in more languages menu(translate infobar)

Allow choosing target language in the source language list.

1. When user chooses target language in the source language list,
   The infobar will dismiss, and no translation takes place.
   This will not be regarded as a "translation declined" and it
   will not triggered auto-never or increment the declined counter.

2. User still cannot choose source language in target language list.

BUG= 734654 

Review-Url: https://codereview.chromium.org/2951963002
Cr-Commit-Position: refs/heads/master@{#483906}

[modify] https://crrev.com/f1bc64b52ad0ed1ea64baf2e29e37e0bc4575f59/chrome/android/java/src/org/chromium/chrome/browser/infobar/TranslateCompactInfoBar.java
[modify] https://crrev.com/f1bc64b52ad0ed1ea64baf2e29e37e0bc4575f59/chrome/android/java/src/org/chromium/chrome/browser/infobar/translate/TranslateMenuHelper.java

Hi Jon and Leo,

I am working on  crbug.com/734654 
The fix (crrev.com/2951963002) allows user to choose any language in the "Page not in this language" menu.
And when source = target language, the translate infobar will dismiss.

My question is. what should happen when user reload that page?
For example, when the page source language was detected as Chinese and user changed it to English manually.
Should the page be detected as Chinese again when the page reloads?

I ask this because I am thinking how to implement "reload should not show the incorrect infobar" (Comment 7)

Any thoughts?

Thanks,
Marti

So I understand:

1. English page loads and is detected as Chinese
2. User clicks "Page is not in Chinese?" and chooses "English"
3. User hits reload.
4. Page is again detected as Chinese.

Ideally I think we should remember that the user corrected the source language and not show the translate infobar again. However I am not sure how long that decision should last. Forever? How can the user change it if they made a mistake?

Yana, WDYT?

What in my mind was some kind of temporary settings stored in the Tab instance (Ideally there is already some APIs we can use directly). So once the user tells us the detected language of the page was wrong, we could save the data and not show the translate infobar for the same origin.

The problem is, the decision whether to show an translate infobar is made in the native part (TranslationManager) and the logic is shared by all platforms. Introducing a new condition may be not easy.

If the decision (not show infobar) is *forever*, the way we handle it should be as same as "Never translate this site".

Seems "dont show incorrect infobar when reload" cannot be done on the java side.  We need to deal with that on the native side without breaking other platforms.
"Never site" may overkill if the site has pages in more than one language.

I was wondering if we can cache the page source language using infobar_delegate#nav_entry_id_ as index?
and skip the language detection in case the page language is cached?

If possible I think we should look for a general solution to this problem, not one that is Android specific. We are planning to migrate the UI to iOS, and the desktop UI has similar issues (you can ask it to translate "English" to "English").

I agree with Jon that any solution to this should be cross-platform. On the product side at first I was worried that we'd be eliminating an escape hatch for a user who accidentally declared the language incorrectl. Last, as Marti mentions, it's an unlikely issue to occur (for the page to be both mis-detected and the user to navigate to it again) so if the fix is complex I wouldn't prioritize it.

Yes, it seems to me that the fix complexity for "reload not showing incorrect infobar" may outweighs its impact.  I'd like to stop by here by now.

That SGTM. Feel free to mark as fixed then.