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.

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.

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.

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:

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

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.

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.

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.

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.