It occurs to me...
Aug. 5th, 2011 08:58 amThe Wordfast translation memory package lives inside a Word template, so essentially the only thing running when you use the product is Word. This lends a lot of inertia to the idea of processing a document linearly, from the beginning all the way to the end.
That's not much of a problem, except that more often than not, the structure of a document results in better progress in some places (and worse in others), depending on what's under your cursor.
For example, tables of numbers really require very little effort to translate (generally, there are column headings and—in my practice—a need to change the decimal delimiter from a comma to a period). Otherwise, pretranslated segments require—ceteris paribus—a modest effort as compared to new text.
I mentioned the other day how the (inadvertently found) ability to address only pretranslated segments is a plus. Edit them, and then when you import a "clean" file (one with no pretranslated segments), the edited segments are filled in by the software.
I noted yesterday how sorting from shortest to longest string allowed me to determine that more than half of the segments generated by memoQ from the clean document are short items (e.g., numbers, section numbers, equation numbers, short mathematical expressions, etc.). That gave me a modicum of peace of mind, but did not address my principal concern at this point in the project, i.e., making sure I make enough progress early on in the project to assure on-time delivery.
You see, given the nature of the beast, progress can't be measured in terms of translating x segments per day, because of the way they're mixed up. As an extreme example, if I decide to address 700 segments per day and run into a section where there's a table with 700 numbers in it, that's not a day's work. The issue is never as clear cut, but I digress...
The solution to my problem is to sort the segments in the other direction, from longest to shortest, and then start translating from the top of the list. This should result in some difficult days up front, where I'm only translating new text, but it will apply my efforts to best effect.
And now, to work!
Cheers...
That's not much of a problem, except that more often than not, the structure of a document results in better progress in some places (and worse in others), depending on what's under your cursor.
For example, tables of numbers really require very little effort to translate (generally, there are column headings and—in my practice—a need to change the decimal delimiter from a comma to a period). Otherwise, pretranslated segments require—ceteris paribus—a modest effort as compared to new text.
I mentioned the other day how the (inadvertently found) ability to address only pretranslated segments is a plus. Edit them, and then when you import a "clean" file (one with no pretranslated segments), the edited segments are filled in by the software.
I noted yesterday how sorting from shortest to longest string allowed me to determine that more than half of the segments generated by memoQ from the clean document are short items (e.g., numbers, section numbers, equation numbers, short mathematical expressions, etc.). That gave me a modicum of peace of mind, but did not address my principal concern at this point in the project, i.e., making sure I make enough progress early on in the project to assure on-time delivery.
You see, given the nature of the beast, progress can't be measured in terms of translating x segments per day, because of the way they're mixed up. As an extreme example, if I decide to address 700 segments per day and run into a section where there's a table with 700 numbers in it, that's not a day's work. The issue is never as clear cut, but I digress...
The solution to my problem is to sort the segments in the other direction, from longest to shortest, and then start translating from the top of the list. This should result in some difficult days up front, where I'm only translating new text, but it will apply my efforts to best effect.
And now, to work!
Cheers...