Closed (fixed)
Project:
Translation Management Tool
Version:
7.x-1.x-dev
Component:
Core
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
12 May 2012 at 15:07 UTC
Updated:
10 Jul 2012 at 07:31 UTC
Jump to comment: Most recent file
Comments
Comment #1
berdirYou need to provide an API key for the Microsoft Translator, have you done that? I thought there is a better error message for that, but we might have broken that one.
See http://drupal.org/node/1490100
Comment #2
steveray commentedI have an API key ("45DB..." from https://ssl.bing.com/webmaster/Developers/AppIds/) entered on the config page and made sure there was no leading/trailing whitespace.
Does the Application Name on the Bing Application Details page make a difference? I used "Translation Management Tool".
Thanks
Comment #3
steveray commentedDigging around in the code I find the source of the "(unsupported)" text string here: drupal\sites\all\modules\tmgmt\tmgmt.module line 840:
It seems that $translator->canTranslate($job) is false... but why?
Is it related to this issue: http://drupal.org/node/1538762 ?
Thanks.
Comment #4
steveray commentedI updated to the latest dev dated 2012-May-12 and found no change.
Comment #5
steveray commentedI enabled all of the remaining modules and found:
File translation flow works fine
Local translator is "(unsupported)"
This site is being developed on a windows xp localhost and is not externally visible on the web... is this an issue with the translation services? Module downloads and status reports from d.o work fine, for example.
Comment #6
steveray commentedI copied the entire site directory and database from my localhost environment to an external shared-host with a domain name and found no change in function.
Configured a myGengo account with $5, entered the public and private keys, but it is also "(unsupported)".
Comment #7
steveray commentedChanged the issue Title, Version, Component and Category since the issue is not just with the Microsoft translator.
I rolled back to a pre-Translation Management Tool install state (a new d7 site without even content) and started over.
This time I installed the tmgmt 1.0-alpha1 version.
I checked that the Microsoft/Bing translator API key is good; the Local translator does not require a key.
Same problem as with the dev versions, the Microsoft and Local translators are both listed as unsupported.
Comment #8
yukiyasu commentedI have same issue.
This may be because of this?
http://msdn.microsoft.com/en-us/library/hh454950.aspx
See "Using the Access Token" paragraph.
It says that "Bing AppID mechanism is deprecated and is no longer supported. As mentioned above, you must obtain an access token to use the Microsoft Translator API."
Also it is reported that only newly created appid doesn't work.
http://www.bing.com/community/webmaster/f/12248/t/675117.aspx
Comment #9
GDrupal commentedI'm having the same issue and i'm debugging all day long trying to find the cause. No luck yet. :x
Comment #10
berdirYes, it looks like they changed the appId stuff:
This is the error returned when trying to fetch the languages:
<html><body><h1>Argument Exception</h1><p>Method: GetLanguagesForTranslate()</p><p>Parameter: appId</p><p>Message: Invalid appId
 Parameter name: appId</p><code>message id=3643.V2_Rest.GetLanguagesForTranslate.236EE1DE
Looks like they completely revamped how things work and we'll need too.
Basically, it looks like you now need to get a client Id and client secret and save that as settings instead of the appId then get a token based on that and request translations with that. See http://msdn.microsoft.com/en-us/library/hh454950.aspx, has some example code at the bottom.
Any volunteers for writing a patch? ;)
Comment #11
berdirComment #12
berdirSee also http://www.bing.com/community/site_blogs/b/developer/archive/2012/04/12/...
That's a month old and they're talking about a transition time of several month's there.. weird.
Comment #13
GDrupal commented@Berdir : Mmmmm seems like we are dealing with a changing scenario, I can begin testing the new api to figure out if it's working that way at least, but perhaps (intuition speaking here) could change again in a short term. Because moving from free to pay, could be a great success or big fail. I think I can go with this since is a blocker for testing (or fixing) pretty everything else.
Do I have your blessing? ;)
Comment #14
berdirYes, sounds good. I'll check today if we have a contact there that can tell us if this is the final version or if it's going to change again in 3 month.
Hint: drush en -y tmgmt_test. That gives you a test translator that does dummy translation by adding the target language prefix. Useful for testing to avoid having a dependency on another service.
Comment #15
berdirWhat's interesting is that my existing installations are working just fine.
I'm currently suspecting that Microsoft is not accepting *new* Bing ID's anymore but old ones still work. Rumors are that there is a working key buried in the git history of this project, but you didn't hear this from me.. Seriously though, you should only use that one for testing, it *will* break sooner or later and we need to implement the new API.
Comment #16
steveray commentedI tried this out on my on-line instance.
The rumored older API key works and the translation occurred without problems.
I then switched back to the newer API key and Bing was "(unsupported)" again.
Thanks for uncovering the root cause.
Comment #17
GDrupal commentedHi Guys! I was struggling with this long time... but seems to we working for me. Please test it and let me know how we can improve it.
Comment #18
berdirgetToken() can return FALSE, what happens in this case? We should try to deal with this and do a $job->reject() with a reason on that case.
Should be formatted according to the coding standards, no "string" and the description on a new line.
Nice that we can keep backwards compatibility for existing keys. However, we should add a warning somewhere that the API key is deprecated, will be removed in a future version and new users need to get a Client Id/Secret.
Comment #19
GDrupal commented@Berdir: Cool thanks for the review! I will fix all this and submit the patch ASAP.
Comment #20
GDrupal commentedHere is the patch with the fixes. There is a funny thing with the error if the getToken() function fails, so I move it a little. I dont know yet if its the best way to do it but make sense for me. Please fell free of review and test it.
Comment #21
berdirNot exactly sure what happens now if it fails, will need to try it out.
Have you experience in writing tests? We have some tests for microsoft translator that use an internal, faked backend to return predefined results for those requests. We should switch them to the new system as well. That includes: Add a new menu callback there for requesting the token. Define a dummy, hardcoded client id and secret and return a example token in the expected structure if correct. Update the existing callback to check the token instead.
If you don't then we can commit this without changing the tests and deal with it when removing the api id so that we have a working microsoft translator again.
Comment should be wrapped at 80 character.
Needs a space before Create and array should imho be lowercase.
Let's replace the description instead of changing the title. Because the description is useless now, you can't create new ones. Let's add something like this "This parameter is deprecated and not necessary. Switch to a client id as soon as possible if you are still using it."
Can we move the new parameters above the API ID so that the focus is on them and users aren't confused by that one.
Comment #22
GDrupal commented@Berdir: Thanks for your review. I have wrote test for webform localization... so I think I can manage it. I will continue with this until we close Microsoft translator for good. ;)
Comment #23
lucascaro commentedThanks @GDrupal, the patch makes the MS translation work again for me as well.
Comment #24
corvus_ch commentedComment #25
berdir@GDrupal: Just wanted to ask if you're still working on this one? I'f you're stuck or are having questions, I'm often in the #drupal-contribute/#drupal-i18n IRC channels or you can ask here.
Comment #26
GDrupal commented@Berdir: I was struggling with the test class and some cache issues (+ xdebug enviroment issues) but seems to be working now. Here is the patch, please feel free to review it so we can improve it. There is a few changes in logic since now you can even get the available languages without a correct api parameters...
Comment #27
GDrupal commentedComment #28
berdirGreat, commited and pushed, thanks for working on this!
Comment #29
miro_dietikerThis issue is about "removing support for Bing ID". Still after upgrade i see in the translator settings a ID setting with text that declares it deprecated.
The translator states it is "unconfigured".
If you remove the support for Bing ID i think we should completely remove that field.
Comment #30
berdirThey only removed support for *new* Bing ID's, existing ones still work, that's why we left the setting in there so that existing sites continue to work and have time to request an azure thingy.
Support for this can be removed at a later point, when the existing Bing ID's stop working as well.
Comment #31
miro_dietikerAs stated above: the tranlator currently states to be unconfigured even if there's a old Bing ID in the settings.
Thus the old system doesn't work anymore in current state. We should revert that / fix it.
Comment #32
berdirFixed, should now work again.
Comment #33
fmosca commentedIs the microsoft translator gone from the latest -dev or am i missing something?
Comment #34
berdirYes, see the message on the project page, all external translator plugins have been moved to separate projects, you can find the microsoft translator here: http://drupal.org/project/tmgmt_microsoft