Quote:
Originally Posted by AndrewGSW
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.
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
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.