Re: [opensource-dev] in-viewer translation is dead soon.

[Daniel]

You didn't read my previous comment apparently.  They are NOT shutting 
off all translations.
They are shutting the freestanding translation page in favor of embedded 
translation web
elements within pages.  The "why" is the freestanding page doesn't make 
them any money,
while translating web pages *which have Google ads included* gets more 
readers for the ads,
thus makes money.  That is entirely sensible from a business point of 
view, although annoying
for people used to using their service as it has been.

For the built-in translator in recent viewers the choices are (1) delete 
the feature, (2) find a
way to use their web elements component, or someone else's service, or 
(3) host translation
software on LL servers so you are not dependent on the whims of a cloud 
based service
provider.

On 5/29/2011 12:47 AM, Marc Adored wrote:
> One thing I am
> not sure about is why google is just shutting it down instead of
> making the throttling permanent...
>

___
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

Re: [opensource-dev] in-viewer translation is dead soon.

[Argent Stonecutter]

On 2011-05-28, at 22:52, a...@skyhighway.com wrote:
> i don't know if i misunderstood or not, but are you really talking about
> Google translation services particularly picking on SL access?  All the
> mail sounded to me like it was more of a policy decision at Google
> affecting everyone everywhere?

Indeed. Apparently there are over 600 apps using this API in the Android store.

Changing the way SL uses the API isn't going to change Google's mind.

The logical thing to do, it seems to me, is to see if LL can license access.
___
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

Re: [opensource-dev] in-viewer translation is dead soon.

[Tateru Nino]

It's true - they're basically monetizing it. Incompletely, to be sure,
but that's better than killing the whole system.

On 29/05/2011 9:39 PM, Daniel wrote:
> You didn't read my previous comment apparently.  They are NOT shutting 
> off all translations.
> They are shutting the freestanding translation page in favor of embedded 
> translation web
> elements within pages.  The "why" is the freestanding page doesn't make 
> them any money,
> while translating web pages *which have Google ads included* gets more 
> readers for the ads,
> thus makes money.  That is entirely sensible from a business point of 
> view, although annoying
> for people used to using their service as it has been.
>
> For the built-in translator in recent viewers the choices are (1) delete 
> the feature, (2) find a
> way to use their web elements component, or someone else's service, or 
> (3) host translation
> software on LL servers so you are not dependent on the whims of a cloud 
> based service
> provider.
>
> On 5/29/2011 12:47 AM, Marc Adored wrote:
>> One thing I am
>> not sure about is why google is just shutting it down instead of
>> making the throttling permanent...
>>
> ___
> 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
>

-- 
Tateru Nino
http://dwellonit.taterunino.net/

___
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

Re: [opensource-dev] in-viewer translation is dead soon.

[Argent Stonecutter]

On 2011-05-29, at 06:39, Daniel wrote:

> You didn't read my previous comment apparently.  They are NOT shutting 
> off all translations.
> They are shutting the freestanding translation page in favor of embedded 
> translation web
> elements within pages.

That's not what I read.

What I read is they're shutting off the API.

http://code.google.com/apis/language/translate/overview.html

___
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

Re: [opensource-dev] in-viewer translation is dead soon.

[Marc Adored]

Yes the API is being shut off completely. Not just that simple
translation page most see. The Viewer uses the api so thats why it
effects the viewer and tons of other apps. Its not just about
monitization although I am sure it is part of it. The API is extremely
abused not just by Secondlife and I never said it was just SecondLife.
Also my suggestions are not to change Googles mind but to make our
code better so whoever we have to use in the future whether its Google
or another that we put less burden on them so that the service last
longer.

I personally think that Linden licencing the service from google would
be a very good solution. They may also be able to work with google to
make a better library and caching system.

On Sun, May 29, 2011 at 9:37 AM, Argent Stonecutter
 wrote:
>
> On 2011-05-29, at 06:39, Daniel wrote:
>
>> You didn't read my previous comment apparently.  They are NOT shutting
>> off all translations.
>> They are shutting the freestanding translation page in favor of embedded
>> translation web
>> elements within pages.
>
> That's not what I read.
>
> What I read is they're shutting off the API.
>
> http://code.google.com/apis/language/translate/overview.html
>
>
___
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

[opensource-dev] in-viewer translation: API vs. freestanding page, Google Translate Element (was: in-viewer translation is dead soon.)

[Boroondas Gupte]

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

Argent in interpreting the note on Google's page such, that they'd only
deprecate the API (Application Programming Interface)
,
not the freestanding translator page .
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
   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

[opensource-dev] in-viewer translation: alternative services, usage statistics (was: in-viewer translation is dead soon.)

[Boroondas Gupte]

On 05/28/2011 02:00 AM, Philippe (Merov) Bossut wrote:
> It shouldn't be too hard to substitute with another service. Someone
> has an alternative service to propose?
As Daniel has pointed out
,
we have to be careful to not put an undue load on a service provider
with the probably vast translation call volume SL viewers generate. Not
all services will be as well-backed as Google's, and even for Google the
'economic burden' is the argument for deprecating the API.

So whatever service we choose, it'd be good to ask its provider in
advance whether it can cope with our amount of requests. To ask them,
though, we would first have to know ourselves, how many queries there
will be (roughly. More on that below.)

On 05/28/2011 07:47 AM, Pat Nad wrote
:

> I think a good alternative Microsoft offer is the Bing translator, all
> the infos can be found here: http://www.microsofttranslator.com/dev/
>
> they have AJAX, SOAP and REST API
I guess the REST API would be most interesting to us. (The currently
used API is a REST ones, too.)

On 05/29/2011 03:34 PM, Argent Stonecutter wrote
:

> Changing the way SL uses the API isn't going to change Google's mind.
>
> The logical thing to do, it seems to me, is to see if LL can license access.
If that's possible (and affordable), that'd be a good solution, I guess.
Though, Google would probably want to know how many requests we would
expect our project to generate, and I don't think we (incl. LL)
currently have any statistics on that. Off course, LL might know how
much chat is sent around in total on their grid (counting messages
several times when they're received by several clients). Multiplied with
the ratio of residents that have translation enabled, one should get the
number of translation queries.

One could also get the statistics right from Google itself
, if
one uses an API key in the requests. Google's API keys aren't meant to
identify individual developers or individual end users, but rather
projects, such that hard-coding a single key in the Viewer wouldn't be a
problem. (Except that someone not related to the project might snatch
the key from our sources and use it, too. But as keys can be generated
for free 
from every Google account, there's little incentive to do so.)

In Version 2

of the Google Translate API, using a key is required. (And you won't get
any results back without one.) However, the SL Viewer still uses

Version 1

of the API, where passing a key is optional, and it indeed doesn't send
one
.

Note that both versions of the API are being deprecated, so there's
probably no reason anymore to upgrade the the newer one. Using an API
key for the time remaining might pay off though, so we get some numbers.

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

[opensource-dev] Search project viewer

[Jonathan Welch]

In case you have not caught the message yet a project viewer with the
new search recently came out:
http://wiki.secondlife.com/wiki/Search_Project_Viewer_FAQ

There is mention of V1 All and Group search being turned off once it
goes to full release.
___
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