|Pages in topic: [1 2] >|
Error Converting Document back to Microsoft Word format
Thread poster: Daniel Isaacs
"Position of fields is / are changed across the paragraph of Field insertion is repeated".
I have been trying, unsuccessfully, to get rid of this message for a full 24 hours.
My document was generated from a TIF file that was converted to Word using ABBYY file conversion. The resulting document contains all kinds of errors, most of which need to be ignored because I do not need to repeat them in the translation. The same is true of many of the font effect tabs that appear to have been added.
In addition, there are a few field codes that relate to hyperlinks.
I have faithfully inserted the hyperlink fields where required (even though these are not 100% necessary in my final translation), but not the other tabs, since most if not all of them relate to font descriptions and sizes that are simply wrong for my target. (I translate from Hebrew into English so I don't need to copy over a field tag that defines a Hebrew font into my English document).
Now, there appears to be no way of cleaning the tags from the source document, nor of finding which tags this error message refers to.
This is a 20 page document and almost every sentence in the source has some tag or another, many of which, when I do put them into the English text, show "ghost" endings, and so I don't think that the program is insisting on these.
How can I know which fields are the ones that need to be inserted or corrected? The error message does not point to any specific segment (as would be useful). It just occurs.
This document was due yesterday and every minute of delay is costing me money.
I never had this problem with Trados 8 or any of its predecessors.
Thanks for your help in advance!
I should add - working with Windows XP, Office 2003, SDL Studio 2009.
| The tag verifier shows me 600 "errors" most of which are not at all errors as far as I can see || Mar 20, 2010 |
Thanks for your reply Jerzy.
The problem is that since 99.9% of the tags in question are style and font tags which simply cannot and should not apply in the translation as they do in the source, I can't see the point in putting them into the translation.
On the other hand, there are 600 of them, but I'm pretty sure that only one is the real problem. Do I need to go through and put correct all 600 of these "errors"? Why won't the software tell me which segment the error occurred in? After all, it must know, because it encountered the problem at a particular segment. Armed with that kind of information, I could then easily go and fix the specific problem rather that putting in tags relating to an irrelevant character set into my English document, for no apparent reason.
This may not be a software problem but it is nonetheless a problem as I see it.
| Thanks but I still don't understand || Mar 20, 2010 |
Why should I be actively inserting a tag that says "David 12 point" into a text that is written in Times New Roman 12 point? It doesn't make any sense to do this.
I have, unfortunately, resorted to exporting the TMX back into Workbench and retranslating the document the old way. Perhaps that way is simply better for the language pair I work in. I truly cannot see the point otherwise.
By the way, the only tag settings that were marked in the Word file type settings were deleted tags and tag order, but naturally, I had deleted all of the tags that related only to font style and size. I know this because I use the full text version of the tags. There were also field tags in the document and hyperlink styles which I took care to leave in. But again, my target text does not use David 12 point, so why can't I leave those tags out? They will only corrupt my final document. I do not want a document that my client cannot use because every time they want to enter text, it enters in Hebrew because there's a hidden tag in it that says "David 12 point". Where is the sense in that?
| | Jerzy Czopik
Local time: 21:43
Polish to German
| Formatting tags do not make trouble || Mar 20, 2010 |
That is why I told you to activate just the warning for deleted tags and changed tag order and make sure, that formatting tags are ignored. You MUST do this in this very project, as otherwise the general setting will not apply. It is also possible, that you will need to change this verification setting both in the project itself AND in the general settings.
After you deactivated the checking for formatting tags and left just the deletion and order change active, run the verifier again. This should reduce the messages to those tags, which are indeed relevant.
And BTW, your error message does not say a word about formatting tags, but just field tags - so this is what you will need to find.
BTW, the message says something abou extra inserted fiels - so maybe you now run a check just for ADDED tags?
But did you check, if the original untranslated document does save properly? Or maybe the problem starts already there?
For formatting tags: you may remove them only in pairs, like <David 12 point> and </David 12 point>
You may also delete all hyphens, non-breaking spaces and so on. But you MAY really not delete bookmarks or fields.
| thanks Jerzy! || Mar 22, 2010 |
I will definitely do that next time. I have a feeling that this document was made more complex because it had been scanned from a TIF doc. That probably caused an ungainly addition of tags. Unfortunately, concentrating only on the field and bookmark tags (and ignoring the style tags) did not work. But I gather that in ordinary documents, there will be fewer style tags that need to be taken into account (at least, in the case of word documents). So I'll persevere
Thanks so much for your prompt responses and excellent advice!
| The same problem but without errors, warnings an notes (Trados Studio SP2) || Mar 23, 2010 |
I have checked all the positions of the tags manually
The log file:
Failed to save target content: An error occured while converting fields back to Microsoft Word 2007 Format:Position of fields is/are changed across paragraph or field insertion is repeated.
Sdl.FileTypeSupport.Framework.FileTypeSupportException, Sdl.FileTypeSupport.Framework.Core, Version=18.104.22.168, Culture=neutral, PublicKeyToken=c28cdb26c445c888
at Sdl.Desktop.Platform.Implementation.Services.Log.Resources(Object message, Action action)
at Sdl.Desktop.Platform.Implementation.Services.Job._worker_DoWork(Object sender, DoWorkEventArgs e)
at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)
at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)]]>
SDL Trados Studio
Microsoft Windows 7 Professional
[Bearbeitet am 2010-03-23 19:06 GMT]
[Bearbeitet am 2010-03-23 19:08 GMT]"
[Bearbeitet am 2010-03-23 20:20 GMT]
| I've run into the same problem again! || May 11, 2010 |
Verifying the tags produces no result. According to tag verification, all of the tags are in the right place. I cannot find the problem, in a 40-page document, because Trados won't tell me where it encountered it, so I am supposed to guess. I have been extremely careful about tag placement in this document and I have no idea where it has gone wrong. Once again, I am forced to export the entire TM back into Workbench and translate the entire document, yet again, in MS Word - and why? Because the software won't pinpoint the problem for me. Merely telling me there is a problem is of absolutely no help.
Sorry for venting, but there is no-one to complain to at Trados either. Even their "explanation" for this problem states, and I quote: "The results window will display a list showing those errors and warnings that might prevent finalizing the translation. Not all of these warnings prevent the creation of the target documents, but the messages that refer to missing field tags will do so." - It doesn't say what you're supposed to do when there are NO warnings or errors, but finalization of the translation is nonetheless prevented.
This is getting on my nerves.
Local time: 21:44
Polish to German
| Some tips from experienced user || May 11, 2010 |
Problems will happen with every single cat tool I know. There is no single program out tehre, which does NEVER cause a problem. Having said that, we come back to Trados.
When dealing with bigger and/or complex documents, you should always (and this is really not the FIRST time I recommend that):
- Open the document in you CAT tool as usual.
- Translate some few sentences at different locations in the file, preferably containig tags.
- Try to create the final document. If it works now, it shall and will most certainly work after you're ready with the translation.
- If it does not work, you know now, that your source is corrupted. As you are at the beginning of the project, you can either try to repair the document on your own, urge the customer for a better version and/or longer deadline or even decline the job.
- So far the preparation
When translating the file:
- After you've checked everything works allright, save the bilingual file (simply press the ctrl+s command).
- Translate as usual. Every some segments (I do not know how fast you are - but do it at least every hour or two) stop and try to create the final document. If it works, save the bilingual by pressing ctrl+s.
- If it does not work, close the biligual WITHOUT saving, reopen it and start translating from TM. Stop every few segment and try to create the final file. If it works, save by ctrl+s. If not, repeat the procedure, but reduce the number of segments translated before you try to create the target.
- This procedure will help you to find out which segment is making trouble.
- It is possible, that you will be even forced to leave that particular segment untranslated - but this is a very low price for the security this procedure gives you.
So instead of recreating the whole translation in Workbench, which is ridiculous, try my procedure. Please also take my advice seriously - I work with Trados not since yesterday.
| | Lisa Ritchie
Local time: 21:44
German to English
Thanks for your contributions, Jerzy! My problem was solved by simply pressing F8 and locating the problem segment. I didn't know that before reading your post though.
Thanks again (deadline is in two hours).
| Thanks, Pascal || Apr 11, 2011 |
Thanks for the suggestion on how to track down the error, Pascal - common sense, but common sense isn't always plentiful at 10 p.m. after a long day and with a deadline looming. Your idea proved invaluable.
Daniel, I think you're absolutely right to 'vent' about this, and I don't for a second agree that this is not a software problem. Well-designed software does not spit out unhandled exceptions. Well-designed software doesn't even let you perform the sort of action that leads to this kind of error and, if by chance the unexpected happens, it works a damn sight harder than Trados does to help you find the problem. I've seen this sort of thing too many times with software in other industries - it's a good product trying hard to stay ahead of the competition and in doing so it packs in more and more features too quickly, leaving a trail of unfixed bugs which people just live with. Being the best does not automatically mean that you're good enough. The guys at SDL shouldn't be looking over their shoulders at the rest of the CAT pack, who are equally busy filling their own software with bugs, but wondering what happens to their market share if someone, somewhere writes a CAT tool which performs the core functions with complete reliability. Maybe I should get to work...
| | Lucia Vargas
Local time: 20:44
English to Spanish
| Thanks Jerzy! || Oct 6, 2011 |
Your advice of that procedure of translating little by little and trying to create the target file each time really saved me.
Eventhough I spent almost 3 hours (my file has 28k words), I found it was safe as you said because I would find where exactly the error was (Trados should point at this position and save us such a terrible work): In the end, or I should say from the beggining, I discovered that in my case the problem was this: I manually divided some segments because my OCR program omitted some period marks, but Trados always adds extra format tags to the resulting segments, anyway, I discovered that by not dividing those segments the error prompt would disappear and I could finally create the final target document.
And this is not the first time I have had this kind of problem, but other times Trados tells me which field is missing or I manually find it. Only this time no clue of what was missing so the only solution is your procedure. Before reading this thread I was going to erase all format from the document, retranslate from TM and later apply again bolds, cursives, superscripts, subscripts... maybe 1 whole day of work!
The moral of the story, as you advice, is to better extract only text, and apply format separately.
|Pages in topic: [1 2] >|
To report site rules violations or get help, contact a site moderator:
You can also contact site staff by submitting a support request »
Error Converting Document back to Microsoft Word format
|You've never met a CAT tool this clever!|
Translate faster & easier, using a sophisticated CAT tool built by a translator / developer.
Accept jobs from clients who use SDL Trados, MemoQ, Wordfast & major CAT tools.
Download and start using CafeTran Espresso -- for free
More info »
|SDL MultiTerm 2017|
|Guarantee a unified, consistent and high-quality translation with terminology software by the industry leaders.|
SDL MultiTerm 2017 allows translators to create one central location to store and manage multilingual terminology, and with SDL MultiTerm Extract 2017 you can automatically create term lists from your existing documentation to save time.
More info »