Hello,
We have produced a v1 of our user manual in Flare. Our customer wants to translate this into Spanish. However, the user manual is constantly evolving so I see this as being an iterative process.
So; before we start translating I want to make sure we have the best process to work; Im however not 100% sure how to achieve this and cant find the answer here or in the various online resources.
so here is the process as I see it currently:
1. prepare Flare project for Lingo - using Analyser - fix up any errors/implement snippet suggestions etc
2. Create new lingo project in spanish, and add the Flare project as a resource.
3. Save the created Lingo project. Send this folder and all files to customer.
On Customer Site
4a. Customer uses Lingo to translate all topics/images etc
4b. Customer hits File->Export to Flare and exports files to flare.
4c. Customer zips up that export and sends back to us.
Back at HQ: (by us)
5a. we open the new Flare project (now in spanish)
but ; does this then stay a seperated Spanish flare project or does it merge back into the original?
How do you produce a differences export to lingo? - since the user documentation that we produce will have moved on since the steps in #4 have been done then how do we merge back in and/or produce a new lingo export for the "differences"?
Also; with regard to the Translatioon memory DB. Should the customer create one of these and then send us the db backup - or is there some other way for them to send us the translation memory?
look forward to hearing back from the forumm
kind regards
peteB
Getting Started Help Needed!
-
peterbrown05
- Propeller Head
- Posts: 52
- Joined: Fri Jun 18, 2010 9:08 am
-
RamonS
- Senior Propellus Maximus
- Posts: 4293
- Joined: Thu Feb 02, 2006 9:29 am
- Location: The Electric City
Re: Getting Started Help Needed!
Hi!
Your intended process is quite right. I can't answer all your questions, but here is what I'd do. Start versioning the project and have the customer translate each version (may also call it milestone). A version includes the changes of either a topic area or anything changed within a three month period or whatever works, but do not go crazy and send things out as soon as they changed and then keep track of what came back. Depending on how fluid things are you will be waiting for translations for topics that are outdated by the time you get them back.
Once completed, you will have two entirely independent Flare projects. One in English and one in Spanish. I'd keep it that way, but there is also the option to merge both into one project and share artwork while producing the different language outputs using conditions. To me that option makes sense when three things are given throughout the life of the project: you have a lot of common content (typically images / artwork) that you can use for both languages and besides Spanish you do not add too many more languages and you have a QA process in place that makes sure that none of the different content gets mixed up in the output. You do not want Spanglish. If you keep the projects entirely separate you may need to do some work twice such as inserting images, but I'd rather do that than have something slip through the cracks because someone at a late night forgot to check a checkbox for the conditions.
As far as the translation memory database goes, I think it is better to export the TMX file if needed rather than make a database backup. The database may include tables that contain records that are system specific. While that will work fine at the customer's site it might not on yours. Then again, for producing the output and packaging it up you do not need the translation memory. As long as the customer continues to maintain the translation there isn't much value for you to have the translation memory unless you intent to use it for other purposes. In that case you'd need to make sure that the customer is OK with this.
Also, Lingo cannot be used to translate images, such as screen shots. Either you or the customer would need to redo them. And that means making brand new captures, don't plop a text label on it using PaintShop or something. It will look cheap and the end-user will notice it right away. Besides that, the person doing it will overlook a bunch of labels. Been there, done that, stupid idea.
As far as I know, Lingo can show the differences between versions and that will allow for updating the translation. Lingo takes the best guess possible at that, which may or may not hit the mark, but that depends on the scope of changes.
Lastly, I think you already made the best decision possible in having the customer do the translation. Even if they are not the end-user they will at least have domain knowledge and thus make a much better translation than some translation agency that has no clue about your industry. It will also keep the customer engaged in the project and provide useful feedback (just be prepared to handle it) for both the help and the application before it ships.
And I should also mention that my last active use of Lingo was a while ago, so you may want to wait for some more advice to come in to make sure that this indeed a proper option to proceed. I am sure someone will correct me if I misstated something.
Your intended process is quite right. I can't answer all your questions, but here is what I'd do. Start versioning the project and have the customer translate each version (may also call it milestone). A version includes the changes of either a topic area or anything changed within a three month period or whatever works, but do not go crazy and send things out as soon as they changed and then keep track of what came back. Depending on how fluid things are you will be waiting for translations for topics that are outdated by the time you get them back.
Once completed, you will have two entirely independent Flare projects. One in English and one in Spanish. I'd keep it that way, but there is also the option to merge both into one project and share artwork while producing the different language outputs using conditions. To me that option makes sense when three things are given throughout the life of the project: you have a lot of common content (typically images / artwork) that you can use for both languages and besides Spanish you do not add too many more languages and you have a QA process in place that makes sure that none of the different content gets mixed up in the output. You do not want Spanglish. If you keep the projects entirely separate you may need to do some work twice such as inserting images, but I'd rather do that than have something slip through the cracks because someone at a late night forgot to check a checkbox for the conditions.
As far as the translation memory database goes, I think it is better to export the TMX file if needed rather than make a database backup. The database may include tables that contain records that are system specific. While that will work fine at the customer's site it might not on yours. Then again, for producing the output and packaging it up you do not need the translation memory. As long as the customer continues to maintain the translation there isn't much value for you to have the translation memory unless you intent to use it for other purposes. In that case you'd need to make sure that the customer is OK with this.
Also, Lingo cannot be used to translate images, such as screen shots. Either you or the customer would need to redo them. And that means making brand new captures, don't plop a text label on it using PaintShop or something. It will look cheap and the end-user will notice it right away. Besides that, the person doing it will overlook a bunch of labels. Been there, done that, stupid idea.
As far as I know, Lingo can show the differences between versions and that will allow for updating the translation. Lingo takes the best guess possible at that, which may or may not hit the mark, but that depends on the scope of changes.
Lastly, I think you already made the best decision possible in having the customer do the translation. Even if they are not the end-user they will at least have domain knowledge and thus make a much better translation than some translation agency that has no clue about your industry. It will also keep the customer engaged in the project and provide useful feedback (just be prepared to handle it) for both the help and the application before it ships.
And I should also mention that my last active use of Lingo was a while ago, so you may want to wait for some more advice to come in to make sure that this indeed a proper option to proceed. I am sure someone will correct me if I misstated something.
New Book: Creating user-friendly Online Help
Paperback http://www.amazon.com/dp/1449952038/ or https://www.createspace.com/3416509
eBook http://www.amazon.com/dp/B005XB9E3U

Paperback http://www.amazon.com/dp/1449952038/ or https://www.createspace.com/3416509
eBook http://www.amazon.com/dp/B005XB9E3U
-
peterbrown05
- Propeller Head
- Posts: 52
- Joined: Fri Jun 18, 2010 9:08 am
Re: Getting Started Help Needed!
many thanks for your detailed reply. That all sounds sensible and makes sense.
From what I can see ; the 2nd time the customer receives the project from us they should use File->Update Project and it will manage the differences. I think the important piece of jigsaw was whether the 2 projects should be kept seperate; and it sounds to me like they should be.
As for the screen shots; then fully appreciate that these need recapturing/generating - the customer is also currently in process of translating our UI to spanish and so they should be quite familiar with this although once they are done; we will need to do the screen grabs I think.
many thanks,
peteB
From what I can see ; the 2nd time the customer receives the project from us they should use File->Update Project and it will manage the differences. I think the important piece of jigsaw was whether the 2 projects should be kept seperate; and it sounds to me like they should be.
As for the screen shots; then fully appreciate that these need recapturing/generating - the customer is also currently in process of translating our UI to spanish and so they should be quite familiar with this although once they are done; we will need to do the screen grabs I think.
many thanks,
peteB