On 05/28/2011 03:32 PM, Daniel wrote: > Note that Google is not closing off all translation services. They > are moving to using the Translate Element within web pages ( > http://translate.google.com/translate_tools ). I assume the reason is > a freestanding translator page does not bring in any revenue, while a > web page element on pages that carry their adsense ads increases how > many of their ads can be read by people around the world (ie makes > money for them). I'm with <https://lists.secondlife.com/pipermail/opensource-dev/2011-May/007116.html> Argent in interpreting the note on Google's page such, that they'd only deprecate the API (Application Programming Interface) <http://code.google.com/intl/en/apis/language/translate/overview.html>, not the freestanding translator page <http://translate.google.com/>. This makes sense, even from your ad revenue perspective: While they don't currently have advertising on the freestanding page, they could easily place some there, without bothering the users too much. (It might annoy some users, but probably not enough for most to cease using the page.) And even today, without ads, the page carries the Google branding and links to other Google services, thus giving 'free' exposure to the brand and maybe attracting users towards other Google services.
The API however returns the translated text, so Google can hardly deliver advertising there without seriously impairing the usability of applications using the API. (Actually, JSON data is returned, so an ad could be delivered within that in a separate string from the translation result, but why would an application want to display the ad, then?) Off course, we /are/ using the API in the viewer, not scraping the freestanding translator page, so this deprecation /does/ affect us. > The question is can you incorporate that web element as a substitute > for what you are using now? Not easily. The magic there is done by the java scripts included from Google's servers. The 'element' itself merely tells the scripts what to translate (whole page or just a part) and some parameters (source language, background colour etc.). While with qtWebkit, we do have a HTML renderer including a JavaScript engine on-board, I don't think it'd be a good idea to turn the chat display into a (dynamic?) website, just so we can use the Google Translate Element for translating it. So this would leave us with analysing the scripts to see how they call the service. (I don't assume the translation happens in the scripts themselves, i.e. client-side. Just imagine the size of databases it would have to download wouldn't the translation happen server-side.) Then we could use the same (undocumented!) API. However, this probably wouldn't be easy: Although lacking linebreaks and indentation as well as comments and speaking variable names, http://translate.google.com/translate_a/element.js?cb=googleTranslateElementInit looks innocent enough. But can you make any sense of http://translate.googleapis.com/translate_static/js/element/main.js , which is loaded by that first script? But even if this were easier (or if we'd reverse-engineer the API by another way, e.g. looking at the calls a browser makes when viewing a page using the Google Translate Element), there are good reasons not to use an API 'extracted' like that: * As an internal API without public documentation, it would be subject to change without notice at any time. Google would just update its scripts so that pages using the element would continue working, while our application's use would break and we'd have to reverse-engineer the changed API anew. * Although I'm not sure we'd break a Google policy (the Google Translate Element web site <http://www.google.com/webelements/translate> doesn't mention any), the API would obviously not be meant for usage other than by Google's scripts, so using it otherwise might be considered abuse. * Google might change the API (together with its scripts) even when they don't have a technical reason to do so, simply to annoy (perceived) abusers. Would that happen, we'd be in a very bad position to complain about it. Probably not the direction we'd want to go, is it? Even scraping the freestanding translator page seems more harmless. (Not that I'm endorsing the latter, mind you.) Cheers, Boroondas
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
