655066 - Integrate Google Translate into translate page

Status: RESOLVED WONTFIX

(support.mozilla.org :: Knowledge Base Software, task, P3)

Description

[Ricky Rosario [:rrosario, :r1cky]]

When creating a new translation, there should be an option to run the english content through google translate to get a base to start working off.

Some options:
* Client-side/js integration. I am not sure if this is possible (do they support it?) or a good idea (CSP, etc).
* Get the google translation from the server-side.
* Build a jetpack. Is this acceptable?

Comment 1

[James Socol [:jsocol, :james]]

(In reply to comment #0)
> * Build a jetpack. Is this acceptable?

I want to take this idea out to dinner and a show, then on a handsome cab ride through the park, I like it so much.

Comment 2

[Kadir Topal [:atopal]]

For me it would be the last resort ;)

Maybe you can hit up the Verbatim guys? They do support that already over there.

Comment 3

[Tanay Gavankar [:tgavankar]]

This may be a little more difficult since Google no longer offers the Translate API.

Comment 4

[James Socol [:jsocol, :james]]

Specifically, the Google Translate API was deprecated[1] and will be shut off completely on December 1[2]. The recommend using the Translate Element[3] which _may_ work, but we'll need to research that.

[1] http://www.searchenginejournal.com/google-drops-numerous-apis-including-translate/30198/
[2] http://code.google.com/apis/language/translate/overview.html
[3] http://translate.google.com/translate_tools

Comment 5

[:ibai]

Cheng and I have done the math and we have around 1.61 million characters in our articles, without counting summaries and titles. Including them we should be below 2M or in other words, 40$ to translate a full locale.

It seems to be worth it even with the paid API.

Should we revamp this? Particularly for locales that were activated but are not maintained anymore? We are still serving those locales to a couple of users a month who don't get the info in their language.

Comment 6

[[:Cww]]

That is 1.61M for all articles, this bug seems to be on a per-article basis.  If we only do the top 25 articles and automatically do them for all the locales where they're missing, that could help, too.

Comment 7

[Vito Smolej]

> If we only do the top 25 articles...

The better way would be to provide translation memories first, aligning the material already localized. But then, the whole idea of using TMs and TM-based translation tools, has not yet been accepted here. 

I have been using OmegaT since two three years and have collected a portfolio of 116 UTF8 files - and the corresponding EN-SL SuMo translation memory:
https://www.dropbox.com/s/aq3rqvqhf6bbuiq/project_save.tmx

Localizing without a TM support is like walking instead of taking a bus.

I am ready to show more of it, if theres interest. At MozCamp Berlin there were just two participants at my talk - but I am sure the shoes got tighter in the meantime.

Comment 8

[Vito Smolej]

... cont

btw, here my movie on the subject of doing l10n with OmegaT

http://www.youtube.com/watch?v=IrJY5RtBiis

Comment 9

[James Socol [:jsocol, :james]]

(In reply to :ibai from comment #5)
> Cheng and I have done the math and we have around 1.61 million characters in
> our articles, without counting summaries and titles. Including them we
> should be below 2M or in other words, 40$ to translate a full locale.

A more interesting number would be how many characters would we have to translate per year.

> It seems to be worth it even with the paid API.

We should be conscious of the FOSS nature of Kitsune, and make sure that paid APIs aren't a requirement to run it.

Comment 10

[:ibai]

(In reply to James Socol [:jsocol, :james] from comment #9)
> (In reply to :ibai from comment #5)
> > Cheng and I have done the math and we have around 1.61 million characters in
> > our articles, without counting summaries and titles. Including them we
> > should be below 2M or in other words, 40$ to translate a full locale.
> 
> A more interesting number would be how many characters would we have to
> translate per year.
> 
> > It seems to be worth it even with the paid API.
> 
> We should be conscious of the FOSS nature of Kitsune, and make sure that
> paid APIs aren't a requirement to run it.

Agree. In this case this is not a requirement but a boost to the actual situation where a big piece of the KB corpus is not localized/updated. Anyone can take Kitsune and not use Google Translate. James, from this thread I understand that you are not against using Google Translate, just against using a paid service in coordination with Kitsune. Am I reading this correctly? 

We could investigate the integration of a Translation Memory, although we should find one that is web based to simplify it's usage. I'm not sure if the Twitter translation center can be considered to have one but it gives you suggestion based on previous translations. That logic is easier with simple strings instead of paragraphs but we can explore it.

Comment 11

[James Socol [:jsocol, :james]]

(In reply to :ibai from comment #10)
> James, from this
> thread I understand that you are not against using Google Translate, just
> against using a paid service in coordination with Kitsune. Am I reading this
> correctly?

I'm wary of making SUMO *depend* on a paid service.

As for Google Translate in particular, they've replaced it with something which probably wouldn't fit our needs very well: http://translate.google.com/manager. As far as I can tell, we could restrict the widget to en-US pages, but we wouldn't be able to restrict the languages within it on a per-page basis--i.e. I don't think we could easily use it as a fallback for xx but not yy, if xx was out-of-date or not translated and yy was up-to-date.

Comment 12

[Ricky Rosario [:rrosario, :r1cky]]

(In reply to James Socol [:jsocol, :james] from comment #11)
> As for Google Translate in particular, they've replaced it with something
> which probably wouldn't fit our needs very well:
> http://translate.google.com/manager. As far as I can tell, we could restrict
> the widget to en-US pages, but we wouldn't be able to restrict the languages
> within it on a per-page basis--i.e. I don't think we could easily use it as
> a fallback for xx but not yy, if xx was out-of-date or not translated and yy
> was up-to-date.

We could possibly only drop it on the /<locale>/kb/<english-slug> pages like https://support.mozilla.org/ak/kb/flash-113-doesnt-load-video-firefox

Also maybe on /<locale>/kb/<localized-slug> where the content is way out of date.

It wouldn't help users landing on /en-US/kb/<english-slug> looking for another language though. But that might be fine?

Comment 13

[Ricky Rosario [:rrosario, :r1cky]]

(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #12)
> Also maybe on /<locale>/kb/<localized-slug> where the content is way out of
> date.

Actually, that won't work. But the first case might be a good use for it?

Comment 14

[Kadir Topal [:atopal]]

Yeah, the first case would ineed be a good use for it. 

We dropped this out of the scope of the Q4 l10n tool improvements, because it's not  as straight forward as normal text (condering our show-for syntax) but I'd strongly reconsider this for the 1st quarter. We can see from our helpfulness surveys that languages that have more content localized have a higher helpful rating than languages with fewer localized articles. 

We could implement this and measure the oucome with the helpfulness rating. It might be that automatic translation works for some languages better than for others, then we can decide on wheather to keep it or for what languages to keep it.

Comment 15

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

Michal, do you think integration of any translator will be useful?

Personally I think anyone can use Google Translator directly, and I would strongly discourage our localizers as it does not work well for longer texts in Czech, but that might be some Czech specific.

Comment 16

[vesper]

We could add a link for users to try Google Translate (since it's the most popular tool out there) if there is no content in their locale and they get an en-US page.

The quality will not be perfect, but if we include a proper disclaimer (and encourage people to support SUMO through localizing articles with us), maybe it would help start community l10n for niche locales.

If you have an easy way of including it, we should experiment with it for a locale or two over a period of at least a month. Let me know and we can discuss the details to be set up.

As an aside: I would abstain from integrating third party tools into our localization flow - we do not control them, and our localizers may have strong preference for other tools.

Comment 17

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

That should be something definitely doable. The most complicated way will be, I think, how to implement some metrics the best way. We will need to get in touch with someone responsible for Google Analytics.

Comment 18

[Alice Wyman]

Moving this bug back to the original product and component since we aren't switching back to Lithium.

Comment 19

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

leaving as P3, but maybe this is a good first add-on for a volunteer? can this be done using a Firefox web extension add-on?