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 2 of 2 FirstFirst 12
Results 16 to 28 of 28
  1. #16
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by rnd me View Post
    if this is something that's going to be saved, it better to use <textarea>.value so people can cut and paste and to prevent the browser from wrongly fixing certain unicode chars.
    The major problem with textarea is that g-translate doesn't see it.
    I think it assumes that as 'user input' it has no right translating it.

    So:
    With all the thinking and research that's been going on..... it has led me to believe that the simplest form is going to be best:

    Code:
    var text = document.body.innerText;
      localStorage.pg_2_text=text;
    This standardises everything, and enables simple comparative testing for state of change (which will be needed as the text changes from English to French.

    It works..... I've tested it.


    • I can write into the textarea of page 1
      localStorage it as page_1_text
    • Refreshing page 2 causes page_1_text to be written as innerHTML <pre>(will try innerText tomorrow).
    • Google auto reads the page & sends back its translated text as innerHTML.
    • I can click the text, and the translation is localStorage(d) as page_2_text.
    • Refreshing page 3 causes page_2_text to be written as innerHTML<pre>.


    It seems perfect!

    We've come a long way around the houses.... but I guess: that is what it's all about.

    I know what you're saying (about the universality) but I think that this might be a good place to move on to other interesting aspects (with another thread..... so if improvements can be made on this current issue then fine).

    There is the question of 'checking the state of page 2..... when it's changed to (say) French, it will need to be stored, and page 3 reloaded.

    So this is gonna require an 'onEnter' event to complete a paragraph.
    The whole text then passed via localStorage & refresh to page 2.

    An indeterminate number of milliseconds later, the text will change to French, and will require passing to page 3.

    LocalStorage can handle the passing of data from page to page.
    What's gonna be interesting is the sequence of events that occur when the author hits the 'Enter' key (to complete a paragraph).

    Clearly page 2 has to refresh AND (I think) start a compare loop, checking the page 2 innerHTML with the page_1_text variable.
    When it changes..... stop comparing, and pass it to page 3.

    Ok... so I've just started a new thread on the old thread.
    Sorry... it's nearly 3:00am.
    I think I'll chuck the towel in for tonight.

  2. #17
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    Actually I think I'm gonna use textContent throughout, to replace innerText & innerHTML.

    This creates a standard text based system.

    Once this is fully functional, it will be worth looking again at incorporating Ali's script, which is more geared for wysiwyg web editing, with 2 monitors, or a big widescreen.

    Sure it would be better, cos it would do everything, but keeping it simple to get the tool finished, is I reckon, a good idea.

  3. #18
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    Actually I've tested in Firefox, and it prefers innerHTML.
    So I've reinstated that across the board.

    I guess the moral of the story is that there are few genuine standards.


  4. #19
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    Actually, the moral of the story is that there are no standards.

    It is not just a matter of sniffing to present innerText or textContent.
    textContent doesn't provide line breaks.

    I found a v.good script to deal with this:

    http://clubajax.org/examples/plain-t...-vs-innertext/

    A real tour de force.

    It may be that I need to use this script.
    I noted there were a couple of comments at the bottom re: some minor issues.

    I need to first review each of the text transfers.
    At the moment, google are returning my line broken text, without the line breaks.

  5. #20
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,277
    Thanks
    10
    Thanked 581 Times in 562 Posts
    fun fact: in chrome, those linebreaks in textContent might come back if you first set the container's white-wpace to "pre" or "pre-wrap" or "pre-line". Surprisingly, this affects textareas as well; a fact which burned me for years before i figured out what was going on.


    silly question comes to mind:
    after hearing about your linebreak and dom issues, i have to ask; are you using google's translate API?

    if so, it expects plain text, and it preserves line breaks just fine. You would use a textarea to send a string back and forth to google. This works simply and perfectly.


    If you are using some kind of hack where google is trying to translate an HTML page you publish, that's going to be a lot trickier and google can change their formatting at the drop of a hat, breaking your script.

    bottom line, use APIs and you will have FAR fewer inconsistencies like you've noted.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/5/28) IE7:0.1, IE8:5.3, IE11:8.4, IE9:3.2, IE10:3.2, FF:18.2, CH:46, SF:7.9, NON-MOUSE:32%

  6. Users who have thanked rnd me for this post:

    Ace..... (11-09-2012)

  7. #21
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    Sorry for the delay in responding.
    After seeing that the line break problems revealed themselves during the operations that passed the values back and forth, I decided to separate the problems.
    1. Script to pass values
    2. Script to deal with the values


    The former being discussed here:
    http://www.codingforums.com/javascript-programming/281274-developing-triple-iframe-rolling-refresh-inc-change-state-post1290393.html

    The objective being to create a system that can pass the variables from start to finish.
    With that in place, the different variables can then be experimented with.

    On that issue, it may be, that the sensible route is to pass for translation everything (Google seems to handle it well), but, having said that....
    .... Let's not forget that the text IS being entered into a textarea - so: text and line breaks.

    Anyway, the script to pass the variables is progressing nicely. Possibly only one more major bridge to cross, before light becomes visible.

    However you do raise a couple of very good points:
    Quote Originally Posted by rnd me View Post
    If you are using some kind of hack where google is trying to translate an HTML page you publish, that's going to be a lot trickier and google can change their formatting at the drop of a hat, breaking your script.
    This IS a concern.
    It is not so much a question of hacking..... though to be fair it may be.
    Almost everything works with google published code, that is provided for their users.

    Ie. If they change their published commands, then everybody on the planet is gonna have to re-install the 'two part codes' (head & body).

    However, there are no event handlers (it would seem) that can cater for our specific needs.
    It may be that we need to extract a 'script status' (gleaned from the chrome log), a number of which look to be very standard, and unlikely to change more than might be expected.

    That then brings your other point re API

    Quote Originally Posted by rnd me View Post
    silly question comes to mind:
    after hearing about your linebreak and dom issues, i have to ask; are you using google's translate API?

    if so, it expects plain text, and it preserves line breaks just fine. You would use a textarea to send a string back and forth to google. This works simply and perfectly.

    bottom line, use APIs and you will have FAR fewer inconsistencies like you've noted.
    Hmmm!
    That is very different to how g-translate works at a user/webmaster level.
    It does not read textareas.

    Yet even if it did...... the key to this system is that the translated text is then passed back to google.
    So the 'translation done' event must still be recognised.

    I'll definitely have a look into the API affair.
    Perhaps it provides just those tools I'm looking for.

    Quote Originally Posted by rnd me View Post
    fun fact: in chrome, those linebreaks in textContent might come back if you first set the container's white-wpace to "pre" or "pre-wrap" or "pre-line". Surprisingly, this affects textareas as well; a fact which burned me for years before i figured out what was going on.
    Thanks for that; that info could prove very useful considering the problems I was having in that area.

  8. #22
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by rnd me View Post
    are you using google's translate API?
    Re: my last post, one of the things I said I'd do, was to look at google API.

    I've just done so.

    To be honest...... it seems like another mountain to climb, when I'm already close to peaking this one (thanks to community support).

    It's not that it's a 'paid for club' per se, but it involves setting up payment accounts on usage that will be beyond my control.
    Like if some clever sod sets a character feed to your input (just for fun).

    Then on top of that there is all the coding simply to deal with authorisation etc. before beginning to find out whether, in their library, some other bod has developed the script that is anyway required.
    (and if not, it will have to be anyway developed)

    I think it was worthwhile looking at it as an option, but, at the moment, the project is advancing well, and everybody following it is potentially getting something out of it.

    I think I'll stick with codingforums.com for the foreseeable future.

  9. #23
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by rnd me View Post
    fun fact: in chrome, those linebreaks in textContent might come back if you first set the container's white-wpace to "pre" or "pre-wrap" or "pre-line". Surprisingly, this affects textareas as well; a fact which burned me for years before i figured out what was going on.
    Who would have thought that it could be such a hassle to provide word breaking between words?

    I've spent a few hours trying to tidy the presentation, and progress has been made.
    This is a good reference on the points you mention (and everything):
    http://www.w3.org/TR/css3-text/

    The only problem is going to be compatibility.
    I'm testing between Firefox and chrome at the mo, cos I can't be bothered to boot into windows.

    Each handles pre differently in HTML but perhaps in css they may be more unified.

  10. #24
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Ace..... View Post
    Who would have thought that it could be such a hassle to provide word breaking between words?
    At last, a major breakthrough with presentation.

    You are forced to use:

    Inline-styles!!!

    The penny dropped when I could see the English copy appear on page perfectly, only to be replaced by the translation, all collapsed.

    I'd been trying every word break rule that W3c has to offer (and they have loads BTW), but I'd been using a style sheet.

    Style sheets, as I've discovered, just don't work with post-load, written-in HTML.

    For crying out loud...... All the frigging posts and articles I've read; and none of them made reference to inline-styles!

    It's a great victory (for perseverence).

    Style-sheets are useful, but without adequate knowledge, they suck you into complacency.

    A daft bit of knowledge, having such an impact!

    Everything is possible now......Wow!
    Last edited by Ace.....; 11-10-2012 at 12:50 AM.

  11. #25
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    Okay....... a working version at last.

    There are still display issues, but the major problems were cleared up after the tip by rnd me, that led me to discover the need for inline styles.

    Immediate display problems relate to:

    Establishing the workspace height for any screen/browser
    I finally went with pixels, just to get the system working, but by zooming out, the workspace is wasted.

    There are I'm sure, ways around this....... It does look a little noobish, by failing to provide scalable height.

    Line spacing - Pasted web site text is more difficult to read
    When typing text, one would automatically hit enter twice to insert 2 linebreaks (as per this post for paragraphs).
    Therefore typed text is perfect(?)

    When pasting a web page contents, typically only one linebreak is used, because in HTML, the additional spacing is automatically provided.

    I don't see any way around this other than by human intervention.
    Save to a text file, and literally add line breaks for clarity, and then use for translation.

    Browser Wars
    I've yet to test the prog on anything other than Chrome & Firefox.
    Both will be very up to date cos I run Ubuntu 12.04.

    There are sure to be issues with IE and older kit, but we'll see.
    You may well discover a few gaping holes in it (but that's good).

    Anyway, here it is:
    (read thru the short instructions first, to learn the best way forward)
    Edit:
    Also a minor problem with the Google inserted header.
    It is cut off at bottom.
    zoom out zoom in and the problem disappears.
    Last edited by Ace.....; 11-11-2012 at 06:01 PM.

  12. #26
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    I just ran it in iexplorer 9.
    Pretty disastrous.

    Not only are the frames not displaying as desired, but the line breaks are not functioning.

    What is the general thinking now, vis a vis two sets of code: FFox/Chrome & iExplorer?

    Obv.... I understand that it means 2 updates.
    Yet that might be a price to pay, in order to avoid the extreme hassle surrounding browser compatibility.

    Or is the way forward, different sections of code, that will be read, if a browser is x or y?

    Or have I just failed to implement the correct code, and hence the iE9 fail?

  13. #27
    Senior Coder xelawho's Avatar
    Join Date
    Nov 2010
    Posts
    2,883
    Thanks
    56
    Thanked 539 Times in 536 Posts
    the problem I believe is that a textarea uses \n to denote a line break whereas innerHTML uses a <br>

    IE seems to be the only one that is really fussy about this, but you can fix it by including a regex to replace those \n's in the function on your "start" page:

    Code:
    function translateIt(text) { 
    var text=text.replace(/\n/g,"<br>")
    parent.frames['theframe'].googleTranslateElementInit(text); 
    }

  14. #28
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    ...
    Internet Explorer 9.......... Sorted!

    Okay the display problems in iE9 relate to the need for a doc declaration.

    Originally I had been using:
    Code:
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
    I then removed it because I was using new html5 declarations.

    Apparently, FFox & Chrome can manage without a doc declaration.
    Research informed me that iE8 & above require it.

    So I chose the new HTML5 declaration, which is incredibly simple, and is supposedly backwards compatible (I read).

    Code:
    <!DOCTYPE html>
    I also learned that I must clear the web browser cache every time I run a test.
    I discovered this, when FFox didn't like my // method to disable certain style declarations.
    I deleted them completely, yet FFox console still found them, even after closing the tab and starting again.

    Actually, I have found FFox console to pick up far more errors than Chrome console.
    It reminded me I must declare the character encoding (which I did).

    With trepidation I loaded the sys in iE9, and YES!
    It displayed seemingly perfectly.

    AhHa......... so maybe, with good coding, the 3 main religions can be catered for in a single document.

    What a relief (you can imagine).
    I've gotta test it a bit more but so far so good.



 
Page 2 of 2 FirstFirst 12

Tags for this Thread

Posting Permissions

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