[Translate] Integrate TranslateEventProto UMA logging into TranslateManager.

components/metrics/proto/translate_event.proto

Index: components/metrics/proto/translate_event.proto
diff --git a/components/metrics/proto/translate_event.proto b/components/metrics/proto/translate_event.proto
index 8dae1b0c01063fc26b7c52d330bfcd0a2b4da1d6..90bbb005b86add140a60b0f9f2749238a94182f1 100644
--- a/components/metrics/proto/translate_event.proto
+++ b/components/metrics/proto/translate_event.proto
@@ -111,6 +111,17 @@ message TranslateEventProto {
     // The translation was not offered because the URL is not
     // supported (e.g. New Tab Page).
     UNSUPPORTED_URL = 17;
+    // The previous page was in the same language, so the translate UI was

[groby-ooo-7-16, 2016/10/25 18:53:11]

I'm sorry for missing this originally - this seems somewhat related to
TranslateBubbleUiEvent. Can we combine the two, and then hook ranker into
ReportUiAction, or is that a bad idea?

[Roger McFarlane (Chromium), 2016/10/25 20:07:56]

I'm not sure.

My initial thoughts...

ReportUiAction is more fine-grained about the ui interactions it captures. The
logging we are aiming for is more to capture broad user-preference as opposed to
individual clicks (i.e., we capture the selected target language rather than
that the target language menu was clicked, and we don't capture it as a seperate
event, rather we update the event attriubutes and save the event when the user
ultimately accepts or declines the translation.

We could combine it, but I would think we'd want to go the other way: Expand the
context taken by ReportUiAction and move it to TranslateManager or some other
stateful class and centralize all translate event logging to it. Some events
would just generate a histogram event, others would also log the accumulated
context into a TranslateEventProto.

Would also need to integrate ReportUiAction into the translate ui delegate flow
to capture inforbar interactions.

[groby-ooo-7-16, 2016/10/25 23:17:21]

I think overall this makes sense - we have many different places interested in
what happened in the TranslateUI, so centralizing reporting somewhere would make
it a little bit harder to miss changes.

[Roger McFarlane (Chromium), 2016/11/07 20:51:58]

Ok, I'll look at centralizing this. But I think that would be better done in
another CL.

I am (along with hamelphi@) looking at generalizing logging for contextual
assists, including but not limited to translate, over the next quarter or two
and this would naturally fit into this effort. Hopefully, I'll have a more
concrete design doc/plan to share with you by the time we come visit you.

+    // suppressed.
+    MATCHES_PREVIOUS_LANGUAGE = 18;
+    // The web context for the translate is no longer active.
+    WEBCONTENTS_NOT_ACTIVE = 19;
+    // The browser context for translate prompt is no longer active.
+    BROSWER_WINDOW_NOT_ACTIVE = 20;
+    // The browser window is minimized.
+    BROWSER_WINDOW_MINIMIZED = 21;
+    // The focus in on an editable field.
+    EDITABLE_FIELD_IN_FOCUS = 22;
   }
 
   // Event received from translate UI.
@@ -131,4 +142,4 @@ message TranslateEventProto {
   // Modified target language, if the user changed it. If changed more than
   // once, we only keep the last one.
   optional string modified_target_language = 13;
-}
+}

[groby-ooo-7-16, 2016/10/25 18:53:11]

Odd - is this a diff because there's whitespace at the end?

[Roger McFarlane (Chromium), 2016/10/25 20:07:56]

Maybe a trailing newline? Not sure.

I've let 'git cl format' do its thing.

[groby-ooo-7-16, 2016/10/25 23:17:21]

Ack.  ¯\_(ツ)_/¯