Hallo everyone,
Can anyone please suggest a reason for the following?
Why, when we upload a page of text that has been translated from our native English to another European language and which appears to read fine with all accents and everything in our browsers and on-line live, but without graphic images inserted, does the text change to include gobbledygook characters when we do then come to insert some graphic files (none of which have caused problems in our English homepage and associated pages)?
We work in Dreamweaver and the translations are being sent as 'Word' files. Am I right in thinking that when used for the web, 'Word' has a lot of extraneous coding when published to web? So coulsod it be a case of the translator copying our webpage text, translating it on page in 'Word' (which may then read the html from our web in a differnet way?) and then us copying and pasting confused coding into our web pages to be uploaded and published?
Thanks to anyone who can hlep in the tiniest way. We've learned much from these Forums and thinks it's a great site for all sorts of subject matter.
Cat
Gobbledygook in translated pages
Hi Brooke,
yes it's this page http://www.pictureburgundy.com/painting ... French.htm
Our web hosters have sorted the other two pages but will not give us an explanation as to why the text is changing if we manually insert the lozengeheader in their editing suite!
The problem is we need to keep changing text etc at dreamweaver level but every time we upload to the server all the text changes.
What do you think?
Thanks,
Catherine
yes it's this page http://www.pictureburgundy.com/painting ... French.htm
Our web hosters have sorted the other two pages but will not give us an explanation as to why the text is changing if we manually insert the lozengeheader in their editing suite!
The problem is we need to keep changing text etc at dreamweaver level but every time we upload to the server all the text changes.
What do you think?
Thanks,
Catherine
Catherine,
I'm not saying this is a definitive answer, but I do have one or two ideas as to what may be happening. To an extent your comment about Word and extraneous coding seems logical, as it almost looks as though the page is displaying the HTML coding for the text, rather than the text itself; I assume that you pasted the text into the code/split view, rather than the design view?
Also, what font are you using? I tried using a couple of non-standard fonts in an early test page, and it also looked fine in Dreamweaver and offline browser, but did weird things when I put it online. Since then I've stuck to the safe but boring fonts.
I'm not saying this is a definitive answer, but I do have one or two ideas as to what may be happening. To an extent your comment about Word and extraneous coding seems logical, as it almost looks as though the page is displaying the HTML coding for the text, rather than the text itself; I assume that you pasted the text into the code/split view, rather than the design view?
Also, what font are you using? I tried using a couple of non-standard fonts in an early test page, and it also looked fine in Dreamweaver and offline browser, but did weird things when I put it online. Since then I've stuck to the safe but boring fonts.
AndyLucia
If you can't say anything nice, don't say anything at all!!
If you can't say anything nice, don't say anything at all!!
It's the special characters that are causing it, but it may not be the font that's the problem.
You should use the right codes for the characters, like vrooje says. I think Dreamweaver should do this itself, but it may be confused by a font with an incomplete character set, so it might be worth trying it with a standard font first.
But better might be to find and replace within dreamweaver, substituting the correct ascii codes - have a look in dreamweaver's help, or you can google for a list like this
http://www.ascii.cl/htmlcodes.htm
You should use the right codes for the characters, like vrooje says. I think Dreamweaver should do this itself, but it may be confused by a font with an incomplete character set, so it might be worth trying it with a standard font first.
But better might be to find and replace within dreamweaver, substituting the correct ascii codes - have a look in dreamweaver's help, or you can google for a list like this
http://www.ascii.cl/htmlcodes.htm
One of the things I love about Dreamweaver is the find/replace function. It has the usual options of performing the search on one document or on all open documents, but it also has the option to do it for the entire website (whether the documents are open or not). I had to use that recently when my web host did a server migration, and it made a 5-minute job out of what could have been a monster.
(I should mention that I always use the code view of Dreamweaver, so I don't have a lot of the problems others have.)
There aren't that many accented characters in French, so I would think it'd be a simple matter of replacing, e.g., é with é and so forth, across all your documents.
Of course, save a copy of all your files somewhere as a backup, in case something goes wrong!
(I should mention that I always use the code view of Dreamweaver, so I don't have a lot of the problems others have.)
There aren't that many accented characters in French, so I would think it'd be a simple matter of replacing, e.g., é with é and so forth, across all your documents.
Of course, save a copy of all your files somewhere as a backup, in case something goes wrong!
Brooke
Hi to all -
and thanks for a set of very positive responses.
We'd be interested to know if you, Susan, had saved your translated Word document for the web, as we have only cut and pasted the translated texts in ordinary Word format - maybe this is a part of the problem? Should we save to web format within Word (or is there an ascii option) and then import into Dreamweaver and use Dreamweaver's 'clean-up Word html' function, maybe?
We were particularly interested in the mention of ascii, as the only piece of advice we have managed to obtain from 'service' team at our hosting company is to upload (using Filezilla, which is great) text files in ascii format and graphics files using another of the Filezilla option.
We have been wondering how this works, as we should have thought that, (like our own?) most people's web pages contain both texts AND graphic images and are sent up together - sure, we have to 'supply' the images separately . . . but is the hosting company suggesting the following (without actually telling us!) that we should;
upload pages containing text only in ascii form and add the images, uploaded in auto mode, at remote host level and then add the images to the text designed pages at their remote level? Seems wierd if so.
We have to apologise to AndyLucia as we are not savvy enough to understand (yet) the difference between htm, html, xhtml and presume that he refers to a piece of overall coding at top of page, rather than with each with its own coding tags for element of text??
Gets ever-so confusing, doesn't it? Too many red herrings!!
Thanks again everyone and your thoughts continually appreciated - we have some ideas to try at our own local level and to throw at our hosting company for response.
Cat & Colin
and thanks for a set of very positive responses.
We'd be interested to know if you, Susan, had saved your translated Word document for the web, as we have only cut and pasted the translated texts in ordinary Word format - maybe this is a part of the problem? Should we save to web format within Word (or is there an ascii option) and then import into Dreamweaver and use Dreamweaver's 'clean-up Word html' function, maybe?
We were particularly interested in the mention of ascii, as the only piece of advice we have managed to obtain from 'service' team at our hosting company is to upload (using Filezilla, which is great) text files in ascii format and graphics files using another of the Filezilla option.
We have been wondering how this works, as we should have thought that, (like our own?) most people's web pages contain both texts AND graphic images and are sent up together - sure, we have to 'supply' the images separately . . . but is the hosting company suggesting the following (without actually telling us!) that we should;
upload pages containing text only in ascii form and add the images, uploaded in auto mode, at remote host level and then add the images to the text designed pages at their remote level? Seems wierd if so.
We have to apologise to AndyLucia as we are not savvy enough to understand (yet) the difference between htm, html, xhtml and presume that he refers to a piece of overall coding at top of page, rather than with each with its own coding tags for element of text??
Gets ever-so confusing, doesn't it? Too many red herrings!!
Thanks again everyone and your thoughts continually appreciated - we have some ideas to try at our own local level and to throw at our hosting company for response.
Cat & Colin
Hi C&C,
I just copied direct from a Word document and pasted it into Dreamweaver then ftp'd it. In fact, I've just done a test on a random French text and it uploaded fine onto my website, but it was in Times Roman. If you let me know what font you are using I will test it out too if you like,
Susan
I just copied direct from a Word document and pasted it into Dreamweaver then ftp'd it. In fact, I've just done a test on a random French text and it uploaded fine onto my website, but it was in Times Roman. If you let me know what font you are using I will test it out too if you like,
Susan
I have had this problem when using a content management system and Brooke's is the solution - you need to do it in the html, using Find and Replace. It seemed to affect punctuation marks except full stops and commas.vrooje wrote:There aren't that many accented characters in French, so I would think it'd be a simple matter of replacing, e.g., é with é and so forth
Paolo
Lay My Hat
Lay My Hat
Translation texts from Word docs
Hallo Susan - and thanks for replying so very quickly.
What you say is interesting.
We are predominantly using Eurostyle, although I think I'm correct in saying that for the French translated page we spoke about earlier, there have been few css styles involved and we introduced Franklin Gothic Demi - or similar - purely because as with the Eurostyle on our 'home' pages, it is sans serif, clear and easy to read.
Yes, please - give it a go and see what happens for YOU!
Cat and Colin.
What you say is interesting.
We are predominantly using Eurostyle, although I think I'm correct in saying that for the French translated page we spoke about earlier, there have been few css styles involved and we introduced Franklin Gothic Demi - or similar - purely because as with the Eurostyle on our 'home' pages, it is sans serif, clear and easy to read.
Yes, please - give it a go and see what happens for YOU!
Cat and Colin.
Gobbeldygook in translated pages
Hi everyone,
Have now sorted this conundrum out. For the benefit of those who may be interested, the fault lay with us!
Before we started to use Filezilla, we uploaded loads of stuff, not really knowing where it was going.
We have cleared a whole morass of duplicate material now and after a clue or two from the site hosts, tracked the problem down to a bad file path;
we were asking the site to find and place artwork from a location that it wasn't actually using.
We changed the file path to the artwork from its 'real' location and bingo! the connection was made, the artwork came in - and importantly did not change the translated texts, (special characters and all) and it all displays fine!
Why the hosts just couldn't say that it was the extraneous stuff that we aere accessing instead of gaining it from the correct location, I do not know - loads of talk about bad syntaxes and stuff (don't like any taxes, to be honest! ).
So thanks to all who have contributed and maybe this will halp others who got into this pickle like we did!
Cat and Col
Have now sorted this conundrum out. For the benefit of those who may be interested, the fault lay with us!
Before we started to use Filezilla, we uploaded loads of stuff, not really knowing where it was going.
We have cleared a whole morass of duplicate material now and after a clue or two from the site hosts, tracked the problem down to a bad file path;
we were asking the site to find and place artwork from a location that it wasn't actually using.
We changed the file path to the artwork from its 'real' location and bingo! the connection was made, the artwork came in - and importantly did not change the translated texts, (special characters and all) and it all displays fine!
Why the hosts just couldn't say that it was the extraneous stuff that we aere accessing instead of gaining it from the correct location, I do not know - loads of talk about bad syntaxes and stuff (don't like any taxes, to be honest!
).So thanks to all who have contributed and maybe this will halp others who got into this pickle like we did!
Cat and Col