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.
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.
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 5/13) STATS (2013/5) HTML5:90.2% MOB:14% IE7:0.5% IE8:8.6% IE9:9.8% IE10:10%
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.
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
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
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
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.
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.
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.
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.
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?
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);
}
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.
Before you post, read our: 
