Forum Moderators: open
If not, how do you go about creating a website in Polish?
[edited by: tedster at 3:31 am (utc) on Oct. 30, 2004]
[edit reason] split from this thread [webmasterworld.com] [/edit]
And so we've put together a translation team - two people per langauge. One person is the translation professional, and the other is the proofreader. And when the first 14 languages are done, many more are projected.
So we first created the English language website. Next the translators create Word documents which we converted to pdf downloads for the first 14 languages - we have to ensure that our team has the correct fonts and embeds them in the pdf. We also create separate directories on the server for each language that have the correct HTTP headers, and make sure the pdf documents have correct metadata.
The pdf's go back to the proofreaders, especially for line break issues and such, although they also have an eye out for wrong shifts in meaning. The proofreader and the translator hash all that out.
Now we go through the website and create a list of words that we need translated just for the HTML version - file names, graphic text, text links, etc. The translators handle that.
Next we take the English HTML and change the pages' charset meta tags and lang attributes. After that, we create the new graphic images and then paste in the translated text.
Final step - back to the proofreaders, and possibly the the translators, for last minute tweaks. Then place the translated HTML online.
It's certainly a project the likes of which I've never tried before. If we stumble over anything more, I'll be sure to share. So far, we've been saved a lot of trouble by the technical knowledge of our translators.
Each language has its own unique demands - such as hyphenation conventions in those long, compound German words. And there are apparently conventions about which pictographs should and should not be near each other in polite Chinese.
[edited by: tedster at 7:25 pm (utc) on Oct. 30, 2004]
Google's "language tools" have been helpful in finding authoritative websites in each language.
Then of course there's the pain of doing updates to the translated pages when you update the main language page - inevitably I think the secondary language pages will 'lag' a bit *_*
I'm considering a job for a financial wiz (basic page with links to pdfs to make his 300 different forms available for download and printing), and while I have a clear idea what to bid for the English setup, he also needs it in Spanish - which is the "home" language of about 30% of his market. He's providing the translation, btw, and the only graphics I'll have to worry about will be his logo, which he also will provide in the Spanish version.
I was needing some background on how much time this could take and how complicated it could get, so I know whether to just bid by the hour for updates, or bid a maintenance setup on a yearly figure (I tend to not like to do that anyway - too many possibles for "off the wall/off the charts" stuff to bite you you-know-where). Would you say that using includes for portions of pages which would need regular updating would be a good fit for a single "other language" setup?
It's absolutely amazing to me that just as I need some information, WebmasterWorld pops up with the goods! Thanks, ted. You're a wonder!
Is the site going to be completely bilingual with identical pages available for both languages? The best way I've found is to make a best-guess detection of the user's preferred language on the home page, and leave the option to switch languages at any time. I find it so much better than a splash page just to choose the language. If you can store the value in a cookie for later, that's a good idea too.
It is important also that the "switch language" link on any one page leads to the equivalent page in the other language, not just back to the home page.
Bilingual sites are not too bad to manage - especially if you speak both languages - but multi-lingual sites can quickly become a nightmare!
Yes, I had figured that the character set wasn't a problem - that was the first and maybe only easy thing. Haven't got into the "this page in English, change to Spanish brings same page in Spanish" setup with him yet, though that's how I think it should work.
He does want a page just to choose language first. That's up to him, and we've already had the "search engine" conversation - he doesn't seem much concerned with that, since his business is so huge already with no website at all, therefore no seo/sem etc. I want to see a link on each page which allows change to the other language - sort of a "fail-safe" option....
I'm thinking this will be fun, if I can get the right approach ironed out ahead of time....
This is useful insight, since I had the link going to the equivalent page automatically, and sometimes your other language editor is not available to update/create that site.
If you are planning to do a CMS this become an issue.
Now each language editor can create pages with their own filenames (in their language!) and inform the other language guy of the new content. Whenever that person gets to it, the corespondiong page gets created/updated.
I have found this to be a much more fluid and also SEO friendly way.
I've seen quite a few documents which have been translated from Japanese & Chinese that would still not pass for a well written document. In many cases they are not very understandable (and I'm not talking about machine translations either). You need to make sure that you are taking the extra step to ensure that the document is well written in the target language as well. Unless you are using a top rate translator often you need to take steps to have this extra work done.
You not only need to make sure that the finished work reads well in the target language, but you also need to make sure your message meets the market. For example, if you're targeting a Japanese audience you may not know that direct references to your competition are frowned upon. You'll never see an ad on Japanese TV where they espouse the virtues of brand A over brand B. However, if you go to the US it's hard to not see a commercial where they don't do this. These may seem like small market differences but it could change your content entirely. You need to keep these things in mind, and having your translated materials proofread and rewritten can help tremendously.
The usual objective of having a website translated is to make money by selling the product or service to consumers in another country. Indeed, it's never been easier to tap into new markets. But getting the translation right is just as important as getting the programming right. Translators are not computers! I know of companies that will spend thousands getting their copy just right, hold countless meetings discussing how the message is to come across and pay a great deal of attention, as they should, in projecting their business in a professional way. Yet for all this effort, when it comes to translating the site into another language, it’s often the cheapest translation provider that gets the work – provided, of course, they can finish 20,000 words over the weekend! The foreign reader is presented with poor and unconvincing copy at best, gobbledygook at worst.
On the other hand, good translation makes it possible for you to convey your thoughts, ideas, hopes, dreams, ambitions, experience and anything you want to people who share a different language and a different culture. And when the translation is good - and some translations are very good – readers will understand and take in the message as if it had been written in their own language by someone who shared their own culture! A good translation can make the difference between winning or losing a contract, between encouraging and preventing a sale and ultimately between being taken seriously or not.
Good translation is the ultimate marketing tool – it’s just that not many people know it!
I think you might be missing one of the major factors here. You can build a page that looks perfect, but how are you going to respond to email inquiries? I'm assuming that you won't have anyone on staff who is familiar with all these new languages.
I think you might be missing one of the major factors here. You can build a page that looks perfect, but how are you going to respond to email inquiries? I'm assuming that you won't have anyone on staff who is familiar with all these new languages.
I found the fact that you can to work on translate enamels also, e.g. Systran and works on then translates an answer to the email - * and * you include a prefix line, for 'machine translation' apologizes; - I have excelent communications with methodolgy this had.
I found that with the Spanish market it was especially difficult.
You really have to know the target COUNTRY. Just any Spanish speaker, as good as s/he might be won't do!
Some very embarrassing, albeit funny, mistakes can happen during translation.
That's why I try to have an 'editor/writer' for content in the first place and do not place so much emphasis on 'translation' - you cannot translate culture.
I found that with the Spanish market it was especially difficult.You really have to know the target COUNTRY. Just any Spanish speaker, as good as s/he might be won't do!
Some very embarrassing, albeit funny, mistakes can happen during translation.
... reminds me of the story of how Chevrolet tried to market the "Nova" in Mexico.
Try translating "no va" from Spanish to English and you get "it does not go".
:)
The foreign reader is presented with poor and unconvincing copy at best, gobbledygook at worst.
Welcome to the forums, Snappy_fish. I know exactly what you are saying, here. Several of our translators (but unfortunately, not all) are professional copy writers in their language, and I rest much easier when that is the case.
how are you going to respond to email inquiries?
The email issue is a good one - my client is a global organization with native speakers in the languages where we are creating translations. They are not translators, but they will handle the emails just fine.
As English speakers, we've all seen instructions written for our electronics, clothing, food, and so on that were very poorly translated - and I hope the approach my team is using will avoid that kind of problem.
Some challenges have already come up where the the translation needs to be a bit "loose" and the content of two sentences must be intermingled in the target language. Our page builders sometimes inappropriately introduce a new paragraph break between those two sentences to keep the text blocks small on screen, and the flow of meaning is disrupted.
But that's the beauty of using a proofreader - we can catch those problem before final release. These sites are heavy on information, basically lead generation sites, not product sites. So the text must come across very well.
Depending on the complexity of your website there can there can be a lot of technical issues that may require additional engineering staff--like character encoding being supported by web applications you are using,double-byte issues, database, url browser compatibilities etc. Also there are issues such as how it's displayed (geoip-based?) and how new information gets translated and published (process, time-lag etc.), architectural issues. A large site usually has QA. Can QA handle foreign translations--do they know that there may be technical differences or process time lag when compared to English pages? Are there tech or other emails that are sent out that will now need translation? How long will that take each time one is needed? Is everybody in the loop and on the same page about this?
Do not just hire the cheapest translator. That's a bad idea. The amount of hassles created by our using cheap translators (round 1) cannot even be imagined. Translators should be well-trained with some sort of documentation (certification) or credentials--which is industry-standard for a professional firm. Just getting anybody who knows English and Spanish to translate your site into Spanish is not necessarily going to work. Translation is an actual skill. The translator has to know both languages fluently, has to make decisions based on the context of the words sometimes rewriting things, has to know the idioms and slang of both languages and other specialized internet words. I hired a translation company not the individuals, but I still insisted on interviewing the translators and vetting them to make sure they were up on music style (our website topic) and other specialized info.
Since we were a large website with a ton of data it required a team of translators on their end, which in turn required an internal process on their end and a project manager on their end. Since each translator has a different translation style a set of rules, a style guide, has to be put in place and approved. Then you need another style editor person to make sure the style was maintained (between translators), then finally a proofreader. Also there needs to be a feedback mechanism in place so errors can be quickly sent back to them and corrected. And make sure versioning is under control--are they working on the correct version of the document--have things been changed on the English site, perhaps an error corrected, whcih will not show up corectly inthe translated doc because they were working on an older version.
Then there is translation tone. We were targeting a young 16-35 demographic for music so the tone of the translation had to be more informal. Of course in many languages this is much more of an issue than in English. Round one we didn't think of it as much and the translation read like it was for a 60 year Spanish professor. Then as somebody else stated there are different styles of Spanish and slang in each country.
See how this keeps getting bigger with more variables and potential for complication? Granted on a small site many of these points are not necessary but you get the idea of what to look out for...
btw, check out the w3.org for more info and background from a technical perspective:
[w3.org...]
...and a project manager on their end
I'd like to underscore this point. The value of a strong person as the translation team project manager cannot be overstated.
Our translations manager is multi-lingual and has been a project manager for many years on a healthy variety of projects. He has saved us untold trouble and sometimes has been able to get his team to turn around their work well ahead of schedule.
That, of course, does mot apply if your target is, let's say, Mexican teenagers and a "cool" music selling site. Then the language used is part of the game, as your audience wouldn't like a bit being spoken in formal neutral Spanish.
So we created a web application called the Language Layer. Each section of text, or blurb, was placed into the database, and would appear in a queue for each team of translators. The translators were suppose to view the page the text was on to get the context of the blurb, and translate. If a blurb did not have a translation for the language a user has set, it would default to English. So you could be viewing the site in Japanese and have a paragraph or a button in English. If the blurb changed in English, the translations would get flagged, and the blurb would reappear in their queues. The English version would then display on the page until it was retranslated. As a web developer it was great, for a paragraph, I just wrote something like <p><?=getText(blurbID)?></p>.
I no longer work there, but this is what I've learned from that system. It's a good idea to develop a system where you only need to program for one site. You do not want to start teaching html to translators, and you don't want to have to make programming changes on 8 systems. Although, in creating your database application, you don't want to lose focus on how people will use it. We had a problem where we would create a blurb for a menu item such as "Community" and then we would use that blurb any place we needed it. However, that word may change in the translation depending on the context, and we didn't always account for that. Also, since the blurbs were constantly being tweaked for maximum effectiveness (damn salespeople) and we had tight deadlines, translators would not always look at the context of which the blurb was being displayed and they would just translate the paragraph on its own. I would recommend hiring a team of salespeople who are native to the country you are targeting instead of just straight translators. Then they can write text that fits the page and not just a direct translation from English.
If I were going to redesign their database system I would put more emphasis on the context than separating text into paragraphs. If a page had multiple paragraphs, I would put all of the paragraphs into one field. The problem comes with things like lists, tables, and links where html needs to be written but you don't want to allow translators to write html. Actually I may have redesigned the system to parse the html on the page and build a form that sort of resembled the look of the page but contained textareas and text input fields. Then the translators would translate a page at a time, instead of a blurb at a time.
I would estimate, that to create completely workable, debugged and well-translated version of your site with support in second language it will take between 50% and 100% of effort you spent on building the original site.
If I were a large corp, I would approach a large or well-known web development agency in the native country to build my site. Believe me, this would be money well spent and an effort not wasted.
Not sure how the Spanish part of this will play out. Once made aware of the potential for blowing up in his face, he may opt for English-only. Or not. He's done very very well without a website, AND with only basic Spanish-speakers in his office, so we'll see. (The Spanish speakers btw are former LDS missionaries. And his Spanish-language clientele are pretty much within the Salt Lake Basin, with a few as far south as Orem, and a few as far east as Evanston WY.)
I'm as yet unsure whether he has plans to use a website as a vaulting horse to further expansion, or if it's simply an easier way to provide forms and documents for his current client-base....
Again, my thanks!
If you check the site in my profile, you will find a row with 19 flags across the top of each page. We coded the English version ourselves, placed identical copies on the server for each of the 19 domains involved and gave the translators access to the server. They could then download the files and go to work on the text only. All translators were nationals of their respective countries and living in them (important, since expatriates tend to lose their language after a few years). So we got idiomatically correct translations in contemporary language.
If we had needed compelling advertising prose, then we could not have taken this inexpensive route and would have had to use local professional copywriters.
Remember: All internal links must be relative, so that the translators won't have to change coding. They must not use editors that write their own code, such as Front Page a.o.
Unfortunately most of the time such a person is not available, leaving you stuck with the usual techniques of sending text files to external non-technical translators. For anything but trivial static sites, this doesn't work well. Without the context of the running site in front of them they're not going to get it right, resulting in long cycles of correction and testing. (Or, omitting testing stage, laughably awful site copy.)
I wish I had a solution, but I really don't think there is one; to do it right you need staff who understand both your site and the target language.
In any case, I'm quite happy that this has sorted out this way. I'd like to get his site up and running the way we BOTH want to see it, without having a problem of the other nature waiting in the wings. Hopefully by mid-2005, he'll have done his research and will have some viable options for us to work with.
I can't begin to tell you all how valuable your input has been. No matter how long I've been designing websites, this particular thing was FAR out of my realm to discuss with any intelligence. Thank you all so much - you helped me come across as professional and logical. Bless you!
That would be like making a version for Canadian English version and another for standard English. A bit useless and hard to understand.
But that is just my personal and untransferible opinion ;) (posted from Madrid).
(Aaarrghhh!)
