I tried with www.taobao.com with the same result ...
Also tried with a reuters page from French to English, same result.

It's not about making things better, it was working perfectly one or two months ago, and i've been using this tool without any problem for years ...
Tt's about fixing what was broken.

Anton, Jason - can you look into why https://world.taobao.com/ is getting an UND CLD3 rating? Could we also look generally to see if more pages are getting undefined?  

Thanks for reporting this. It seems that there two separate threads in the messages above. One is that CLD3 sometimes predicts 'und' and a bubble doesn't show up in the upper right corner. The other is that right-clicking and selecting "Translate to ..." doesn't actually translate the page. 

Regarding the former, as yyushkina@ said, for some pages only a small amount of text is passed to the language detector CLD3, so the output is 'und' (i.e., unknown). The page world.taobao.com is one of them.

Regarding the latter, I *think* that these steps use the server-side lang id model, not CLD3. Also, on Linux with 58.0.3029.81, I visited http://www.baidu.com/, https://world.taobao.com/, and http://fr.reuters.com/, right-clicked and selected "Translate to English". Translation worked as expected.

fred.berbigier@gmail.com, can you please confirm that you are using M58 and that for the three pages above you are right-clicking followed by selecting "Translate to ..."?

Yes, I can confirm this, right-clicking followed by selecting "Translate to ..." says translated, for all 3 sites, but nothing happens, upper right translate button also does nothing. It used to work perfectly fine, so not sure what's going on.

Sorry forgot to confirm my Chrome version:
Version 58.0.3029.81 (64-bit)

Hmm, I cannot reproduce this on Mac OS either. It seems from earlier messages that there was indeed an issue but should be fixed in M58. I wonder if the update does not work properly for some M57 versions. I'd try reinstalling.

yyushkina@, let's cc folks who worked on the fix to give advice?

I precise I did reinstall Chrome, and issue is the same on Linux for my side.

Might actually be an issue with Translate team and not Chrome, that the Chrome part does its job, but Translate doesn't with a certain Location/Language configuration. That's what I believe in more and more.

Hi All!

Chrome-es support forum user have attached information.

Tested URLs:
https://support.google.com/toolbar/answer/9271?hl=en
https://www.washingtonpost.com/
http://www.parismatch.com/
https://gmplib.org/

Errors Log file:
No errors.

Detection Logs:
Attached as translate_internals_detect_logs_dump.json

Prefs:
Attached as Prefs.jpg

Chrome Version:
Google Chrome	58.0.3029.81 (Build oficial) (64 bits)

Console log screenshoot:
Attached as Captura.jpg


abakalov@chromium.org about Comment 19, i think that we are not looking two different threads. 
Users report that when they press translate, Chrome show the message: "Web translated" but, content is not translated. That's should be caused by the "und" detection (As you can see in the screenshot attached).

Another imporatnt topic is that, if they use the Google Translate extension (https://chrome.google.com/webstore/detail/google-translate/aapbdbdomjkkjkaonfhkkikfgjllcleb?hl=es-419), extention works fine and translate the page correctly. Have chrome another logic for this process?

Thanks!
Nico.

Deleted: translate_internals_detect_logs_dump.json 9.9 KB

translate_internals_detect_logs_dump.json 9.9 KB View Download

Deleted: Prefs.jpg 90.9 KB

	Prefs.jpg 90.9 KB View Download

Deleted: Captura.jpg 109 KB

	Captura.jpg 109 KB View Download

Hi Nico, could you add the detection logs for all pages. More specifically:
- go to chrome://translate-internals/#detection-logs
- visit the four pages
- go back to the first tab and click "dump"

The log from the previous comment shows that two pages were loaded:
- new tag with prediction "und", which is expected because of the very small amount of text on the page
- https://gmplib.org/ with prediction "en" (i.e., "English").

 Issue 713929  has been merged into this issue.

Anton - I tested your very good hypothesis that this is based on country variation but I'm still getting good behavior with country set to Spain (same as the user that nicods.2006 mentions), with multiple UI languages.

barakt@, ftang@ - can you look at the Captura.jpg screenshot that nicods.2006 shared in c25 and see if this a Translate server issue? In particular why could the server be returning 403 code persistently for certain users? 

Just a quick note, the credit for the good hypothesis goes to fred.berbigier@gmail.com :)

It seems to me that this is not a CLD3 issue, so I am going to remove myself from the owners list to allow others to take over but please feel free to add me back if that's not the case.

Thanks for setting the record straight, Anton :)

fred.berbigier@ - thanks for sticking with us. A couple more questions while we wait for the Translate team. 

1) When you go to chrome://settings/languages, do you have the box next to "Offer to translate pages that aren't in a language you read" checked?

2) Can you take a screenshot and share your Prefs tab from chrome://translate-internals?

Hello, yyushkina@chromium.org
1) Yes, but because images are better than words sometimes, screenshot attached
2) Here you are :)

Deleted: language_prefs_chrome.jpg 105 KB

	language_prefs_chrome.jpg 105 KB View Download

Deleted: language_prefs_chrome_2.jpg 90.8 KB

	language_prefs_chrome_2.jpg 90.8 KB View Download

Deleted: language_prefs_chrome_3.jpg 67.4 KB

	language_prefs_chrome_3.jpg 67.4 KB View Download

Deleted: language_settings.jpg 82.5 KB

	language_settings.jpg 82.5 KB View Download

Deleted: settings.jpg 111 KB

	settings.jpg 111 KB View Download

Thank you so much! I do see that for several languages we're not showing you prompts automatically (you can see them under translate_too_often_denied_for_language in the Prefs) but this should not be causing your right-click translations to fail.  

One last (hopefully :)) experiment: Can you go to http://espn.uol.com.br/noticia/690332_em-bom-momento-e-se-adaptando-ao-portugues-hernandez-diz-tenho-que-esperar-uma-oportunidade and tell me whether:
1) You see a Translate bar at the top
2) If you see it, click Translate and tell me if the page translates
3) If it does translate, can you go back to the Original and then right click to Translate and see if that works as well.

Thanks again for all your patience.

No worries @yyushkina@chromium.org :)
1) Yes
2) Doesn't translate
3) Doesn't translate

Frank / Barak,

Why would users be getting 403 errors (see Captura.jpg in Comment 25) when trying to translate?

We have looked into this but have not been able to reproduce this in Chrome.

Then you are blocking certain Ip ranges from using API, this all started recently ( around the same time Translate was unblocked in China), but it affects other languages, I tried without logging into Chrome, on Windows, on Linux, same result, and speech in Android translate is also broken, all at the same time. That's the only explanation I can find on a 403 without a username on an api key (Chrome) that should be recognized and authenticated, is that your servers got some new ban on datacenter IPs (since I'm behind a VPN).
Since speech was failing with VPN on Android, I tried without, and it works, it really seems of some barbarian rules that blindly blocks too many ip ranges ... Add if that's the case, you won't of course be able to reproduce it.

Do you mind sharing what your IP is? We can take a look and see whether it's blocked. Do other Google services not work for you as well (Gmail, etc.)?

Unfortunately I can't, as my vpn provider doesn't make those public for obvious reasons.
Google translate speech is also broken (Android), that's all I could notice. I can give some data, but not publicly.

Google Translate speech works again, so i guess that glitch got fixed, Chrome translate tool is still broken.

So in general Google Services (of which Translate is one) will block certain IP addresses if there is a significant amount of abuse (e.g. automated queries) detected from them. It's possible that some of the computers that use your VPN have been doing this and since all traffic would come form the same block of IPs they would all get blocked. In such a case it'd be useful to contact your VPN provider to see if they've received a notification that unusual traffic is coming form their network (e.g. https://support.google.com/websearch/answer/86640?hl=en).

The translate team is also investigating whether they may be blocking any addresses inadvertently that they should not be and if it's discovered they are I'll update this bug.

For now marking as external dependency. Again, apologies that this is occurring but there is not much we can do on the Chrome side outside of bringing this to the Translate team's attention.

 

Hi All!

This is Nicolas from Chrome-es again.

We have some users reporting this problem, but they are not using a VPN.

We will send you IPs:
- 83.50.118.222

(You can see other important information in the attached image)

Deleted: IPagain.jpg 155 KB

	IPagain.jpg 155 KB View Download

Hey Nicolas - can you start a separate bug please since this bug is about connections over VPN? In that bug please provide for each user having issues: reproducible steps, whether the issue is seen on specific URLS or across sites, and attach screenshots of the user's prefs and detection logs (after browsing on some number of sites where translation is requested) from chrome://translate-internals?

Hi again yyushkina!

Sorry, i haven't noticed that issue topic has change, i've participated in this issue.

Actually, you can found my comments with this information in this issue (c7 and c25).

Behaviour is the same, if you want, i can create a new issue, but, sincerely i think that the problem is hardly related.

Hey Nicolas, yep this bug kind of took on a life of its own and became specifically about issues due to blocked IP addressed but it's fine. I'll check whether the IP address in question is being blocked and investigate. As mentioned above, the translate team is also investigating whether they may be blocking any addresses inadvertently that they should not be and if it's discovered they are I'll update this bug.

Just my 2 cents, but with translate unblocked in China, given the huge traffic bump that involves, most likely if there are automated ip banning (definitive ban), this isn't going to ease things anytime soon. 
I tried without a vpn, since translate is unblocked, and while it says it's translated, nothing happens, the last thing I can think of, is Chrome trying to get its location settings based on the system profile and that certain profiles don't work anymore, I recently got a notification from Windows saying it couldn't say where I was located.

Since my chinese ip never was used with Google translate before, it can not be an ip ban issue. That was my initial thought because of the 403 error, but could it be that some location profiles that worked before suddenly can't because of an API change that is now expecting some parameters that some location/language/encoding profiles can't provide ?

Let's say you're using a vpn, your connection is with USA (or any other country, doesn't really matter), your local timezone is set to China (my case), but your local language is set to English (US), how do you handle that ? I didn't try changing my timezone and see what happens yet, but given i tried over 4 different vpn providers, even tried with my local ip, and there's no change, that's the only remaining factor.

I tried changing my timezone, with and without vpn 
same result, www.suning.com
VM1991:239 POST https://translate.googleapis.com/translate_a/t?anno=3&client=te_lib&format=…ld=vTE_20170501_01&sl=zh-CN&tl=en&sp=nmt&tc=3&sr=1&tk=145731.289954&mode=1 403 ()

2017-05-13 21:45:45	https://www.suning.com/		zh-CN (Chinese (Simplified))	true	false	zh-cn	zh-CN (Chinese (Simplified))

One more here with the same problem.
I have tried everything in this thread:
- Creating new profile
- Reinstall Chrome
- Delete all cookies, temp files, even my bookmarks!
Translate still not working.
My current IP: 62.57.192.114
I dont use a VPN, I have disabled firewall, antivirus, etc etc.
Chrome: Version 58.0.3029.110 (64-bit)
If I visit the last URL posted in Comment 51, i get a 403, "Your client does not have permission to get URL"
I have attached a print screen.

Cheers!

Deleted: 403error_Myclientisnotallowed.JPG 51.1 KB

	403error_Myclientisnotallowed.JPG 51.1 KB View Download

Is there a filter towards some sites through Chrome translate tool ?
I just tried using google translate through the web interface, it works perfectly well. Really odd that what works through Google translate doesn't through Chrome translate ...

Hi again Team!

We have news from a Chrome-es forum user.

He has created a new windows user, and there, translator works. If he's in the new windows user, all works fine, but, in his old windows user, translator doesn't work.

I'll attach the user files:
new_* files are the new profile files.
old_* files are the old profile files.

Thanks again for your hard work.
Regards,
Nico.

Deleted: new_Captura.jpg 93.1 KB

	new_Captura.jpg 93.1 KB View Download

Deleted: new_internals_detect_logs_dump.json 8.3 KB

new_internals_detect_logs_dump.json 8.3 KB View Download

Deleted: new_prefs.jpg 89.3 KB

	new_prefs.jpg 89.3 KB View Download

Deleted: old_detect_logs_dump_1.json 8.3 KB

old_detect_logs_dump_1.json 8.3 KB View Download

Deleted: old_internals.jpg 95.1 KB

	old_internals.jpg 95.1 KB View Download

Deleted: old_prefs.jpg 101 KB

	old_prefs.jpg 101 KB View Download

old_prefs shows translate_too_often_denied for en as true.

Note there are changes to this processing coming with the new 2016Q2 UI (see https://cs.chromium.org/chromium/src/components/translate/core/browser/translate_prefs.cc?rcl=ee42f00f402c8d2aff960d60079e77a94fc5aed5&l=382)

I really doubt this is related to a system user profile, as I tried this on Linux with the same issue.
Problem is this Error 403, that Chrome translate tool gets denied from Translate services, where the web interface works perfectly fine.
Why is it denied in the first place ? From the very beginning, we never had a real answer to that question, and since this issue is recent, it really seems very odd that with numerous reports on this being broken that we still weren't given any other answer that, can't reproduce ... And changing the number of attempts so it answers it can't translate won't change a damn thing to this issue, it is still broken, while it was working not so long ago.

@napper: having  translate_too_often_denied set to true won't impact right click translations though (it just won't show you the prompt) so I don't think that's it. The Translate team took a look at the requests from 83.50.118.222 (provided by nicods.2006) and the ones that were denied did not have a valid API key associated with the Chrome version (this happens if you're using a custom Chromium build instead of a Chrome official build installed from https://www.google.com/chrome/) but the ones that did get translations did not have this issue. 

@yyushkina: understood. But it is weird that with one user, the translations worked, but with another user the translation didn't work (comment #54). Presumably both these users used the same build of Chrome?

Hi @napper and @yyushkina!

I'll request chrome://version screenshot to the user in order to validate the chrome version. 

That should be useful. Is that right?

Regards.
Nico.

> I'll request chrome://version screenshot to the user in order to validate the chrome version. 

Thank you, that would be useful.

Happy to help and be usefull. I have Requested the screenshoots!

Anyway, in the forum topic (https://productforums.google.com/forum/?#!topic/chrome-es/Z0HsxnpkFyg) you can found the original question. There he have attached the chrome://version information:

Google Chrome 58.0.3029.81 (Build oficial) (64 bits)
Revisión ac0bae59f0aa5b391517e132bf172144b1939333-refs/branch-heads/3029@{#746}
Sistema operativobWindows 
JavaScript V8 5.8.283.32
Flash24.0.0.189 internal-not-yet-present
Agente de usuario Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36
Línea de comandos"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end
Ruta del ejecutableC:\Program Files (x86)\Google\Chrome\Application\chrome.exe
Ruta del perfil C:\Users\Despacho\AppData\Local\Google\Chrome\User Data\Default
Variaciones3095aa95-3f4a17df

All seems legit. Consistent version. Correct program directory. 

 
If you see the last answer (https://productforums.google.com/d/msg/chrome-es/Z0HsxnpkFyg/8yNthH4GBAAJ) you will found a extension page screenshot.

I think that there is nothing suspectious.
 
Anyway i have the screenshots again.

Thanks again for your hard work!

Regards,
Nico.

Ok, so my assumptions were correct, it's actually the api keys that are messed up, any way to force a regeneration of those ? Chrome Re-installation doesn't work for this, so I guess there's another place where this is stored ?
I do have the official Chrome installed though, I might have had a Chromium installed in the past, so that might be some remnant files.
That makes sense, it coincides with Google partly killing Chromium sync, side-effect.

zea@, grt@ - adding you per rpop@'s recommendation as API key experts. We're running into an issue with missing API keys and reinstalling not repairing Chrome which makes Translate servers return 403().

Nicolas here again :)

I got the screenshoots. 

I see just one difference, flash version. I'm not sure if that can be related.

Regards,
Nico.

Deleted: translator_working.jpg 113 KB

	translator_working.jpg 113 KB View Download

Deleted: translator_broken.jpg 121 KB

	translator_broken.jpg 121 KB View Download

The API keys are in the Chrome binaries and are not stored in user data. They can be overridden by an environment variable, however, which would certainly cause translate to stop working and would be consistent with it not working for one user account on a machine but working just fine for another.

Would you please check to see if the GOOGLE_API_KEY variable is set in your environment?

You could also try running Chrome with --enable-logging --v=1 on the command line. This will generate a chrome_debug.log in your User Data directory (%LOCALAPPDATA\Google\Chrome\User Data). Search for "google_api_keys.cc" in that file. If you find something like this:

[30088:30672:0520/224715.259:VERBOSE1:google_api_keys.cc(270)] Overriding API key GOOGLE_API_KEY with value spam from environment variable.

Then that's the problem.

@grt I've got good news, this was indeed the case, and I know why it was there, this follows the installation of AndroidStudio, since those environment variables got added at that time, and yes, I had AndroidStudio installed in both Linux and Windows,  I removed those variables, and it works as intended, problem solved !

[4432:7344:0521/090533.886:VERBOSE1:google_api_keys.cc(255)] Overriding API key GOOGLE_API_KEY with value no from environment variable.
[4432:7344:0521/090533.886:VERBOSE1:google_api_keys.cc(255)] Overriding API key GOOGLE_DEFAULT_CLIENT_ID with value no from environment variable.
[4432:7344:0521/090533.886:VERBOSE1:google_api_keys.cc(255)] Overriding API key GOOGLE_DEFAULT_CLIENT_SECRET with value no from environment variable.

I just tried translate tool, and it works normally.
Thanks a lot for finding and pointing that out !

Thanks @grt!

That's the problem!

But... now, how can we check who is overriding that API Key?

I will attach the user log, just in case.

If you can found some extra information in this file, we'll really thankfully if you can explain us how to found it, next time a crbug ticket will not be required :)

Thanks again!
Nico.

Deleted: chrome_debug.log 494 KB

chrome_debug.log 494 KB View Download

@grt 

my logs look like this :
[5660:4496:0525/101445.546:VERBOSE1:google_api_keys.cc(255)] Overriding API key GOOGLE_API_KEY with value no from environment variable.
[5660:4496:0525/101445.546:VERBOSE1:google_api_keys.cc(255)] Overriding API key GOOGLE_DEFAULT_CLIENT_ID with value no from environment variable.
[5660:4496:0525/101445.546:VERBOSE1:google_api_keys.cc(255)] Overriding API key GOOGLE_DEFAULT_CLIENT_SECRET with value no from environment variable.

but i dont know wich application override this value. how to fix it?

@grt

update from me :
i deleted all windows registry for GOOGLE_API_KEY, GOOGLE_DEFAULT_CLIENT_ID and GOOGLE_DEFAULT_CLIENT_SECRET and reload the registry...it works!

thank you so much... you save me...

It would be great if we could get confirmation of what other software is setting these environment variables. Please respond on this issue if you can figure it out. Thanks.

@grt can you explain us how we can figure out what program is overriding it?

It will take some folks who are having this problem either figuring it out or telling us what software they have recently installed that might have done it. Android Studio does not seem to be the problem -- I've checked with the team and have verified locally that it is not setting GOOGLE_API_KEY in the environment. Unfortunately, there's no simple place to look on a Windows computer to find out what program is responsible for setting a variable in the environment.

Thanks @grt!

Is not my business, but, the fix is really complex for regular users (Delete records from Windows register, is a advance process for the most part of Chrome-Es users).

Is there any possibility to remove those records (If exists) as a new step in Chrome Cleanup Tool (https://www.google.es/chrome/cleanup-tool/)?

We have a lot of threads about this issue, and if we can't get the responsible of this overriding, we couldn't give a happy response to those users

Thanks again for your hard work!

Technically, it's not about registry, but environment variables.
If you're looking to deploy a solution on a large scale, I guess this could help
https://support.microsoft.com/en-us/help/121170/how-to-access-environment-variables-in-an-ms-dos-batch-file

All you need to do is to deploy a startup script which would overwrite/override it on a domain.

That's correct Fred!

But, Comment 70 fixed it removing some keys from windows registry.

Actually, we haven't more clue about how fix it than this :(

If i'm not wrong, main problem is that if you have a record in your registry, chorme will not use the environment var (Log message says: Overriding API key GOOGLE_DEFAULT_CLIENT_SECRET with value *no from environment variable.*) but the registry value. 

Chrome reads the values from the environment, not from the registry. The environment is populated based on the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment and HKEY_CURRENT_USER\Environment registry keys, so deleting the values there will make them absent for future processes.

Having the Chrome Cleanup Tool delete them is an interesting idea. +robertshield to take this into consideration.

How about we remove this env var override in official Google Chrome​ builds? I can see why it's useful for development and for Chromium, but why for Google Chrome? Does anyone on-thread know?

+1 to removing from official builds, seems like the override causes confusion and I don't see a non-developer use case for it. 

Hi All,
i try to find which program that change the setting of windows environment...
but still not sure.. the suspect is firefox update...

i change the environment through windows registry by this step :
- click start --> run (or "search programs and files") --> type "regedit"
- then "edit" menu --> Find --> type "GOOGLE_API_KEY" --> click "find next" button
- if it found the "GOOGLE_API_KEY" with value "no", i delete it (right click then delete)
- below the registry key "GOOGLE_API_KEY", also delete "GOOGLE_DEFAULT_CLIENT_ID" key and "GOOGLE_DEFAULT_CLIENT_SECRET" key
- continue the search (f3 button on keyboard or find next on edit menu)
- after all GOOGLE_API_KEY, GOOGLE_DEFAULT_CLIENT_ID and GOOGLE_DEFAULT_CLIENT_SECRET key with value "no" deleted, reload the registry (it easier by restart your windows)

i dont know what is side effect of this action except my translation on chrome works again. i will report if there is bad effect... (but still there is no until now)

Thank you so much ,  My translation works after deleting GOOGLE_API_KEY and other from registry.

grt@/robertshield@/rpop@ - is there anyone that needs to chime in before moving forward with removing this environment variable override in official Google Chrome​ builds? I'd love to have a fix for this that doesn't require each affected individual user to delete environment variables manually.

SGTM. If we're worried that this will break something we haven't thought of, the engineer implementing should send a design doc per https://docs.google.com/document/d/1eqxrys_EnlCvLDXWhMZOPBDmPEuSs9xgw7VZ_CW5l9Y/edit#heading=h.bc3qpbpz6z7n to over-communicate and allow people to raise objections.

robert and i had a small chat about this yesterday. while we could contrive some possible uses of the env var overrides in official builds, they felt contrived. i think rpop's proposal to send out a small doc explaining the change is the right next step.

yyushkina: are you comfortable with doing this and prepping the CL?

Hi All!

We saw a huge amount of users reporting this problem in Chrome-es and chrome-en support forums (We've found some topics about 1 year ago).

Prepare a CL, Approve/discuss that, make changes and launch a new release with those changes will take time, right? Is there any possibility to add this to the Chrome Cleanup tool meanwhile? I don't know the CleanUp Tool workflow, but if this is faster, maybe we can give a happy answer to users faster.

Regards,
Nico.

@grt: I don't think you want me prepping any CL's for the codebase's sake, I'm just a simple PM :) Would you or Robert be able to take this on or should rpop and I look for someone? 

@privard/robertshield: would it be possible to have the Chrome cleanup tool help with a swift solution for this issue - clearing out GOOGLE_API_KEY environment variables? The TL;DR of this thread is that users are unable to use Translate because some unknown program is setting environment variables that then over-ride the GOOGLE_API_KEY in official Chrome builds.

Here's a bug for the first piece.  crbug.com/728481 

It's possible to have the cleanup tool do it, but I don't think that's the best solution. 

It won't really help that much - the cleanup tool only runs when the reporter component (that doesn't change things on the system) finds stuff to clean, messages to the user that they have junk on their system and the user accepts the cleanup.

Until we have evidence that the presence of this env var is symptomatic of a specific family of (policy-violating) unwanted software that we would clean generally, I wouldn't recommend prompting the user to run the cleaner just for this.

Removing support for the env var from official builds is the right thing to do and we should do that.

If this can wait a week or so, I can take a look. It looks on the surface like a simple CL (i.e. add #if here: https://codesearch.chromium.org/chromium/src/google_apis/google_api_keys.cc?l=268) though since it may break someone's workflow it will need writing up as rpop mentioned above. 

If there's anyone who would like to take a stab at the doc/CL in the meantime, I'm happy to review. 

Robert - it'd be great if you could take this on in one week. Given that we just-just branched we can hopefully still get the patch into 60, right?

@nicods: for the time being please recommend that users delete environment variables manually using the steps detailed above as we work on the longer-term fix.

Hey Robert - just wanted to check in to see if you'd be able to take a look at this issues this week?

My apologies, this week got a little busy. I've started working on a patch, functionally speaking it looks pretty straightforward. 

Unsure how many things this will break though, will ask on some lists tomorrow if anyone knows who's using the environment variables.

Awesome, thank you!

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

commit 156c7095f41e676fbdd780ead1450be6aaff6d53
Author: robertshield <robertshield@chromium.org>
Date: Tue Jun 20 21:26:51 2017

Disable environment variable override of API keys on official builds.

BUG= 710575 

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

[modify] https://crrev.com/156c7095f41e676fbdd780ead1450be6aaff6d53/google_apis/google_api_keys.cc
[modify] https://crrev.com/156c7095f41e676fbdd780ead1450be6aaff6d53/google_apis/google_api_keys_unittest.cc

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

commit 8d06e9e1d811adc8b28cf9b65552e9affe6ce60e
Author: robertshield <robertshield@chromium.org>
Date: Fri Jun 23 14:09:18 2017

Update Google API keys header comment.

Mention that env var overrides don't work in Google Chrome builds.

BUG= 710575 

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

[modify] https://crrev.com/8d06e9e1d811adc8b28cf9b65552e9affe6ce60e/google_apis/google_api_keys.h

Hi there,
I was having this exact same problem:-
https://productforums.google.com/forum/?utm_medium=email&utm_source=footer#!msg/translate/m-tREbUPSEo/FYMoe3GwAQAJ
Fortunately Rina - put me on to the right track which lead me here.
I carried out the solution as at comment 81 at their suggestion and, so far, it has worked perfectly.
My only issue (and it's a small one!) is I spent 3 or 4 days trying different solutions I found on the web before I actually found this one!
But thanks to y'all.
Jon C.

 Issue 728481  has been merged into this issue.

Glad that the temp fix worked for you, Jon! Thanks to the work by robertshield, this issue should permanently fixed in Chrome starting with version 61 as well so that other users don't have to go through the manual fix. 

Actually - Robert any chance we can ask the TPMs to merge your change into 60? This is a frustrating issue for users to experience and as you can see from the comments of the few who managed to find their way here, a confusing one to manually fix.

@yyushkina: never hurts to ask I suppose.

@bustamente: there is desire in #101 to merge the change at https://codereview.chromium.org/2939403002 to M60. What say you?

This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

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

It seems to me that if a the API call to translate gets a 403 message then it should not say page completed.   If the API key is being overridden by an environment variable, then it should display the fact that there was an error and a link to a page describing the environment variables.    
If it gets a 403 using the default API key, well, then I don't know what that's all about, maybe a link to a page that says you're FUBAR.    

Reporting back that everything is fine does not seem to be the right answer.

We are working on improving the error handling and messages for cases such as these. See https://bugs.chromium.org/p/chromium/issues/detail?id=722680

robertshield@ / yyushkina@ - can you please confirm if the fix has been verified in canary or dev? Is this overall a safe merge?

Rejecting merge to M60. 

I'm on Chromium 61.0.3159.0 64 bit on Windows 10 Pro and translation doesn't work. Please help.

Console reports - Failed to load resource: the server responded with a status of 403 ()

@c109: Did you try the fix in c81?

FWIW, I just tried out version 61.0.3159.3 on Win10 Pro with the environment variables

GOOGLE_API_KEY=foo
GOOGLE_DEFAULT_CLIENT_ID=foo
GOOGLE_DEFAULT_CLIENT_SECRET=foo

and saw translate requests succeed whereas they fail with 403s on e.g. 59.0.3071.115 with the same variables set.

+1 to checking your environment variables and clearing them out as per c81, please let us know if you do not have these variables set and are still seeing 403s. 

Verified GOOGLE_API_KEY=spam123 ignored in Chrome 61.0.3159.5 Win10, for google.com, mic use OK.  The fix is in dev and should promote to beta in a few days.

In bug 717419 there is a related use case where some combination of extensions involving 'Awesome Net Tab Page' prevent the mic icon from being displayed.

delete 

GOOGLE_API_KEY=foo
GOOGLE_DEFAULT_CLIENT_ID=foo
GOOGLE_DEFAULT_CLIENT_SECRET=foo

worked for me 
thank you 

On the MacOS:
1. vi .bashrc
2. Add the lines
export GOOGLE_API_KEY=foo
export GOOGLE_DEFAULT_CLIENT_ID=foo
export GOOGLE_DEFAULT_CLIENT_SECRET=foo
3. Save the changes
4. Quit Chrome 
5. source .bashrc

Fixed the issue!!! Thanks to all who shared the Registry fix on Windows!

This bug also impacts:
  Google Voice Search (mic: No Internet connection)
  Extension: VoiceNote2 - uses Google voice search
  Google Docs  - voice typing
  Google Translate - page auto translation (no microphone dep?)
in all languages.

If you can help get the word out about the env var fix for the current version 60, in other languages or forums let me know here 
  (English, Translate Help Forum)
  https://productforums.google.com/forum/#!topic/translate/m-tREbUPSEo

I've already scanned/posted to 
  forum threads mentioned in this bug
  the Chrome Help 'mic - no internet' threads
  the Translate help forum thread *PSEo ref above
  2 chrome-es help threads

I am surprised there aren't more CRs merged in here given the number of use cases/failure modes involved.