update to include the latest languages supported by google shown in the snapshot below:


the update adds 2 new language groups:
african and minorities
to keep the translation menu as compact as possible with the new additions; the keyboard accelerators have been removed for that menu

download and save in macros folder, replace original 'translate.kmm'
http://kmext.sf.net/macros/translate.kmm

update::google text trans update to fix stupid google bug: dropdown language pair boxes not complying to the language pair strings

new string:
translate.google.com/translate_t#<from>|<to>|<txt>

to make km use new string in pref..you must:
1-restart km
2-select babelfish translation from using submenu
3-select back google translate
or
select babel, restart and then select google



Edited 1 time(s). Last edit at 11/14/2009 06:48AM by disrupted.

Great, Thanks!

Before I didnt even notice it's buggy, there's already the fix, cool!
And I may not really need african languages etc., but the checkmarks now match again the chosen languages, yeah

it's not really a bug but it annoys me..the new string doesn't work everytime. google decided that if you translate text externally instead of using their actual translate form and button..they will display most used languages for that domain in their to and from dropdown boxes regardless of the language pairs that are actually used for the translation

for e.g: translating from italian to english, the translation is correct using the proper pairs: it>en but the boxes display spanish >english


the pairs differ according to what google has decided as the most used translation pairs for this language, example using translate.google.de.. using string italian to english but the dropboxes display english to german


another example using greek google.gr, translation pairs are italian to english but boxes use english to greek


i think this is dumb and the dropdown boxes should show the right langpairs used in the string but i can't find any way around it..maybe i'll just make a css to hide the dropdown boxes altogether :mad:

please redownload the macro because there was a bug in ;to language' menu..it's fixed now..also goodle has overhauled their translation website and now all dropdown boxes display the proper languages with the new string

Well, from my observation and tests the old/original translate.kmm works (no problems with language pair boxes, etc.) so I'm gonna stick with it.

yes, after google has fixed it, old ranslate string should work without problems.. the main difference is the updated macro supports languages that aren;t inculded in the older macro... for many who won't be needing those new languages, it isn't really necessarily to update..especially that new macro has an extended menu which can be confusing..that's why for my translate; i created a new gropu called it 'commons' with only the languages i might encounter frequently or need to translate words i don't understand (very helpful in learning).. the menu doesn't have any separators so it's compact and tidy and yet i can always activate any language that's not in the 'commons "group if the need arises

It's an ago old thread, but assuming it's the same macro that's included out-of-box long since, it meanwhile needs 2 little bugfixes for "Selected" text. Can only test in KM1.6, but in KM76 those snippets still seem to be the same in included translate.kmm, so most likely needed there too.

@Dorian
==> The blank insertion after linebreaks is very simple and necessary, please include by default.

Am only not entirely sure if the length-limit is the same for all KM-versions and win-systems, perhaps someone can test?

Around line 70 replace this:

_Translate_text{
$OpenURL=sub("<txt>",urlencode($OpenURL),gsub("<from>",$_from,gsub("<to>",$_to,getpref(STRING,$_Translate_pref_text)))); &OpenURL_Selected;
}

with something like this:

_Translate_text{
$OpenURL=sub("<txt>",urlencode($OpenURL),gsub("<from>",$_from,gsub("<to>",$_to,getpref(STRING,$_Translate_pref_text))));
# fix bug: linebreaks without blank merge together last+1.st word on selection-translation:
$OpenURL=gsub("\n","\n ",$OpenURL);
# fix bug: If text length > 2120, Google reports "Error, that's all we know"!
#alert(length($OpenURL)); $OpenURL=substr($OpenURL,0,2120);
if (length($OpenURL)>2120) {
setclipboard($SelectedText);
$OpenURL=_("Selection too long. Please right-click and paste (CTRL+V) ");
$OpenURL=sub("<txt>",urlencode($OpenURL),gsub("<from>",$_from,gsub("<to>",$_to,getpref(STRING,$_Translate_pref_text))));
}
&OpenURL_Selected;
}

Also after saving the macro again, the entry in context menu fell all down to the end of my long menu with selection-context-macros. Fixed by adding position:

# context menus
old: setmenu(Selection,popup,$__s);
new: setmenu(Selection,popup,$__s,"Sen&d By Mail...");

Update:
Meanwhile noticed, google also refuses to translate whole https-pages...
No, not true! It's actually not google that denies, but just the macro itself that wrongly thinks google would!
After modifying the restriction for "https://"; sites to "http" all works fine for example on wikipedia page https://ru.wikipedia.org/wiki/Тектология
May well be that REALLY protected sites cannot be translated, but nowadays all sorts of public sites redirect to https too, so guess we could leave the error message to google itself - but only if it really doesn't work...



Edited 3 time(s). Last edit at 11/25/2015 07:28PM by siria.

Wondering if anyone could test, can the current beta with native translate-macro googletranslate this page, just as example?
Or can major parts of it be selected and right-click-translated without that infamous "that's all we know"-error?

https://ru.wikipedia.org/wiki/Тектология

My old computer only gets errors from google, but am not entirely sure if it has anything to do with my hardware or if it's the same for modern machines too. Strongly suspect the latter...

siria

I get a message saying, "Sorry local and secure pages cannot be translated". I tried to remove the s from https, but it just put it back.

Thanks for testing! But that message is only the macro itself. The https restriction must be replaced with "http" inside the kmm...
Sorry had realized that https-thing only after posting the above, and then edited the pre-previous posting at the end :-)



Edited 1 time(s). Last edit at 11/25/2015 08:00PM by siria.

Have attached an edited macro for easier testing.
The name is different to avoid accidental overwriting of the original one, but of course that must be disabled first to avoid conflicts (I usually just rename to xxx_kmm)

try this:

_Translate_page{
$clnurl = gsub("https://";, "http://"; ,$URL);
$OpenURL=sub("<url>",urlencode($clnurl),gsub("<from>",$_from,gsub("<to>",$_to,getpref(STRING,$_Translate_pref_page))));
index($URL,"http")==0?&OpenURL_Typed:alert(_("Sorry, local pages cannot be translated!"),gsub("&","",_(getpref(STRING,$_Translate_pref_srvc))),INFO);
}



_Translate_link{
$clnlurl = gsub("https://";, "http://"; ,$LinkURL);
$OpenURL=sub("<url>",urlencode($clnlurl),gsub("<from>",$_from,gsub("<to>",$_to,getpref(STRING,$_Translate_pref_page))));
index($LinkURL,"http")==0?&OpenURL_Typed:alert(_("Sorry, local pages cannot be translated!"),gsub("&","",_(getpref(STRING,$_Translate_pref_srvc))),INFO);
}

remove semicolons in the gsub strings



Edited 1 time(s). Last edit at 11/26/2015 02:56PM by disrupted.

siria

I installed your modified translate file and was able to get a translation of the Russian https page.

Thank you. And attached below is now my 'final' version, with yet more updates.
Should still work in all stable KM-versions from 1.5.4 until current KM76 (but tested only in KM1.6)
Change description is inside too:

##### Update 2015-11-26, based on KM76beta2 macro:
# 1) MOD page: allow https-sites, google has no probs with public https-pages like wikipedia etc.
# And for truly protected sites we can leave the error message to google itself.
# 2) MOD selection: Linebreaks without blank make that the last and first words are
# merged together and not translated => add a blank after each linebreak
# 3) MOD selection: If text length > 2120, Google reports "Error, that's all we know"!
# => copy selection into clipboard, then show in google input field a message to user to paste
# 4) MOD: new option for local files, opens google page for uploading instead of showing error
# 5) MOD: use "https:" for google-translation for better privacy, and google redirects there anyway

----
(have not added a new link-option, because google automatically translates all links too when clicked inside an already translated page, and currently google is the only available service)

Hi siria -

Just downloaded your macro, but I think the problem is actually in Google, see this screenshot:


Google does give an English translation, but immediately scrambles it. IMPORTANT: Both translate macros produced this, and I'm sure Google thinks it's Ukranian, when I asked it to auto-detect. Bing has no problems.

Actually, I'm getting sick of Google, how do I insert Bing?

Gordon.

____________________
Understanding the scope of the problem is the first step on the path to true panic. [Florence Ambrose, "Freefall" 01372 January 22, 2007 http://freefall.purrsia.com/ff1400/fv01372.htm]



Edited 1 time(s). Last edit at 01/01/2016 10:29AM by gordon451.

Oh GREAT... greater and greater Nothing but bugs everywhere, sigh.

Perhaps more people can examine this strange behaviour, because manual translations like in your screenshot have always worked fine for me so far, incl. RU>EN
Could it be some encoding issue?

Regarding BING, I had already took a short look how it could be implemented at the time, but am running against a wall here with my old online machine and browser, and various security blocks over the years. No chance yet to see ANY translations or translation interfaces there! :-(

It seems BING offers a bookmarklet for full-page-translation, perhaps that works for you?
http://labs.microsofttranslator.com/bookmarklet/

Such scripts can also be started by macro, but the only advantage over a bookmarklet would be that it uses your "To" language, as set by the KM menu. That's possible because the language pairs are just part of the called URL:
http://labs.microsofttranslator.com/bookmarklet/default.aspx?f=js&to=en
Then again, it would also be easy to just create a few separate bookmarklets for each language.

Anyway, this is how the macro works: it just puts together a modular URL and then opens it.
So if you can figure out a working URL structure on Bing, we could try adding it to the macro.

Here's the silly part with Google. Sit down first

I pasted part of your last post into Google and asked it to give me the Russian. It did, perfectly. Wonderful!!!!! Now let's take the generated Russian text, and render it in English... 8::::::::

I did look at Bing's instructions last night, but I cannot drag their link onto the Favourites Bar. It will only go onto the Tab bar. I think this may be due to the way K-M does things which M-$oft can't quite get hold of.

Gordon.

____________________
Understanding the scope of the problem is the first step on the path to true panic. [Florence Ambrose, "Freefall" 01372 January 22, 2007 http://freefall.purrsia.com/ff1400/fv01372.htm]

OK. This problem really is the property of Google.

Voilà:


I truly don't need this translator.

Gordon.

____________________
Understanding the scope of the problem is the first step on the path to true panic. [Florence Ambrose, "Freefall" 01372 January 22, 2007 http://freefall.purrsia.com/ff1400/fv01372.htm]

Seriously, just tested again, but auto>ru and back auto>en works fine for me
Can't help suspecting some settings prob...
In menu View>Encoding I have chosen utf8 and autodetect-universal.
And javascript is OFF.
In F2>PageDisplay > Languages EN is on top.
Or some cookie-stored setting on google...?

Hmm, considering your screenshot:
What if you simply click on the "russian" button??

---------

And Bing - finally!! After finding a hint on wikipedia, telling that bing offers translations for search hits, this gave me access to their translation page! Doing a search for anything and voila, there they are, "translation" links with the hits. And they do have a modular URL, so basically could be used by macro. At least for full page translation.

BUT: they refuse to translate "secure" https-pages!
Even if public ones like wikipedia, or their own yahoo news pages. Looks hopeless, considering that today all major site are redirecting to https for no reason (except tracking)
Google seems to have fixed this meanwhile, because the former macro code contained this restriction too, throwing an error-alert by the macro itself for https-pages (one of the things I fixed recently), and today google seeems to translate anyway.



Edited 1 time(s). Last edit at 01/02/2016 02:05AM by siria.

I've changed my auto-detect to Universal, the only thing I have off ATM is Flash to keep almost all videos on a leash. Google seems not to have many cookies, unlike Bing which appears to set cookies for language-pairs--that needs to be checked out!

"What if you simply click on the "russian" button??"
I wanted to see how reliable the auto-detect would be, I got Ukranian auto-detected a couple of days ago...

So far, I've been translating highlit text, but just now I simply translated the entire page (http://kmeleonbrowser.org/forum/read.php?1,121498,page=2), but told Google to auto-detect. Google thought the original page was in Welsh... :s And the sense of the translation was hilarous!

Have you seen what Google does to German on pasted/highlit translations? And German has to be one of the simplest languages around! It also does it to Spanish, I suspect any language with diacritics will be mistreated. The only way I can get sense is to edit the passage and remove all diacritics, then work out what the sense should be from Google's mistakes.

Gordon.

____________________
Understanding the scope of the problem is the first step on the path to true panic. [Florence Ambrose, "Freefall" 01372 January 22, 2007 http://freefall.purrsia.com/ff1400/fv01372.htm]

Quote
siria
##### Update 2015-11-26, based on KM76beta2 macro:
# 1) MOD page: allow https-sites, google has no probs with public https-pages like wikipedia etc.
# And for truly protected sites we can leave the error message to google itself.
# 2) MOD selection: Linebreaks without blank make that the last and first words are
# merged together and not translated => add a blank after each linebreak
# 3) MOD selection: If text length > 2120, Google reports "Error, that's all we know"!
# => copy selection into clipboard, then show in google input field a message to user to paste
# 4) MOD: new option for local files, opens google page for uploading instead of showing error
# 5) MOD: use "https:" for google-translation for better privacy, and google redirects there anyway

Hi siria, more on Google's behaviour. Just did a page translate on https://ru.wikipedia.org/wiki/Свод законов Российской империи. Short story is, correctly translated (Russian) wordcount is 2310 which includes infobox, TOC, image titles, everything down to the line where it cuts off. Funny story is, everything after the 2310 wordcount was left as Russian text, which then became garbage only after a mouseover.

I can put screenshots if needed.

Just a few seconds ago I found the "Selection too long. Text is in clipboard. Please right-click and paste (CTRL+V)", selecting a passage and using the Menu>Tools>Translation. That was 108 Russian words.

Gordon.

____________________
Understanding the scope of the problem is the first step on the path to true panic. [Florence Ambrose, "Freefall" 01372 January 22, 2007 http://freefall.purrsia.com/ff1400/fv01372.htm]