Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 3 of 3 FirstFirst 123
Results 31 to 43 of 43
  1. #31
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by xelawho View Post
    oh, dear

    this line
    Code:
    res=thediv.innerText?thediv.innerText:thediv.textcontent;
    should be:
    Code:
    res=thediv.innerText?thediv.innerText:thediv.textContent;
    change that, and Olivia gets sad about her camera in FF, too

    I think a copy/paste error cos the two lines are the same:
    Code:
    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.

  2. #32
    Senior Coder xelawho's Avatar
    Join Date
    Nov 2010
    Posts
    2,981
    Thanks
    56
    Thanked 557 Times in 554 Posts
    no - the second line has a capital c for content:
    Code:
    res=thediv.innerText?thediv.innerText:thediv.textContent;

  3. #33
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    Yes, that did it.

    I'll run some more tests on it.

  4. #34
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    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).

    ?

  5. #35
    Senior Coder
    Join Date
    Apr 2011
    Location
    London, England
    Posts
    2,120
    Thanks
    15
    Thanked 354 Times in 353 Posts
    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.
    "I'm here to save your life. But if I'm going to do that, I'll need total uninanonynymity." Me Myself & Irene.
    Validate your HTML and CSS

  6. Users who have thanked AndrewGSW for this post:

    Ace..... (11-14-2012)

  7. #36
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by AndrewGSW View Post
    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.


  8. #37
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    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.


  9. #38
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    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.

  10. #39
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    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

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

  11. #40
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    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.
    Last edited by Ace.....; 11-15-2012 at 04:15 PM.

  12. #41
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    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?

  13. #42
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    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

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

    Code:
    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)

    BTW I'm assuming this IS a mem problem, because it certainly clears on reload.
    Last edited by Ace.....; 11-18-2012 at 05:48 PM.

  14. #43
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    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.


 
Page 3 of 3 FirstFirst 123

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •