If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Enjoy an ad free experience by logging in. Not a member yet? Register.

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.

Originally Posted by xelawho

also, this is going to cause you problems:

Code:

<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.

Originally Posted by xelawho

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.

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."

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.

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.

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:
You'll see there are some valuable instructions with it, based on my experience of translation.

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.

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

( 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? )

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:

Code:

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.

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'.