Step 1 may not be necessary. But somehow this bug doesn't occur in some Chrome profiles. I suspect extensions unintentionally preventing the bug.

Thanks for filing the issue!

@Reporter: Could you please clarify us on point no.4 in comment#0. Does "Close it, then reopen it" means closing https://twitter.com/paurubio web page and reopening it in a new tab ?
Your Feedback helps us to triage the issue in a better way.

"Close it, then reopen it" is referring to the translate bubble.

Thank you for providing more feedback. Adding requester "vamshi.kommuri@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on reported chrome version 64.0.3282.140 and latest canary 66.0.3355.0 using Mac 10.12.6, Windows-10 and Ubuntu 14.04 hence providing Bisect Info

Bisect Info:
================
Good build: 64.0.3261.0
Bad build: 64.0.3262.0

You are probably looking for a change made after 514670 (known good), but no later than 514671 (first known bad).

https://chromium.googlesource.com/chromium/src/+log/687b4385de466e7f3783d0f401f64d296551df94..6b7caf9d9a9948625b933566f9479990bb014dc2

Reviewed-on: https://chromium-review.googlesource.com/756365

@Xiaocheng: Please confirm the issue and help in re-assigning if it is not related to your change.
Adding ReleaseBlock-Stable as it is seems a recent break, feel free to remove it if not applicable.

Thanks!

@groby: Do you know how does Chrome determine whether a page has been translated?

Does it compare the page innerText with the text dump generated by WebFrameContentDumper?

Guess I found the cause.

Before page translation, page language is determined by DeterminePageLanguate() (in language_detection_util.cc/h) from the page text capture. In the test case, we incorrectly determine the page as English, which is the reason why the translation prompt doesn't pop out automatically.

However, when translating the page, our (powerful) translation server correctly finds that the page is Spanish, and performs the translation.

Now when the translation prompt is invoked again, it compares the original language (English) with the language translated into (still English), and hence concludes that the page hasn't been translated yet.

Conclusion: root cause is that language_detection_util fails to detect language.

+napper

Do we really consider this as a serious P1 regression?

With a second thought, I think we are running into a boundary case that's hard to fix.

In general, how do we decide if a page is a Spanish page, or an English page with some Spanish text inside? There is no clear answer, or clear boundary between them.

I think the test case page is somehow an boundary case: it contains so much English text (see the attached text dump), so that it is in the "fuzzy boundary" between English and Spanish for the language detector. With my patch in #7 slightly changing the whitespace characters in the text dump, the detection result changed from Spanish to English.

In general, we always have such boundary cases. A better idea might be changing LanguageState to actually store whether the translation server has been called, instead of simply comparing two language codes.

Deleted: dump.txt 12.7 KB

dump.txt 12.7 KB View Download

In fact, it's not caused by my patch...

With my patch reverted, it still detects the page language as English.

So I think it's a regression caused by changes in CLD instead of WebFrameContentDumper.

Hence, I'm removing RBS due to the low severity of the regression and the external dependency.

External dependency on https://github.com/google/cld3/issues/10

CLD3 issues are not an external dependency. Adding Jason/Anton  and correct label.

Separately: "A better idea might be changing LanguageState to actually store whether the translation server has been called, instead of simply comparing two language codes." How complex is that fix?