GTranslate is not working because of TCL issues

[ujjain]

While moving my eggdrop from an Ubuntu server to CentOS. Unfortunately I am having issues with getting a tcl script working. I was told to add package require http at the top of the script, but this does not make a difference.

Code: Select all

[14:54:23] Tcl error [gTranslator::translate]: invalid command name "::http::formatQuery"

Sourcecode:

Code: Select all

package require http
namespace eval gTranslator {

       set lngs { "fr" "en" "es" "de" "it" "nl" "tr" }

       #---------------------------------------------------------------------#
   #                    ***End of Settings ***                           #
   #   Do not edit below this line unless you know what you are doing!   #
   #---------------------------------------------------------------------#
   variable author "CrazyCat"
   variable versionNum "0.1"
   variable versionName "gTranslator"

}

namespace eval gTranslator {

       bind pub - !tr gTranslator::translate

       proc translate { nick uhost handle chan text } {
               package require http
               package require json
               set lngto [string tolower [lindex [split $text] 0]]
               if { [lsearch $::gTranslator::lngs $lngto] == -10 } {
                       putserv "PRIVMSG $chan :\002Attention\002 $lngto is not valid"
                       return 0
               }
               set text [::http::formatQuery q [join [lrange [split $text] 1 end]]]
               set dturl "http://ajax.googleapis.com/ajax/services/language/detect?v=1.0&q=$text"
               set res [::json::json2dict [::http::data [::http::geturl $dturl]]]
               set lng [dict get $res responseData language]
               if { $lng == $lngto } {
                       putserv "PRIVMSG $chan :\002Error:\002 Do you really think I can translate $lng to $lngto?"
                       return 0
               }
               set trurl "http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&langpair=$lng%7c$lngto&$text"
               putlog $trurl
               set res [::json::json2dict [::http::data [::http::geturl $trurl]]]
               putlog $res
               putserv "PRIVMSG $chan :($lng) [dict get $res responseData translatedText]"
       }
}

putlog "\002$::gTranslator::versionName $::gTranslator::versionNum\002 loaded"

[CrazyCat]

Well, seems to be a trouble with the http package.

I use package http 2.5, you can get it at http://www.eggdrop.fr/board/downloads.p ... iew&did=85

It must be loaded before the gTranslator tcl.

[ujjain]

Unfortunately the same error. I replaced http.tcl (renamed old version) and restarted the entire VM to be completely certain it would not do anything with the http.tcl. I know, was probably not necessary.

I added package require http before the source scripts/gtranslate.tcl line to be completely certain. Unfortunately the same error:

Code: Select all

*** ujjain joined the party line.
[18:30:03] Tcl error [gTranslator::translate]: invalid command name "::http::formatQuery"

Code: Select all

[ujjain@centos-desktop eggdrop]$ tail -2 eggdrop.conf
package require http
source scripts/gtranslate.tcl
[ujjain@centos-desktop eggdrop]$ ls -al /usr/share/tcl8.5/http1.0/
total 52
drwxr-xr-x 2 root root  4096 Nov 19 18:20 .
drwxr-xr-x 7 root root  4096 Nov  2 21:21 ..
-rw-rw-r-- 1 root root 26426 Nov 19 18:16 http.tcl
-rw-r--r-- 1 root root  9759 Nov  2 20:59 http.tcl.default
-rw-r--r-- 1 root root   735 Nov  2 20:59 pkgIndex.tcl
[ujjain@centos-desktop eggdrop]$

This 9759-bytes big http.tcl works perfectly fine on the Ubuntu-desktop.

Code: Select all

ujjain@ubuntu-desktop:~$ ls -al `locate http.tcl` 
-rw-r--r-- 1 root root 9759 2009-12-05 23:35 /usr/share/tcltk/tcl8.5/http1.0/http.tcl

[CrazyCat]

Well, I'll have a look on this trouble.
I'm using Debian, so it might be hard to reproduce the trouble, but I'll find the solution

[speechles]

Code: Select all

set text [::http::formatQuery q [join [lrange [split $text] 1 end]]]
set dturl "http://ajax.googleapis.com/ajax/services/language/detect?v=1.0&q=$text"

This looks wrong. q= is .. already going to be part of $text when that first line runs. This is what using [::http::formatQuery] does. It will be "q=text user put minus first word" ... then you add q= agan to it within your "set dturl" line. Why? Google has a very forgiving API if it works like that.

There is nothing wrong as far as that users error goes. [::http::formatQuery] .. or simply [http::formatQuery] should both work exactly the same and not cause that issue. The problem more than likely is ( I replaced http.tcl (renamed old version) and restarted the entire VM to be completely certain it would not do anything with the http.tcl )

So wait, its an eggdrop running inside a virtual machine? was it compiled on that virtual machine so paths and everything work that way. It won't out of the box, it will fail to load packages (or use the wrong path and the wrong http.tcl) just as your seeing now.

[ujjain]

Well, I'll have a look on this trouble.
I'm using Debian, so it might be hard to reproduce the trouble, but I'll find the solution

Thank you. If you wish to access my CentOS VM, that's no problem.

Code: Select all

set text [::http::formatQuery q [join [lrange [split $text] 1 end]]]
set dturl "http://ajax.googleapis.com/ajax/services/language/detect?v=1.0&q=$text"

This looks wrong. q= is .. already going to be part of $text when that first line runs. This is what using [::http::formatQuery] does. It will be "q=text user put minus first word" ... then you add q= agan to it within your "set dturl" line. Why? Google has a very forgiving API if it works like that.

There is nothing wrong as far as that users error goes. [::http::formatQuery] .. or simply [http::formatQuery] should both work exactly the same and not cause that issue. The problem more than likely is ( I replaced http.tcl (renamed old version) and restarted the entire VM to be completely certain it would not do anything with the http.tcl )

So wait, its an eggdrop running inside a virtual machine? was it compiled on that virtual machine so paths and everything work that way. It won't out of the box, it will fail to load packages (or use the wrong path and the wrong http.tcl) just as your seeing now.

Not sure I understand what you mean regarding the setting of variables, but it works on the Ubuntu desktop.

Code: Select all

[16:38:43] http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&langpair=fr%7cnl&q=Je%20deteste%20de%20la%20fromage.
[16:38:44] responseData {translatedText {Ik haat de kaas.}} responseDetails null responseStatus 200
[16:38:44] http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&langpair=fr%7cnl&q=Je%20deteste%20fromage.
[16:38:44] responseData {translatedText {Ik haat kaas.}} responseDetails null responseStatus 200
[16:38:44] http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&langpair=fr%7cnl&q=J%c2%b4aime%20bien%20fromage.
[16:38:44] responseData {translatedText {Ik hou van kaas.}} responseDetails null responseStatus 200

Eggdrop has been installed on both a CentOS- and Ubuntu-VM and compiling went perfectly fine. Installing Eggdrop on a physical machine or virtual machine should make no difference.

[speechles]

@CrazyCat ... Why is this line there at all:

Code: Select all

set lngs { "fr" "en" "es" "de" "it" "nl" "tr" } 

Your Google translate script converts between a massive 7 language pairs? Wow, very not impressed at all. To add languages people need to constantly tamper with that variable.. Why?

The Google translate script I have which is part of Incith:Google doesn't limit you, want to translate Serbian to Japanese it will.

# auto detect serbian to japanese
!tr @ja <serbian text goes here>

# auto detect japanese back to serbian
!tr @sr <the japanese text given back in response above>

# force chinese detection and return japanese
!tr zh-cn@ja <chinese text here>

# force french detection and return default english reply
!tr fr@ <french text here>

# auto-detect and return default english reply
# fully auto, no languages required.
!tr <any language at all goes here>

Google will auto-detect you've used Serbian and convert it properly to Japanese. There is no limit to the languages you can use in mine as evidenced above. If Google supports it, you will be given the translation. If Google doesn't support it _yet_, you will be given that message. If it isn't a valid language, you will get back your original text. Yours doesn't work like this and limits itself for no reason. You should check out of the translate portion of the Google script and COPY the way I do it exactly. Otherwise, your script will always be inferior even though it should be superior using the API rather than web-scraping.

[ujjain]

There is no language limitation in place. I changed the comparization in source code to -10, effectively killing the language limit:

Code: Select all

if { [lsearch $::gTranslator::lngs $lngto] == -10 } { 

This effectively ends any relevance of lngs. I will rewrite the entire TCL-script when I have time, but it works perfectly fine as lngs is no longer used. I am aware I can remove both set lngs... including the entire if-statement.

I have been looking for 2 weeks for a way to get the tcl-script working on the eggdrop installed on the CentOS-VM. Do you have any idea's how to achieve this?

[speechles]

There is no language limitation in place. I changed the comparization in source code to -10, effectively killing the language limit:

Code: Select all

if { [lsearch $::gTranslator::lngs $lngto] == -10 } { 

This effectively ends any relevance of lngs. I will rewrite the entire TCL-script when I have time, but it works perfectly fine as lngs is no longer used. I am aware I can remove both set lngs... including the entire if-statement.

I have been looking for 2 weeks for a way to get the tcl-script working on the eggdrop installed on the CentOS-VM. Do you have any idea's how to achieve this?

Not to hi-jack this thead, but at the moment this script has the functionality your looking for and works if patched for utf-8 support both input and output. Uses the same !tr trigger as well. It is a full featured script with functionality far beyond translations. Some features presently are broken, this is due to the nature of it being based on html rather than api. These will be fixed eventually, but the core functions are solid themselves it's merely the parsers that break.

Now about this script, it has potential easily to rival my mere scraping attempt as it uses pure API. It will not require maintenance for parsing as it is fed a json reply which can be easily machine read. My html parsing version its meant to be read by humans, and it's context and style will change as humans evolve. So my script will break over time. But for the moment, see if perhaps it works for you. It may not, it will likely suffer same error. It may not, can't know without trying. Hopefully CrazyCat evolves this script into something closely resembling mine, but with the added benefit of the API wrapping.

[ujjain]

You might have a point, although it might take me much time to scrap the other features from that script. I have another script that does almost all Google functions, but it is was used spamishly in our language channel. Our channel is about learning languages and I prefer a bot with little functionality, Google Translate. Converting the syntax from !tr fr|to text might also be hard to do for me.

The current script is working fine and as long as there are no security issues, I am fine with the functionality. Replacing the translate-script by a fully functional Google script is not an option, we have a language channel with 50 users and having them use locate, wikipedia, whois, news functions in our channel will reduce the quality of our channel.

I appreciate your suggestion and will consider taking the translate part of that script as it might work.

[CrazyCat]

@speechies: I know my tcl isn't efficient, it was just an exercice to use the Google Translate API, and I didn't work alot about the language detection / translation.

BTW, I think I'll do a wonderfull version soon Ok, let's say a better one

[ujjain]

@speechies: I know my tcl isn't efficient, it was just an exercice to use the Google Translate API, and I didn't work alot about the language detection / translation.

BTW, I think I'll do a wonderfull version soon Ok, let's say a better one

Do you have any idea how I can solve the Tcl error?

[rayvtirx]

i get this error
Tcl error [gTranslator::translate]: can't find package dict
any ideas?

[CrazyCat]

You need tcl 8.5.

[rayvtirx]

ok got tcl 8.5
now getting
Tcl error [gTranslator::translate]: Illegal characters in URL path