Droid

Well, the Iphone and AT&T are going to get a run for their money in a couple of weeks. Motorola, Google, and Verizon will debut a phone with a open source platform. Yes, you can now customize how your phone operates. Another big feature is the ability to run background processes like a computer. Now, you can run multiple apps, thus allowing you to work more efficiently. Now, what does that mean for translation and localization. Well, since it has an open source platform and has a 1GHz processor, it might be able to run a translation software. If SDL, and that's a big if decides to offer a scaled down version of it's new Studio 2009, it's quite possible that translators and translation companies could run it on their phones. Mobility at it's best. If SDL decides not too, and you have a really good programmer handy, then you could create a 3rd party app that is compaltible with Studio 2009 and have an editing tool. You could still perform the translations and apply the memory on the go. Google of course has it's own translation tool (machine, but they wil be coming out with a version that allows you to upload existing memory files and useNow we'll have to wait and see if this will work.

Global TM

This week ICD started tweeting, and we started to follow Renato Beninatto, famed translation industry expert and President of Common Sense Advisory. He tweeted about the future of the Global TM (Translation Memory). Basically, it's the idea of combining multiple translation memories from different vendors and create a shared TM. Access can be granted to both vendors and clients who agree to share their memories. Now, that sounds like it should bring about fair market competition between translation companies. For example: If translation company A and B are bidding on the same project they would have the same competitive edge when it comes to the translated content, but the winning bid would come down to the translators cost. That's when the problem arises for translators. The price war has already begun, and with a global TM, translators will have to beat each other based on prices because that becomes the sole variable for translation cost. Then the question of quality becomes an issue.

The other problem arises with proprietary content. TMs are the clients proprietary material, and if they entered into an agreement for a Global TM, then their translated materials would be shared with their competitors. I'm not sure how this will effect instruction manuals, but it could be a problem for marketing literature with catchy tag lines and phrases. You certainly don't want your prized tag line that your marketing gurus spent hours coming up with duplicated or beaten by a competing company. It only takes a couple words to have a best seller.

Will the Global TM succeed? Maybe, if limits are placed on the exchange of translated content, and on access provided to companies that agree to share their memories. Smaller translation companies will also feel the pain as they will be less competitive if they don't participate in the Global TM.

Is XML easier to Translate?

I've always been a proponent of XML content. I think it's faster to get things translated, and with a CMS it alleviates unnecessary emails and creates a translation work flow. However, there are a couple of fundamental problems in XML construction that you should address before setting up a translation work flow. One common problem is using CDATA sections.

Problem:
It's a very bad idea to use CDATA sections to separate
database content from database structure if you want to translate this content. CDATA sections make it impossible for third party tools to parse/separate the text and tags/elements within the CDATA sections. CDATA sections are designed this way because they are explicitly used to hold text and tags to prevent parsing. This makes it almost impossible for third party tools like Translation Memory Systems (TRADOS/SDLX) to parse the text and tags within the CDATA sections. TRADOS/SDLX exposes the CDATA content for translation without further parsing. Therefore, you get all the tags as "real text".

Solution:
You should considers using name spaces instead by placing the database structure, XML into it's own name space and have the database content in a second name space (or have it without a name space). SDL TRADOS Snippet might be a more or less usable workaround here, but it limits the tags you can "hide", and text within CDATA sections that are not closed will be hidden as well.

I hope this helps those of you out there who use XML as a content editor, or are planning to send XML files for translation. It's always a good idea to communicate with you translation vendor, or potential translation vendor when they are bidding on your project. Work together on finding ways to solve potential structural problems within the XML file. You certainly don't want unnecessary content translated, and this will allow you to preempt any exporting problems you might face with deleted or missing tags when you want to publish your translated content.

Photos from the 56th Annual STC Conference

As promised, here are a few pictures from the 56th Annual STC Conference that was held in Atlanta, GA. Catherine, Ann, and I had a great time meeting people, and seeing the sights in Atlanta. We met some interesting exhibitors including the creators of Guimags. A bright idea that allows designers to save time and money by creating their layouts on a board with customized magnets. It also eases the UI testing process with a more interactive experience. Check them out. Overall, the conference was geared more towards writing content in the new age of blog, wikis, and twitter. There was less of a focus on translation and localization even though the majority of the exhibitors were translation companies.

Mobile Blogging Failed, STC Conference Day 2

Well, the mobile blogging idea failed. I didn't have the patience to key in every single word with my not smartphone phone. I should get an Iphone if I want to seriously mobile blog. Yesterday, Catherine and I arrived in Atlanta, and we had to set up our booth. The new booth looks awesome, pictures to come. Now, I'm sitting in a session about blogging and using wikis and blogging about it. Hilarious. Anyway, the blogging aspect wasn't anything new, but the info on wiki's is pretty neat. The speaker is explaining the whole wiki process: setting it up, expanding it, and updating. ICD is considering creating a wiki to update our clients on what's going on with their projects. Twitter would work, but no one seems to think it's very professional. "Wiki Wars" the speaker just said that. Apparently, it happens. People battle it out to see what's actually "true" content. I know, I went off on a tangent. Ok, back to wikis.

The speaker is a writer for Floss manuals, and they use the wiki they created to run book sprints. Book Sprints are a collaborative writing effort to create a book or manual in a short period of time. One option is to use the wiki as a collaborative writing community like a writers block, but on an online community where things can be debated, edited and changed all at the same time. Floss Manuals was able to create a manual for Firefox users in 5 days, and it was a collaborative effort with Mozilla developers. That's pretty quick. There's so much out there in the online community, that people are starting to make business connections and promote their services through the internet. In order to succeed though, you have to be able to utilize the internet effectively, and manage and update your blogs, and wikis so people continue to follow your posts and stay connected.

Esprit d'ICD Spring 2009

Hello All,

ICD's Newsletter Esprit d'ICD has received a face lift for 2009. Gone are "Catherine's Column", "Employee Profile", and "Puzzler" (Ipod's are to valuable to give away during hard economic times). We have more content now and the articles are more concise. Now, you get more stuff to read and more information. We have tried to add article that are a little more widespread and encompass different issues and industries. Some highlights include: "New strides in machine interpretation", "Instant sharing of views and news through Twitter", "The first GPS without a screen", and "What's in a car name?" You can read the newsletter here

We have tried to include what's relevant in today's world, and what's going on in the translation industry. I hope you enjoy reading this issue. If you want to subscribe to our mailing list and receive a copy, email: translate@icdtranslation.com

I'll be in Alanta this coming week for the STC conference, and I'm going to try mobile blogging. Hopefully, I'll be able to inform you about the goings on at the STC, and stuff that might happen with the ICD team as we take on Atlanta.

How Language Crashed a Plane?

I was watching CNN this morning and they were talking about a new book (I don't remember the title), but it was about language and education and how cultural barriers are being broken. As they were talking, one of the highlights appeared on the bottom of the screen: "How Language Crashed a Plane?" That immediately caught my attention, and I listened intensely to the reporting. Apparently, there was a plane crash involving a Korean Airlines flight a few years ago (I tried searching for the story, but it seems Korean Air has a checkered history of airplane crashes and problems, and there were countless crashes. They've improved since the late 90's though. I was on a Korean Airlines flight last October, and it was actually really nice, service was great, all the booze you can drink etc.) Anyway, the reason this particular plane crashed was due to a disagreement between the pilot and co-pilot on the way to solve a problem with landing the plane, and to make matters worse there was a disagreement with ground control in Korea. This all stemmed from their communications in Korean because Korean is a hierarchical language where honorifics and speech level play and important part in grammar and verbiage used between conversations of people with different status. By status I mean either ones job position, age, and education level.

Allegedly, there was verbiage and tone that was incorrectly used between the co-pilot (lower status), and the pilot (higher status) as they disputed ideas to solve the problem they were encountering. This created an argument, and when the ground control officer got involved it elevated the communication breakdown that had occurred between the pilot and co-pilot. The language hierarchical problem that occurred was a costly life-ending event for Korean Airlines and since that incident, they have enforced the use of English for all instructions and commands on their airplanes. This lesson serves as an important factor when considering the use of language. When you get something translated, quality matters. You need to consider cultural aspect and important tone and verb usage. It's important to understand the culture, and experienced high quality translators are able to understand the culture, and translate appropriately.

ICD in Action

Recently, the ICD sales and marketing team (trade show warriors) attended (invaded) trade shows from DC to Montreal. They have been traveling so much, that some of them have packed their entire wardrobe and then some (Mads). Well, here are two pictures from a recent show in DC. The first one above is Catherine expressing the importance of translation and why it's important to consider quality over lower prices, while Sandy gives her winning smile and shows us what a true trade show warrior can handle.
Jeff is pictured below enjoying his time behind the booth after hours of walking the show, and collecting signed POs.


Well, here's to more successful shows in the future. ICD's trade show warriors are currently taking a much needed vacation from the floor, and they'll be back on the road this Summer.

French Canadian Week

Well, this week was unofficially "French Canadian Week" here at ICD. Catherine and Madeline went to Montreal for 3 days to meet with clients, and attend a Trade show. While I had to deal with some interesting French Canadian projects. No, we really don't have language weeks, but it might be fun to have a language week. Maybe we could sample food from that particular country where the language originates, blog about a particular project in that language, and even dress in the local costumes (this might be stretching it a little).

Anyway, the French Canadian project I had was placing French Canadian translations and English text for a bi-lingual label. First off, the label was designed for one language, so the bi-lingual label had to have smaller fonts so everything would fit. Secondly, the client wasn't familiar with the idea or concept of a bi-lingual layout, which is ok, and I fielded a lot of questions about it. So, the project was finished and it was English/French Canadian, and the client asked if it was appropriate for English to go first followed by French Canadian. Generally, this is the accepted layout, but I did ask my translator in Montreal, and his response was rather interesting: " The bilingual version made for Quebec is fine as-is, but could be made 'French before English', which would be more appropriate since the majority of Quebecois are French-speaking. However, Canadians, whether they are Anglo or Franco, are very used to seeing both languages side by side. This bilingual version for all of Canada would also address French-Canadians living outside Quebec."

Well, this comment is interesting because I found out today from Catherine upon her return from Montreal, that the government of Quebec requires that if a child born to two Quebecois (French Canadian speaking couple, both parents are from Quebec) are ONLY allowed to attend schools where French is the medium of instruction. The government does this to maintain the French heritage and culture in Quebec. I just thought this was an interesting way to sum up French Canadian Week, plus I learned a little fact about Quebec and the French Canadian culture.

How to Tango with Lingo

The ICD production room heats up every time there are files that are incompatible with SDLX™ or Trados™ . We have to find a work around, and it's usually more complicated or costly. Fortunately, the guys at MadCap Software™ decided to create Lingo that allows translation companies to work with files created by Flare™ and Blaze™ (MadCap's help file software). They were thinking ahead instead of waiting for SDLX or Trados to come up with a filter.

What it basically does is allow a translator to translate content from Flare into an SDLX environment without using SDLX. So you get the SDLX translation environment (left column source language segments/ right column target language segments) in Lingo, and it also allows you to create a translation memory for content reuse, and a TMX (Translation Memory eXchange) so you can import/export the file to SDLX or other translation tools. It also eliminates the problem of content transfer or extraction from a Madcap program into another software program. What it does not do is analyze the files for repeat content (saving you money), and build a memory from previously translated files.

One more thing, Lingo does not translate the content for you. Automated translations like Google translate are crappy and only work for very simple sentences or independent words. Technical terms and sentences with context value are usually inaccurate with automated translations. Therefore, if you are using Flare or Blaze, you can acquire Lingo, import the Flare or Blaze file, export your content as a TMX, and send the TMX file to the translation company. They'll analyze the file and translate the TMX. You get a translated TMX back, you import it in Lingo and you have a translated help file.

Well, thank you MadCap for thinking ahead, and reducing the stress for all of us in the translation and localization business.