Multi-language web-site templating system?
May 5, 2010 12:47 PM Subscribe
What's a good system to use for working on a site that needs to be localized for two or more languages?
So far, we've been using Dreamweaver templates. We make one template for English, build the site in DW, no problem.
But the translation service requests the site in one big Word file, and sends it back as one, which means I've got to build the second version of the site with a whole bunch of repetitive copy-and-paste.
I've been reading some stuff about XLIFF and could make the case to the translation service to allow it as a format, but won't bother until I know it'll help to use it.
I did see this closely related question:
http://ask.metafilter.com/35004/How-do-I-extract-website-content-for-translation
But it's from 2006 and there might be something new since then.
So far, we've been using Dreamweaver templates. We make one template for English, build the site in DW, no problem.
But the translation service requests the site in one big Word file, and sends it back as one, which means I've got to build the second version of the site with a whole bunch of repetitive copy-and-paste.
I've been reading some stuff about XLIFF and could make the case to the translation service to allow it as a format, but won't bother until I know it'll help to use it.
I did see this closely related question:
http://ask.metafilter.com/35004/How-do-I-extract-website-content-for-translation
But it's from 2006 and there might be something new since then.
(I should clarify - he writes the posts in both languages, and they're served depending on what the reader wants, so in wordpress you'll just copy-paste that word file into one post that has two fields, one English and one Danish - saving you designing two pages. I think this is what you'd want if I understood your question correctly.)
posted by dabitch at 1:00 PM on May 5, 2010
posted by dabitch at 1:00 PM on May 5, 2010
Response by poster: Ooh, further fun things I could mention:
1) Each file name needs to be translated, this includes both pages and even image files
2) Each page should link to its other-language equivalent
3) Most of these sites are updated in large ways infrequently, rather than small changes frequently, so I don't think a CMS is necessary.
4) For images that contain text, we usually change the text in Fireworks and re-export. I would be interested in ways of displaying the all corresponding images side-by-side for quick double-checking that they're correct. (And according to #1, the corresponding images won't have the same name.)
Dabitch: If it's still a lot of copy & paste, I'm not sure that will be an improvement.
posted by RobotHero at 1:21 PM on May 5, 2010
1) Each file name needs to be translated, this includes both pages and even image files
2) Each page should link to its other-language equivalent
3) Most of these sites are updated in large ways infrequently, rather than small changes frequently, so I don't think a CMS is necessary.
4) For images that contain text, we usually change the text in Fireworks and re-export. I would be interested in ways of displaying the all corresponding images side-by-side for quick double-checking that they're correct. (And according to #1, the corresponding images won't have the same name.)
Dabitch: If it's still a lot of copy & paste, I'm not sure that will be an improvement.
posted by RobotHero at 1:21 PM on May 5, 2010
If your translation service requests the site in one big Word file - then I think it is time to seek a new translation service. Any provider worth their salt should be able to accept all of the HTML files process them and return the same HTML files in a translated form. The work that you are currently doing in putting it all in one Word file can be done easily and consistently by a number of translation tools, tools which most providers own.
Copy and paste is madness - the tools parse the translatable content from the code and just show the translator the translatable content. The XLIFF is the format that supports this separation and again the provider should be doing this.
I would suspect that if they are requesting a word file then they may not even know what XLIFF is. Feel free to Memail me, I work for a provider, but would not try to be your provider.
posted by clarkie666 at 1:47 PM on May 5, 2010 [1 favorite]
Copy and paste is madness - the tools parse the translatable content from the code and just show the translator the translatable content. The XLIFF is the format that supports this separation and again the provider should be doing this.
I would suspect that if they are requesting a word file then they may not even know what XLIFF is. Feel free to Memail me, I work for a provider, but would not try to be your provider.
posted by clarkie666 at 1:47 PM on May 5, 2010 [1 favorite]
As for naming conventions, one thing that lots of Government of Canada pages use is a multi-lingual filename (often /eng-fra) with the language selection represented by the directory:
ie: http://gc.ca/fra/cats-chats.aspx vs http://gc.ca/eng/cats-chats.aspx
(note that that page does not actually exist, despite the PM's interest in helping cats find foster homes)
I am not TOTALLY sure of how the language selector works, since no matter what page you are on you can just click on the other language and be brought to that page, but possibly a IT-involved GoC'er is on here and could clear that up.
I think that the copying-and-pasting may be unavoidable; whenever I create something for my department's website, I have had to submit everything in both English and French.
posted by urbanlenny at 1:51 PM on May 5, 2010
ie: http://gc.ca/fra/cats-chats.aspx vs http://gc.ca/eng/cats-chats.aspx
(note that that page does not actually exist, despite the PM's interest in helping cats find foster homes)
I am not TOTALLY sure of how the language selector works, since no matter what page you are on you can just click on the other language and be brought to that page, but possibly a IT-involved GoC'er is on here and could clear that up.
I think that the copying-and-pasting may be unavoidable; whenever I create something for my department's website, I have had to submit everything in both English and French.
posted by urbanlenny at 1:51 PM on May 5, 2010
Response by poster: I developed a distaste for multi-lingual filenames years ago when I worked for a Government of Canada department and had to spell out their awkward URLs over the phone. It strikes me as ensuring equality by inconveniencing English mono-linguals rather than by improving the convenience for French mono-linguals. As a design philosophy, the latter seems better.
I would technically be allowed to do it either as this:
http://gc.ca/fra/cats-chats.aspx vs http://gc.ca/eng/cats-chats.aspx
or as this:
http://gc.ca/fra/chats.aspx vs http://gc.ca/eng/cats.aspx
But I know what my preference is.
posted by RobotHero at 2:29 PM on May 5, 2010
I would technically be allowed to do it either as this:
http://gc.ca/fra/cats-chats.aspx vs http://gc.ca/eng/cats-chats.aspx
or as this:
http://gc.ca/fra/chats.aspx vs http://gc.ca/eng/cats.aspx
But I know what my preference is.
posted by RobotHero at 2:29 PM on May 5, 2010
Response by poster: urbanlenny:
Though I suppose my preference isn't set in stone.
clarkie666:
So far the client has picked the translation service. And their request for a Word doc got to me second-hand, so I guess I should check that an intermediary didn't ruin it for me.
posted by RobotHero at 2:57 PM on May 5, 2010
Though I suppose my preference isn't set in stone.
clarkie666:
So far the client has picked the translation service. And their request for a Word doc got to me second-hand, so I guess I should check that an intermediary didn't ruin it for me.
posted by RobotHero at 2:57 PM on May 5, 2010
Best answer: The standard for storing text in multiple languages - for translation of software and web applications - is gettext, so you'd be looking for a po editor.
The other part of the answer is that any moderate scale website built recently uses a CMS. Some of the common ones have very good support for multilingual - Drupal being quite excellent in this regard.
posted by tmcw at 9:07 PM on May 5, 2010
The other part of the answer is that any moderate scale website built recently uses a CMS. Some of the common ones have very good support for multilingual - Drupal being quite excellent in this regard.
posted by tmcw at 9:07 PM on May 5, 2010
Best answer: As I mention the service provider should be able to deal with the source HTML files and return the same, however if as you mention the alternative is to provide them with XLIFF (which is a new XML localization standard) and have the return the same. This is a good approach however you will need to take responsibility for the version control and conversion of the files. Though if you are doing copy and paste - this seems like a much happier life.
To produce the XLIFF files you will need a localization tool that can convert your files into this format. One option to consider is GlobalSight, which is the beginning of a Translation Content Management solution that is opensource. It is still a little raw for service providers but if you are looking at core functionality that will allow you to 1. Input your HTML assets, 2. Output XLIFF 3. Import translated XLIFF and produce final HTML. One HUGE advantage of using such a system is that when you do your updates for your next release - you can just run all of the content again through the system. It will pre-translate and allow you to isolate just the content that needs to be translated. In this way you can just send and pay for the new content (you pre-translate everything that hasn't changed).
There are other desktop/server tools that can do this, such as SDL Trados, Wordfast, Across, memoQ and Atril Déjà vu.
If you can it would be good to work directly with the service provider. In my past experience as a Project Manager I was often presented with projects where it seemed that the client was very low tech or wanted something very simple. After digging and persisting to speak with the developers of the content often we were able to suggest an alternative format or process that made no difference to us but saved them days or even weeks of work.
posted by clarkie666 at 10:53 PM on May 5, 2010
To produce the XLIFF files you will need a localization tool that can convert your files into this format. One option to consider is GlobalSight, which is the beginning of a Translation Content Management solution that is opensource. It is still a little raw for service providers but if you are looking at core functionality that will allow you to 1. Input your HTML assets, 2. Output XLIFF 3. Import translated XLIFF and produce final HTML. One HUGE advantage of using such a system is that when you do your updates for your next release - you can just run all of the content again through the system. It will pre-translate and allow you to isolate just the content that needs to be translated. In this way you can just send and pay for the new content (you pre-translate everything that hasn't changed).
There are other desktop/server tools that can do this, such as SDL Trados, Wordfast, Across, memoQ and Atril Déjà vu.
If you can it would be good to work directly with the service provider. In my past experience as a Project Manager I was often presented with projects where it seemed that the client was very low tech or wanted something very simple. After digging and persisting to speak with the developers of the content often we were able to suggest an alternative format or process that made no difference to us but saved them days or even weeks of work.
posted by clarkie666 at 10:53 PM on May 5, 2010
Response by poster: I'll take a look at some of these tools, and the next time we have a project that requires translation, I'll request to work more closely with the translation service before beginning.
posted by RobotHero at 9:22 AM on May 10, 2010
posted by RobotHero at 9:22 AM on May 10, 2010
This thread is closed to new comments.
posted by dabitch at 12:58 PM on May 5, 2010