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

Marc Adored marc at inworlddesigns.com
Sat May 28 13:18:22 PDT 2011


I think the main issue here is abuse due to bad coding. The real
discussion should not be who it needs to move to or what other service
can be abused next it should be how do we write better code to lesson
the burden on whatever service we use. Secondlife has a LARGE userbase
therefore any usage will be great but what can we do to make that
usage more efficient.... Just think... right now every user who has
machine translation enabled for google is translating every line of
text they read. Even if someone else already translated it. Thats
thousands of queries per second. None of that load makes any money for
google or microsoft for that matter. So the service being abused on
top of no revenue is kind of a slap in the face. SO maybe some thought
into making the code a little better should be done first. Maybe some
type of central caching service... I know security issues security
issues but I am just throwing out ideas. Because to me 1500 different
people translating the same line of text is just abuse and retarded.
Maybe some kind of central proxy from secondlife can be setup so if
the same line of text is queried it just spits out the translation
thats cached to them. The cache lifetime should be short for security
purposes but caching a translation for 5mins should be plenty of time
for everyone receiving that text to get the cache translation. Just
think of how much of a burden that will remove from google. I know it
will put more of a burden on a secondlife server somewhere but not
that much because its just spitting out cache its not like its
translating any text or anything just serving cached data. You could
even tell each TPV that if they want to offer translations they have
to setup some type of caching. Hell it could probably even be some
simple proxy with a decent cache time setup. I don't know the
specifics but I know it can be done better. Sadly what has happened
here is what happens when you don't put limits on a service. Crappy
code is written and the service is abused. I am sure that google
simply throttling the api will make quite a bit of better code emerge
from the depths... That may even be Googles plan and why such a long
period before its shut off completely. SO maybe the thought pattern
should be "how can we do what we're doing better" instead of "who can
we jump ship to next and abuse" Because like others have said google
is a very big company, bandwidth is very easy to come by for them so
if we are hurting them then its going to be worse for others. No body
is better suited for such a task then google. Just my $0.02 :)

On Sat, May 28, 2011 at 9:32 AM, Daniel <danielravennest at gmail.com> wrote:
> The problem as pointed out by Tateru Nino on her blog is that Google is
> huge, and their
> users will "fail over" to other services like you are suggesting,
> causing them to get overloaded
> also.  In that case, they may also decide it is too expensive to stay
> open, causing a chain
> reaction.
>
> 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).
>
> The question is can you incorporate that web element as a substitute for
> what you are using now?
>
>> From: "Philippe (Merov) Bossut"<merov at lindenlab.com>
>> Subject: Re: [opensource-dev] in-viewer translation is dead soon.
>>
>> Hi,
>>
>> It shouldn't be too hard to substitute with another service. Someone has an
>> alternative service to propose?
>>
>> Cheers,
>> - Merov
>>
>
> _______________________________________________
> 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
>


More information about the opensource-dev mailing list