...

View Full Version : Developing a triple iframe rolling refresh, inc. on change of state



Ace.....
11-06-2012, 06:49 PM
3 iframes in a container page.
It should be simple to refresh iframe2 from iframe1 etc.

I've spent hours on this........ I must be doing something stupidly wrong. :(
None of my reload scripts will fire.

Here is the containing page:


<body><div id="container1">
<iframe name="iframe1" id="iframe1" src="iframe-1.html" width="32%" height="100%"></iframe>
<iframe name="iframe2" id="iframe2" src="iframe-2.html" width="32%" height="100%"></iframe>
<iframe name="iframe3" id="iframe3" src="iframe-3.html" width="32%" height="100%"></iframe>
</div></body>

Everything seems okay with it.
The css provides me with full size iframes:


#container1 {
overflow: visible;
text-align: left;
top: 0px;
width: 100%;
position: absolute;
height: 100%;
font-weight: normal;
font-family: Arial,Helvetica,sans-serif;
font-size: 100%;
}

Here is iFrame1 script with the different attempts to reload iframe2:


function reload_page_2()
{
parent.getElementById("iframe2").contentWindow.location.reload(true)();

//if (parent.frames.iframe2) {parent.frames.iframe2.location.reload();}

//var f = parent.getElementById('iframe2');
//f.contentWindow.location.reload(true);
}

function store_pg_1()
{var pg_1 = document.getElementById("styled").value;
localStorage.pg_1_text=pg_1;
reload_page_2();}

store_page_1 works perfectly (onClick the textarea value is stored), but iframe2 does not reload via the script.

Can anybody see what I'm doing wrong?

Logic Ali
11-06-2012, 07:45 PM
I've spent hours on this........ I must be doing something stupidly wrong. :(

Yes - developing a script without using the error console

Ace.....
11-07-2012, 09:34 AM
Yes - developing a script without using the error console

Wow!
I didn't even know it existed.
Thank you for that response. :thumbsup:

Ace.....
11-07-2012, 03:53 PM
I fixed the loading problem (I was missing .window):

Below are the scripts that should enable:

text to be entered in iframe1
onclick localStored
auto-reload iframe2
retreive and display text
auto-translation occurs
delayed storage of translated text (to allow time for translation)
auto-reload iframe3
retrieve and display translated text.


BTW it doesn't fully work, as I believe the delay is not truly a delay to the script:


function store_pg_1()
{var pg_1 = document.getElementById("styled").value;
localStorage.pg_1_text=pg_1;
reload_page_2();}

function reload_page_2()
{parent.window.frames['iframe2'].location.reload();
setTimeout(function() {store_pg_2();},5000);}

function store_pg_2()
{var text = document.body.innerText;
localStorage.pg_2_text=text;
reload_page_3();}

function reload_page_3()
{parent.window.frames['iframe3'].location.reload(); }

I now need a way to pause the script.
At the moment the storage of pg_2_text is prior to translation.
(I can confirm this with an onClick to reload iframe3, which then retreives the translation).

Progress though. :)

Ace.....
11-07-2012, 05:10 PM
To get around the the need to pause the script until the translation is complete I tried the code below, but it was a fail:


function reload_page_2()
{parent.window.frames['iframe2'].location.reload();
if(document.loaded) {store_pg_2();} else {
if (window.addEventListener) {window.addEventListener('load', store_pg_2(), false);} else {window.attachEvent('onload', store_pg_2());}}
}

I think the document is already loaded.
Maybe it starts to re-load, but maybe not.
Google is just writing in the translation maybe.

Does anybody have any ideas on how to pause the script until the translation is complete?

xelawho
11-07-2012, 05:40 PM
it sounds like you would probably use a callback

Ace.....
11-07-2012, 08:47 PM
it sounds like you would probably use a callback

I've had a look around re: callback.
It seems that you need to understand (first) what is actually happening.

In reality, I don't know what event is occurring & ending.

Obviously I know that my text has been sent to google, and that it is returning (modified).

Clearly a change of state is: triggered - not finished - finished.

But worse than that.... the page first loads fully ie. one state complete; and then there is a pause while the text is sent to google (ie. the first state is still stable). Then the returned translated text is written in.

If we know what the final state is, then we might compare it to the the 1st state - which is page loaded and original text written in (if any, cos iframe2 is originally empty, but it will gradually acquire text, as it is typed into iframe1).

What we can be certain of, is that the 2nd completed state, is going to be different to the 1st completed state.

Perhaps it's possible to monitor the sending to google of the original text.
Ie. English arrives in iframe2. It is then sent, or called, to google.
This 'data transmission' might then allow the 1st state to be logged.

The 2nd state (different) could be compared to the 1st, but can we determine, when the return text has fully arrived?

I think once we understand how javascript can recognise these events, then the appropriate function can be fired.

Does anybody understand these events?

xelawho
11-07-2012, 08:58 PM
but can we determine, when the return text has fully arrived?
that would be where your callback would come into it. How are you sending the text to be translated? Maybe you can post some more code, or a link?

Ace.....
11-08-2012, 12:49 PM
that would be where your callback would come into it. How are you sending the text to be translated? Maybe you can post some more code, or a link?

1. Launch command (iframe container page):

#googtrans(en|fr)


This anchor doesn't exist on iframe_2.html, however this is the 1st command to tell the browser to send the whole dom to google, once the page has fully loaded (this I assume from logic).

It tells google to expect it in English, and to Return it in French.


<iframe name="iframe2" src="iframe_2.html#googtrans(en|fr)">

2. The Header code (on page requiring translation - iframe2)


<meta name="google-translate-customization" content="f3ec1860041f93e1-f800c17a206199a4-g305246f186c2820d-15">


The above is part one of two sections of code.
The numbers I presume identify my site, and translation preferences, gleaned from my responses to their form.

3. The Body code (on page requiring translation - iframe2)


<div id="google_translate_element"></div>
<script type="text/javascript">
function googleTranslateElementInit()
{
new google.translate.TranslateElement({pageLanguage: 'fr', includedLanguages: 'en', layout: google.translate.TranslateElement.InlineLayout.SIMPLE, autoDisplay: false}, 'google_translate_element');
}
</script>
<script type="text/javascript" src="//translate.google.com/translate_a/element.js?cb=googleTranslateElementInit"></script>

What do we know about the above:


pageLanguage: 'fr',

The language of your web site, presumably speeds up the process, so it can offer a visitor french to chinese translation on the fly.

includedLanguages: 'en',

These are the languages that appear in a drop box, so you can choose your language.

layout: google.translate.TranslateElement.InlineLayout.SIMPLE, autoDisplay: false

This is the style of the drop box.


The Links:

http://translate.google.com/

Then click the link

http://www.google.com/url?source=transpromo&rs=rsmf&q=http://translate.google.com/manager/website/%3Fhl%3Den


I'm gonna look for the chrome console log, as it is jam packed with info on what is going on.

Ace.....
11-08-2012, 03:54 PM
I have run chrome with logging enabled.

To keep the log pure to the task, I set the launch page to

http://www.max-haut-debit.fr/translator/translator_page.html

I had already blanked the local storage cache for iframe2 & iframe3 by passing the empty textarea thru localstorage to iframe2 which passed it on to iframe3


As a result, this is what the log shows (I deleted the old logs):

Step 1
Therefore as chrome loaded: iframe2 & 3 loaded, and their scripts fired with almost no data.

Step 2
I pasted some english text using ctr+v into textarea.
onClicked the text.
The text was localstored
iframe2 reloaded, retrieving the text, and displaying it in english.
The text was then sent to google.
It was returned in French, and displayed.

Step 3
Step 3 already started probably milliseconds after onclicking the text.
iframe3 had reloaded retrieving the blank local storage.


This is the problem area, pausing the rolling reload, until translate has done its biz

Step 4
I onclicked iframe2, causing the translated text to go to localstorage.
iframe3 reloaded, retrieving the French text.
The text was sent to google.
It was returned in English, and displayed.

Step 5
I quit chrome, and copied the log to temp.
I copied the log to pastebin.

This log should only contain the tasks described above:

http://pastebin.com/016QNsSz

xelawho
11-08-2012, 06:39 PM
I am wondering about the need for local storage here, which has growing support but not below IE8. Also your interface is a little unintuitive - you can pass the value of the textarea to the iframe onkeyup and do it that way. Here's one way, anyway. Main page:



<html>
<head>
</head>
<body>
<textarea name="styled" id="styled" onkeyup="translateIt(this.value)"></textarea>
<iframe name="theframe" width="500" src="translated.html"> </iframe>
<script type="text/javascript">
function translateIt(text) {
parent.frames['theframe'].googleTranslateElementInit(text);
}
</script>
</body>
</html>


iframe page:


<html>
<head>
<meta name="google-translate-customization" content="f3ec1860041f93e1-f800c17a206199a4-g305246f186c2820d-15"></meta>
<script type="text/javascript" src="//translate.google.com/translate_a/element.js"></script>
</head>
<body>
<div id="google_translate_element"></div>
<div id="thetext"></div>
<script type="text/javascript">
function googleTranslateElementInit(txt) {
document.getElementById("thetext").innerHTML=txt;
new google.translate.TranslateElement({pageLanguage: 'en', includedLanguages:'fr',layout: google.translate.TranslateElement.InlineLayout.SIMPLE, autoDisplay: false}, 'google_translate_element');
}
</script>
</body>
</html>

Ace.....
11-08-2012, 07:51 PM
I am wondering about the need for local storage here, which has growing support but not below IE8. Also your interface is a little unintuitive - you can pass the value of the textarea to the iframe onkeyup and do it that way.


Yes, you are absolutely right.
I used onclick purely so that I could control events.

The system is primarily set up as a test bed for the scripting.

My idea was ultimately to use the 'Enter' key, to act on the finalisation of a paragraph: Type a paragraph - have a look (how did it turn out) continue, or have another go.

Onkeyup may be more akin to the google translate page, where characters are sent individually, building a paragraph that is ultimately translated.

But either way, the thinking was that, the final processes would inform the final design.

Re your suggested code..... it looks like you have discerned the key commands. :)

I was working with what was auto-available (from ignorance of the detail).

This enlightenment, means I need to spend a bit more time understanding what is happening - but at least I know now, where to look. :)

The log file has proved definitely to be good educational material, even for the uninitiated (who are prepared to go thru each line a couple of times).

Thanks very much for your interest in this project. :)

.

xelawho
11-08-2012, 08:07 PM
yes. there is a problem though - there doesn't seem to be a way to auto select the language - and therefore have an automatic translation - on first page load (if you have done this already you would have to clear your cache to see what I am talking about). You would think that the autoDisplay parameter might do something, but from what I can tell setting it to true, false or even removing it completely seems to have no effect at all :confused:

Ace.....
11-09-2012, 02:25 PM
The good news is that the system now only requires the removal of one "onClick" event handler.
more on that later.


there doesn't seem to be a way to auto select the language - and therefore have an automatic translation - on first page load (if you have done this already you would have to clear your cache to see what I am talking about).

On the above, I noted that your code did not use the anchor link

<iframe name="theframe" width="500" src="translated.html#googtrans(en|fr)"> </iframe>

It's purpose is to auto-select the 'from & 'to' languages.
With this added & using google chrome, I have seen no problems.
I cleared the cache, but the scripts & display functioned as expected.
For no other reason that this, I believe the anchor link must solve this problem.



You would think that the autoDisplay parameter might do something, but from what I can tell setting it to true, false or even removing it completely seems to have no effect at all :confused:

This looks as though it is driven by whether: the text SHOULD be translated, or whether it HAS been translated.

Once translated, it must be displayed. Based upon an understandable philosophy that is effectively: "Be aware, this data has been modified".
Therefore the question is only whether it is always displayed, when say a French browser, visits English pages.

As we are translating, it will always display.

xelawho
11-09-2012, 03:05 PM
ah, I get it now. thanks for explaining.

can I ask what the purpose of the other iframe is? it seems to want to translate to English? But if the input language is English what is the idea? and why not fire the function on the onkeyup of the textarea the way you do with the first iframe?

also, this is going to cause you problems:

<body onhaschange="translateIt(document.body.innerText)">

there is, sadly, I believe, no body onhaschange event, and the equivalent is hard to implement in a cross-browser fashion.

innerText will get you into trouble, too. innerText is IE only. textContent is more widely accepted, but IE only started recognising it at IE9+

if you are only looking to translate the text from the textarea, it is much easier just to be getting the value of that textarea, the same as you are doing now.

Ace.....
11-09-2012, 03:16 PM
The good news is that the system now only requires the removal of one "onClick" event handler.


Hang on.... I'll answer your last post with another.

The onkeyup code is working very well, in transferring the text to its designated division (then onward to google and therefore returning translated to the same designated area). :)

The problem now is: how to pass the translated text back to google?

The requirement being; that the user should only be interested in typing the text.
The onkeyup deals with that perfectly, for the first translation.

What is needed is a way to fire a script, when the translation has arrived.
I'm doing this with onclick, just to prove that everything is working fine.
And it is. :thumbsup:

As an alternative I note lines 173 to 176 ( http://pastebin.com/016QNsSz )


[3726:3754:5520733244:VERBOSE1:resource_loader.cc(293)] OnResponseStarted: http://translate.google.com/translate_a/element.js?cb=googleTranslateElementInit
[3726:3754:5520734105:VERBOSE1:resource_loader.cc(320)] OnReadCompleted: "http://translate.google.com/translate_a/element.js?cb=googleTranslateElementInit" bytes_read = 1477
[3726:3754:5520734658:VERBOSE1:resource_loader.cc(320)] OnReadCompleted: "http://translate.google.com/translate_a/element.js?cb=googleTranslateElementInit" bytes_read = 0
[3726:3754:5520734707:VERBOSE1:resource_loader.cc(543)] ResponseCompleted: http://translate.google.com/translate_a/element.js?cb=googleTranslateElementInit

Could "ResponseCompleted" be the code element that could fire the script to pass the translated text back to google?

Here is how I'm doing it, just to prove the text can be re-translated and passed into a 2nd iframe:


<div id="google_translate_element"></div>
<div id="thetext" onClick="translateIt(document.body.innerText)"></div>

<script type="text/javascript">
function translateIt(text) { parent.window.frames['theframe2'].googleTranslateElementInit(text); }
</script>

I guess I can be a bit more accurate with the text value, but as it stands, with a click on the text, the 2nd translation occurs. :)

Ace.....
11-09-2012, 03:54 PM
can I ask what the purpose of the other iframe is? it seems to want to translate to English? But if the input language is English what is the idea? and why not fire the function on the onkeyup of the textarea the way you do with the first iframe?

The idea is simply to gain feedback.
Google doesn't translate textarea content, hence why we must first send it to be written in to the page, in order for it to be read.



also, this is going to cause you problems:

<body onhaschange="translateIt(document.body.innerText)">

there is, sadly, I believe, no body onhaschange event, and the equivalent is hard to implement in a cross-browser fashion.


Yes, I should have deleted that..... I was merely floundering around looking to see if there was an event handler that would work..... and there were none. :(



innerText will get you into trouble, too. innerText is IE only. textContent is more widely accepted, but IE only started recognising it at IE9+

if you are only looking to translate the text from the textarea, it is much easier just to be getting the value of that textarea, the same as you are doing now.

All fair comment.
This whole area of standardisation is in a mess, and should have been sorted out some years back (considering the dates of some of the articles I've read, discussing this very issue).

My thinking with this thread, was to focus on establishing the scripts that could pass either the text or dom elements, to and from google.
In effect treating the two problems separately.

On the question of "what to transfer":

Logic Ali produced a very good piece of coding to operate in this area:
http://www.codingforums.com/showpost.php?p=1288306&postcount=6

Here is another interesting behemoth, apparently working across all browsers.
http://clubajax.org/examples/plain-text-vs-textcontent-vs-innertext/

I stopped working on this issue, when I discovered there were problems working with line breaks, as the text moved backwards and forwards.

I figured that once I had a working system in place, I could then experiment with greater ease.

But clearly crossbrowser/generation compatibility is a nightmare, that hopefully can be dealt with, with community assistance coming from:
http://www.codingforums.com/showthread.php?t=280694
:)

Ace.....
11-09-2012, 05:37 PM
Re: Feedback

try this:

1. Stewart Francis - "You know who really gives kids a bad name? Posh and Becks."
2. Tim Vine - "Last night me and my girlfriend watched three DVDs back to back. Luckily I was the one facing the telly. "
3. Will Marsh - "I was raised as an only child, which really annoyed my sister."
4. Rob Beckett - "You know you're working class when your TV is bigger than your book case."
5. Chris Turner - "I'm good friends with 25 letters of the alphabet… I don't know Y."
6. Tim Vine - "I took part in the sun tanning Olympics - I just got Bronze."
7. George Ryegold - "Pornography is often frowned upon, but that's only because I'm concentrating."
8. Stewart Francis - "I saw a documentary on how ships are kept together. Riveting!"
9. Lou Sanders - "I waited an hour for my starter so I complained: 'It's not rocket salad."
10. Nish Kumar - "My mum's so pessimistic, that if there was an Olympics for pessimism… she wouldn't fancy her chances."

Not funny.
(Perhaps they never were to begin with :D )

xelawho
11-09-2012, 05:57 PM
I'm not sure what the gaining of feedback means here.

Is the purpose to send text to google to translate, then send the translated text to google to translate back to the original language so as to compare the original with the twice-translated text?

Ace.....
11-09-2012, 06:20 PM
Yes.
Hence the jokes.

Sure jokes are the worst to translate.
I used them merely as an example.

I put ten in to show that in fact, it wasn't all disaster.

Pretty close.... but pretty close often is just not good enough.

Consider:

We will accept cheques & we will not accept cheques. :eek:

xelawho
11-11-2012, 02:28 PM
as Ali pointed out (I think in the other thread), the most reliable way to do this would be to use the translate API - I note that it does offer a callback function, which lets you know when the translated text has arrived back from google.

the thing you're working with on the other hand is a simple widget and as far as I can tell does not offer the sort of functionality you need here.

but in the meantime, you can use a (fairly) simple workaround - check every half a second (or whatever - you can change the 500 in the code, which refers to miliseconds, although that seems reasonable to me) to see if the text that appears in the "French" iframe is the same as the text that was entered in the textarea. If it has changed (ie, google has sent back its results), send the new text on to the next iframe for translation back to English.

It's not 100%, but seems to work ok most of the time. You might get better results by lengthening the delay, or using a button to fire the functions instead of onkeyup.

main page:


<html>
<head>
</head>
<body>
<textarea name="styled" id="styled" onkeyup="translateIt(this.value)"></textarea>
<iframe name="theframe" width="500" src="translated.html#googtrans(en|fr)"></iframe>
<iframe name="frame2" width="500" src="orig.html#googtrans(fr|en)"></iframe>
<script type="text/javascript">
function translateIt(text) {
var text=text.replace(/\n/g,"<br>")
parent.frames['theframe'].googleTranslateElementInit(text);
}
</script>
</body>
</html>


translated.html:


<html>
<head>
<meta name="google-translate-customization" content="f3ec1860041f93e1-f800c17a206199a4-g305246f186c2820d-15"></meta>
<script type="text/javascript" src="//translate.google.com/translate_a/element.js"></script>
</head>
<body>
<div id="thetext"></div>
<script type="text/javascript">
var thetext;
function googleTranslateElementInit(txt) {
thetext=txt;
document.getElementById("thetext").innerHTML=txt;
new google.translate.TranslateElement({pageLanguage: 'en', includedLanguages:'fr',layout: google.translate.TranslateElement.InlineLayout.HORIZONTAL, autoDisplay: false});
setTimeout(checkIt,500)
}

function checkIt(){
var thediv=document.getElementById("thetext")
res=thediv.innerText?thediv.innerText:thediv.textcontent;
if(thetext!=res){
parent.frames['frame2'].googleTranslateElementInit(thediv.innerHTML);
} else{
setTimeout(checkIt,500)
}
}
</script>
</body>
</html>


orig.html:

<html>
<head>
<meta name="google-translate-customization" content="f3ec1860041f93e1-f800c17a206199a4-g305246f186c2820d-15"></meta>
<script type="text/javascript" src="//translate.google.com/translate_a/element.js"></script>
</head>
<body>
<div id="origtext"></div>
<script type="text/javascript">

function googleTranslateElementInit(txt) {
document.getElementById("origtext").innerHTML=txt;
new google.translate.TranslateElement({pageLanguage: 'fr', includedLanguages:'en',layout: google.translate.TranslateElement.InlineLayout.HORIZONTAL, autoDisplay: false});
}
</script>
</body>
</html>

something else I just noticed is that, while it's reasonably reliable in Chrome and IE, firefox returns "undefined" in the translated-back-to-original frame. Dunno why, and being that my work made me install this stupid extension for firefox that makes firebug unuseable I can't see why that would be, either.

Maybe someone else can take a look.

Ace.....
11-11-2012, 05:25 PM
A working version is now ready.
This should satisfy any doubts over whether reverse translation has become possible in 2012.

Passing French back to English
This was the killer coding problem.

I've solved this with the aid of an open source javascript library for keyboard shortcuts:


http://www.openjs.com/scripts/events/keyboard_shortcuts/
Version : 2.01.B
By Binny V A


I chose Ctrl+shift to trigger the reverse translation, simply because the user can type at will, and when ready, hit the 2 keys that are (I believe) usually bottom left.

Bugs

I experienced one problem, by hitting the shortcut before the text had finished translating.
This stopped the primary translation process.
Everything I typed in English was curiously accurate.
I then discovered that I was simply moving English from page 1 to 2 to 3.

This bug has never appeared again.
I reloaded the page and it worked perfectly thereafter.

Edit Note: This may be to do with the fact that by pressing Ctrl+shift this also creates an onkeyup event.
When I used onclick, the translated text simply transferred to the right frame.
Now the shortcut resends the english text for translation, at the same time as it trys to transfer the translated text.

That is the cause of the bug, so the instructions below don't help.
A fix is required.

To get around this, in the instructions I recommend checking what you have typed, before translating it back to English. (In real life, you would first check what you'd written)

Yes.......... I know it is not perfect. :(

Perfect would be to automatically pass the French, after translation.
But....... as a test bed; this is pretty good (and maybe a solution will present itself). In the meantime, other problems might arise from usage.

Anyway, here it is: (http://www.max-haut-debit.fr/translator/translator_page.html)
You'll see there are some valuable instructions with it, based on my experience of translation. :D

Ace.....
11-12-2012, 02:49 PM
I updated the the two problem files around 14:00GMT.
I had two onclick events, one being correct, the other incorrect.

It now appears quite stable, with all the logged errors/warnings originating from the google code (as listed below).

Having now coded the mouse click over the textarea to update the reverse translation....... it seems quite fluid.

Yes.... it is still possible to interrupt the initial translation, however, having tidied the code, the translation now simply picks up when new text is entered.

There can be temporary hanging (for a few seconds), but this may well be the fault of the network or at google end.
No warnings appeared when this happened, and the translation just started again.

Overall, this afternoons version is better than yesterday afternoons! :D

Warnings relating to google code:


[15:10:04.275] Unknown property '-moz-box-shadow'. Declaration dropped. @ http://translate.googleapis.com/translate_static/css/translateelement.css:2
[15:10:04.275] Unknown property 'zoom'. Declaration dropped. @ http://translate.googleapis.com/translate_static/css/translateelement.css:2
[15:10:04.275] Expected declaration but found '*'. Skipped to next declaration. @ http://translate.googleapis.com/translate_static/css/translateelement.css:2
[15:10:04.277] Error in parsing value for 'display'. Declaration dropped. @ http://translate.googleapis.com/translate_static/css/translateelement.css:2
[15:10:04.277] Unknown property '-moz-border-radius'. Declaration dropped. @ http://translate.googleapis.com/translate_static/css/translateelement.css:2
[15:10:04.278] Error in parsing value for 'background'. Declaration dropped. @ http://translate.googleapis.com/translate_static/css/translateelement.css:2
[15:10:04.278] Error in parsing value for 'filter'. Declaration dropped. @ http://translate.googleapis.com/translate_static/css/translateelement.css:2
[15:10:04.279] Expected color but found 'top'. Error in parsing value for 'background'. Declaration dropped. @ http://translate.googleapis.com/translate_static/css/translateelement.css:2
[15:10:04.279] Error in parsing value for 'background-image'. Declaration dropped. @ http://translate.googleapis.com/translate_static/css/translateelement.css:2
[15:10:04.280] Expected color but found 'top'. Error in parsing value for 'background-image'. Declaration dropped. @ http://translate.googleapis.com/translate_static/css/translateelement.css:2
[15:10:04.281] Unknown pseudo-class or pseudo-element 'null'. Ruleset ignored due to bad selector. @ http://translate.googleapis.com/translate_static/css/translateelement.css:2
[15:10:04.282] Unknown property 'box-sizing'. Declaration dropped. @ http://translate.googleapis.com/translate_static/css/translateelement.css:2
[15:12:16.659] Use of attributes' nodeValue attribute is deprecated. Use value instead. @ http://translate.googleapis.com/translate_static/js/element/10/element_main.js:300

Ace.....
11-12-2012, 06:16 PM
Since adding the doc & character declarations, and tidying some of the unacceptable declarations and comment marks......

..... it all seems fine now, in the big 3. :)

I don't know whether it's to do with the network, or whether it's down to the improvements made to the coding (probably the latter) - but everything is running much faster now.
So fast in fact that, whilst typing, it is hard to click the mouse fast enough to interrupt the primary translation.
I had to paste in text and click, to mimic this scenario.

As it happens, there seems to be no problem.
If the translation is interrupted (and English is displayed), by simply recommencing the typing, the translation continues.

Having said that...... I'm game to try to fully automate the system (eliminate the mouse click).
I just don't know where to start.

Does anybody have any pointers? :)

xelawho
11-12-2012, 06:31 PM
did you try with the method described in post 21, above?

Ace.....
11-13-2012, 01:20 AM
did you try with the method described in post 21, above?

I don't know why; I don't know how...... but sometimes fate deals a good hand. :eek:


( it's rare though ;) )

I actually missed that post (see first remark)...... I guess it was meant to be like that.

After the weekend's work, and Sunday, sort of stupidly releasing a working version (in the heat of the moment). Today saw good housekeeping, leading to 'covering the fundamentals': getting all the declarations right (when a release would have been correct).

There's only a break-line that Chrome doesn't like (actually W3c).

Oh, while I remember re W3c: onhaschange does exist. It's part of a whole new raft of event handlers in HTML5 (what a bugger eh? :) )

Either way.... I didn't manage to use it correctly. :o
http://www.w3.org/TR/2009/WD-html5-20090212/browsers.html#window

But leaving all that aside, this really IS the ideal point to move to the next phase.
This morning would have been too early.
Definitely a lesson to be learned there IMHO.

Tomorrow, may well see full automation. :D

(Thanks for the direction.) :thumbsup:

Ace.....
11-13-2012, 06:28 PM
something else I just noticed is that, while it's reasonably reliable in Chrome and IE, firefox returns "undefined" in the translated-back-to-original frame. Dunno why, and being that my work made me install this stupid extension for firefox that makes firebug unuseable I can't see why that would be, either.

Maybe someone else can take a look.

Yes you were right to flag this up.

The sys is simply not working in FFox.
It is the English text that is being transferred, rather than the French.


Note: you can confirm this by hovering the mouse cursor over the supposed reverse translated text.
The dialogue box should show the French source.
However, it shows English as the source.

Further; FFox console doesn't flag up any errors.

Chrome does seem reliable.
I did have problems, but I believe that was due to the fact that I had not fully stripped out my own code for focus, onclick, and Ctrl+shift.

Also, when I first tried it; it was without the:

var text=text.replace(/\n/g,"<br>")
It worked fine.

When I introduced the variable, it created problems.

I removed it, and Chrome was stable once again.
This made no difference to FFox.

Conclusion (theory)
FFox is happy with the new automation code.
But, the "if comparators" are reading the fr/en variables differently
OR
the variables are being streamed differently.
OR
'thetext' does NOT equal 'res' the moment new English text arrives.
Therefore the English is sent (rather than the French).

When English is typed, it appears in the Fr2En frame as English.
It is written in, when the previous state of the frame was French.
Ie. Could it be functioning back to front sending the wrong 'different' text.

Well, we are certain that it is sending the wrong text.
At least it's a start. :)


function checkIt(){
var thediv=document.getElementById("thetext")
res=thediv.innerText?thediv.innerText:thediv.textcontent;
if(thetext!=res){
parent.frames['theframe2'].googleTranslateElementInit(thediv.innerHTML);
} else{
setTimeout(checkIt,500)
}
}

xelawho
11-13-2012, 07:19 PM
it seems to work ok for me. I put one of your jokes into your page using Firefox:
You know you're working class when your TV is bigger than your book case

the French version comes out
Vous savez que vous êtes de la classe ouvrière lorsque votre téléviseur est plus grand que votre caisse de livre

the translated back to English version shows
You know you're working class When your TV is bigger than your book box

(note that the W has been capitalized and "case" has been changed to "box")

so obviously it's not just transferring the English straight across. Caching issues, maybe?

Ace.....
11-13-2012, 08:03 PM
Be careful to hover the cursor over the reverse translated text.

It seems VERY wierd.

But what in fact is happening, is that the English source text is being converted to English.
This produces a re-translation that makes a minor change..... but that is only going to make you think that it has been translated.

Try typing this in Chrome & then in FFox:


"Olivia is sad that she had a problem with her braces."

You should get in Chrome:
Orig English: Olivia is sad that she had a problem with her braces.
French: Olivia est triste qu'elle avait un problème avec son appareil.
Reverse English: Olivia is sad she had a problem with his camera.

Hover over the French and you will see the original text.
Hover over the reverse English and you will see the French text.

In FFox:
Orig English: Olivia is sad that she had a problem with her braces.
French: Olivia est triste qu'elle avait un problème avec son appareil.
Reverse English: Olivia is sad that she had a problem with her braces.

Note: FFox struggles to display the dialogue box.
Change tab, then return, and then hover.
You will see that the reverse English is merely the original English.

And anyway we know that google translate (with this sentence structure) translates 'braces' as 'camera'.

You can prove this by clicking this link (containing the text).standard google translate page (http://translate.google.co.uk/#fr/en/Olivia%20est%20triste%20qu'elle%20avait%20un%20probl%C3%A8me%20avec%20son%20appareil.).... it translates it as camera.

Presuming you see the same results; this will confirm that the sys is failing in FFox as previously described.

xelawho
11-13-2012, 08:33 PM
oh, dear :o

this line

res=thediv.innerText?thediv.innerText:thediv.textcontent;

should be:

res=thediv.innerText?thediv.innerText:thediv.textContent;

change that, and Olivia gets sad about her camera in FF, too

:thumbsup:

Ace.....
11-13-2012, 08:40 PM
oh, dear :o

this line

res=thediv.innerText?thediv.innerText:thediv.textcontent;

should be:

res=thediv.innerText?thediv.innerText:thediv.textContent;

change that, and Olivia gets sad about her camera in FF, too

:thumbsup:
I think a copy/paste error cos the two lines are the same:

res=thediv.innerText?thediv.innerText:thediv.textcontent;
res=thediv.innerText?thediv.innerText:thediv.textContent;

But I'm looking forward to seeing the change cos it did work in chrome. :confused:

xelawho
11-13-2012, 08:48 PM
no - the second line has a capital c for content:

res=thediv.innerText?thediv.innerText:thediv.textContent;

Ace.....
11-13-2012, 11:52 PM
Yes, that did it. :thumbsup:

I'll run some more tests on it. :)

Ace.....
11-14-2012, 04:15 PM
For some reason, the auto transfer is not reliable.
I have periods when it is going really well, then suddenly the final reverse translation fails, and I'm looking at the original English text.

Then... sometimes you can clear this, by hitting a key, while other times, only some of the text changes.
Ie. partial reverse translation, partial original text.

I've tried decreasing and increasing checkit speed 5 to 2000.

I'm wondering whether the dual translation cannot work together.
Ie As English is typed, it is being translated to French, but at the same time, there is French being translated to English.

If that is the case, then the onclick to reverse translate, might be the only solution (or some other user triggered eventhandler).

?

AndrewGSW
11-14-2012, 04:32 PM
I haven't looked at this in detail but you could try causing an (artificial) delay between setting the innerHTML and translating - or push the translation into the existing (or another) timeout. That is, allowing the DOM to be fully updated before attempting the translation.

Ace.....
11-15-2012, 01:27 AM
I haven't looked at this in detail but you could try causing an (artificial) delay between setting the innerHTML and translating - or push the translation into the existing (or another) timeout. That is, allowing the DOM to be fully updated before attempting the translation.

This concept does make sense (if I understand it correctly).
I believe you're suggesting: that an interruption should be inserted.

That interruption could be implemented, by simply ceasing to enter original source text, or by an automated procedure.

This our current thinking.
However....... I've got new information, that must cause us to re-examine the problem.
It's a bit Whacko Jacko...... but all the better for it..... cos we're gonna enter the world of Artificial Intelligence. :eek:


Please come with me....... you really need to be in the zone with this one AND this understanding does lead to an underlying normal In/Out programming scenario.

Part 1.

We understand:
Write English in frame1- English appears in frame2 - English in frame2 turns to French - French copies to frame3 - French turns to English.

How this happens:
The English text appears in frame2, either slowly, or quickly (according to our speed of typing).
If I type at a certain pace, no translation occurs, until I pause.

When I pause it ALL turns to French; until I start typing again, then it ALL turns to English.

Or at least; that's how we view it.
But not at detail level.

Type 'one two'
Do it slowly, and watch the French build.

There is ambiguity at the beginning 'on' ='sur' ('on the bridge'/'sur le pont').

But after that, 'one' = un, (one***** no words) ____ two = deux (two**** no words)_____ th***** (th could make lots of words, but we can see it's AI in operation cos it thinks[?] it could be twoth, threeth, fourth, fifth, sixth.)

So it finally can re-translate, and it changes deux to deux ème (2nd or twoth) - a bit like a child that is following some basic rules.


(Like a French 'English teacher' that taught a young girl I knew: ten, eleventeen, twelveteen, thirteen........ [no wonder the French can't speak good English] - true story BTW)

Remember, we have now (in English typing) one two th = un deux ème
We add an 'r'.... one two thr
This could be anything........ it waits........ no...... okay, I refuse to translate 'thr'.... BUT I will translate one two.

So the French returns from un deux ème to un deux thr (the last three letters remain un-translated).

I add an 'e'.
The French returns to English(!!): one two thre

At this point, its poor child-like brain has just decided it can't continue without more information.

It sits there unmoved by the passage of time, in English, 'one two thre' (why not 'un deux thre'?....... I guess we'll never know why)

I finally add an 'e'____ making 'one two three'.

The very moment the final 'e' arrives BANG - it translates to: un deux trois.

Okay..... so you think you understand it now.
Google translate is either a smooth skinned creature with a big head and tear-drop eyes, that only understands language thru rules, OR it's a French English Teacher :D

But.... just to re-enforce the concept that we cannot pre-judge how it's thinking, we can look at how it deals with adding 'fourteen' to the line of text.

We have:
one two three = un deux trois
one two three f = un deux trois f
one two three fo = un deux trois fo
one two three fou = un deux trois fou
one two three four = un deux trois quatre (well done)
one two three fourt = un deux trois Fourt

Here we've confused the poor little sod.
It was expecting four, and now it has to think of something, so it's guessed it MUST be a name, so it's stuck a capital on it.
But we also must realise that it has now 'stuck' with one two three = un deux trois (that's important cos I think what it has stuck with is now cached).

one two three fourte = un deux trois Fourte
one two three fourtee = un deux trois fourtee

It's dropped the capital, and is probably gambling with it's mates on it being fourteen.

one two three fourteen = un deux trois quatorze (immediately correct)

Part 2.


(Okay.... we're nearly there, to our programming question:)

We have discerned that a rule based intelligence is at work, and that it looks likely, that once it is satisfied with a section of translation.... it doesn't waste any more processing power on it.

This is how we would do it.
If we translated four paragraphs, and we were given a fifth.... we wouldn't start re-translating from the beginning.

This is important, because in testing we saw entire sections; of the supposed reverse translated English; all in original English.
Yet, the French translation was sat there, perfect in every detail.
Hit a key in the text area, and all that lovely French should have been transferred for reverse translation back into English.

I'm looking at an example now: A page of text typed in English, a page of translated text in French, and a reverse translation page that consists of sentences translated from French and sentences of pure original English.

When I hit a key..... the entire page of French changes to English immediately (I mean immediately), and then back to French (taking a bit longer), yet the reverse translation chooses different paragraphs to refresh.

Every time I hit a key, I watch different paragraphs refreshing, While the pure English doesn't change at all (perhaps the big clue).

Let's link this in with the one two three that it was happy with (un deux trois).

Could it be that there is another way of dealing with textContent/innerHTML?
One that uses a cache.
One that tricks our code and our eyes.

We see with our own eyes, the entire page of French, turning to English, and turning back to French.

But we don't realise that in fact, even though the whole page is apparently being refreshed, in truth, it is only certain paragraphs that are being processed..... and it is only these paragraphs that our code sees.

The rest of the French is what we could call an illusion.
For our code, it doesn't exist.
In its place, our code sees the original English

Our code sees:
The French that is still being processed (every time I hit a key)
The underlying English that forms the basis for the French overlay on the screen.

We only see all French, or all English.

We would never have discovered this fact or at least had it confirmed, if we didn't have the reverse translation to look at.

The reverse translation can't hide.
The fixed underlying English has been passed back and doesn't change.
Only the paragraphs still being processed, flip between French and English.

Conclusion

There are two text sources, and our code is reading the wrong one.

Our code needs to read the page of French that our eyes see.
If it read the French that our eyes see, it could not transfer English to the other frame.

:)

Ace.....
11-15-2012, 11:40 AM
Continuing on from the previous post.

I think I understand the solution, and partially understand the problem

The French translation is linked to the original English.

Those references allow us to hover over translated text, and see the original sentence displayed in the dialogue box.

When we copy the French translation, and paste it for reverse translation.....
..... we are not copying only the French text, we are also copying it's references to the original text.
AND apparently we end up sometimes copying the original text, rather than the translated text.

Therefore, we need to copy the translated text, like as if we had highlighted it........ and paste it, like as if we pasted a copied web page into a text editor.

Effectively a fresh start, without any references to other text.

That's the solution.
It seems logical, and obviously works when pasting the text in a Fr2En version of the sys.

The question is, how to do it?

I'll perhaps revisit the innerText/textContent elements.

Also I'll rebuild my sys that used onClick, to fully test AndrewGSW suggestion that by pausing the processing, we might be able to copy the displayed French every time.

:)

Ace.....
11-15-2012, 02:37 PM
I have re-instated the onclick to transfer the French text for re translation.
The original text is transferred onkeyup for translation to French.

This pausing does seem to have solved the problem.

Once the text has been translated to French, I can transfer it to frame3.
It appears in frame3 and is translated back into English almost instantly.

At the moment I have a problem with the translation into French..... it is extremely slow.
I rebooted, but nothing changed and anyway, the reverse translation is almost instant.

I'm gonna check the code again.

But what does seem clear, is that the system struggles to simultaneously translate English to French & French back into English; at least, in the way it was coded.

Ace.....
11-15-2012, 03:20 PM
The problem is associated with non-character keys!

I have a page of original English text.
The French translation of it.
The reverse translation.

The cursor is at the end of the text.
I decide to edit the document, so I cursor up (instead of using the mouse).
I hit the up arrow 12 times.

The French translation reverts to English, and sits there in English.

I did this a few minutes ago, and it is still in English.
I'll now actually edit the document, adding a comma.

That sorts it.
And I've just tried it with the shift key, and that freezes it as well.

So the only keys that it likes are keys that actually edit the text.

Hmmmm I wonder if this was causing problems in the automated system.
Well it would have been causing problems.

Testing shows that I can do two rapid cursor moves, but not 3.

I wonder if there is a way of recognising that a character has been sent, and then firing the function.

At the moment it is a catch all 'onkeyup'.

Progress :thumbsup:

If this is fixed, I can retry the fully automated version again.

Ace.....
11-15-2012, 04:07 PM
OR

I might try onhaschange for the textarea, though it will only work for the latest browsers I think.
No I was wrong about it..... I misread the damned thing.

I need to monitor the changes to the textarea.
What can do that?

maybe oninput or onpropertychange or both, for IEx.

Ace.....
11-15-2012, 05:00 PM
oninput is definitely better than onkeyup.
It overcomes the issue of firing the translate function when it has not been edited.

I've tried it in the fully automated version.

It works and has eliminated a major problem.
This allows the actual problem to become visible:

It is best reproduced by adding a single comma or full stop to a page of text.

This edit is effected so quickly that the compare function fires and grabs some French text and some English text.

Ie. The English text being in the process of changing to French.

It's a fundamental barrier to timing.

Even if you add a delay; the user can easily have added another character, causing the screen to be in the same mid-state of change (from English2French).

The human eye works + a command.

You see when the text has all changed from English to French, and then you hit the reverse translate key.

How can that simple task be replaced by code?

Ace.....
11-18-2012, 05:44 PM
I believe the problem is associated with javascript memory.

The New Setup
I removed oninput, and replaced it with a shortcut to transfer text for translation.
I re-introduced checkit (4000ms), to confirm translation had taken place, before sending the translated text for reverse translation.

This slowed everything down, allowing for better examination.

I soon discovered that what we thought was happening was not (thanks to chrome console).

Comparing script commands with ACTUAL output :eek:

1st Pass:
I've pasted a largish sized chunk of text for editing (value).


shortcut.add("Ctrl+Alt",function grabmytext() {translateIt(document.getElementById('styled').value);});
function translateIt(text) {parent.frames['theframe'].googleTranslateElementInit(text);}

The first time this is run, it performs as planned: The value is passed, is written in (English), translated (French).
Similarly, for the reverse translation, the first time run, everything is passed, to be written in (French), translated (English).

However, a different set of rules apply, and function correctly, until grinding to a halt. :(

By examining Network - Headers:

The text is divided by line breaks ( the divider is q: ).
The record shows it being sent like this in English; but we have no record of the return translation.
The next header shows it being sent like this in French ( line by line, separated by q: )

2nd Pass:

I choose a line of text to edit.
I send (according to my scripts), the entire text (value), and I see it appear in English, then watch it turning to French.
In my other frame, I watch the process in reverse.

However, when I check Network - Headers:
The only text that I have sent, is the line of text that I have edited!
The next header shows the same line in French being sent for re-translation.

Thereafter.... every time I send the text for translation, only the line, or the lines, that I've edited are sent.

How the hell is it managing all this?

Where is all this information being stored?

It first must be storing the (value), and then storing the French translation, plus the individual line links, between the (value) and the French, cos you can hover over a French line, and read its original English.

It must then be storing another copy of the French and the reverse translation with its links, cos you can hover over the English and read the original French.

WOW!

From its perspective I got 28 edits.
From my perspective I got 14 edits.

It then ground to a halt.

The only way forward, is to select & copy all the text, then reload, and paste in the text, and start editing from where you left off.

Solutions?

Is it possible to flush the memory without reloading, and re-read the scripts etc?
Effectively: the text value would be sent as virgin text (like the very first time) :D

BTW I'm assuming this IS a mem problem, because it certainly clears on reload.

Ace.....
11-19-2012, 12:49 PM
Heap Snapshot
I tried taking a heap snapshot, but either the feature doesn't work in linux, or my pc is not powerful enough. (64bit dualcore c50 3Gb ram)
I left it for an hour parsing, the pc unusable during the period.
I finally hard switched it off.

Used Heap
I'd read that timeline can help identify mem probs.
This showed the peak used heap size 52Mb of 87Mb

This was as high as it got.
During the editing test, it had gone up to 70Mb, dropped down to 40Mb, and then began to rise until 87Mb.

At no time was the used heap size close to the total.

Counters

Docs 16
Nodes 18,970
Listeners 17,807

These figures are at the point of script collapse - they started low, & rose with every operation.

The Halt
The first to stop was a reverse translation
But strangely, that didn't kill the system.
I was able to get another English to French translation

The next edit after that, never got sent.
The text was passed in English to frame2, but it was not translated.

Perhaps the solution is to use clipboard and refresh - manually it works.
:)



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum