• State Verified Answer
  • Replies 32 replies
  • Answers 1 answer
  • Subscribers 433 subscribers
  • Views 24687 views
  • Users 0 members are here
Options
Related

The 'cf' start tag on line 1 position xxx does not match the end tag of 'P'. Line 1, position xxx.

Elisa Wenceslá

Hi all,

I'm having this recurrent error message when trying to back convert some files, especially Word files:

I have found ways to "solve" the issue by reprocessing and retranslating the source file, saving the source from docx to doc, etc. but this is not the ideal situation as most of the time I end up with lose of leverage, tag differences, etc.

This is similar to other error messages that are also solved by changing the file format (docx to doc, etc.) and can be spotted doing a pseudotranslation and back conversion test before the real translation. However, this particular error is not always spotted in advance.

This happens both in Studio 2014 and 2017, and whenever I click on the error message Studio may take me to a segment where there's nothing to solve (even if I just copy source to target to make sure it's just like the original, the error persists) or it takes me to the very first line of the file: the file type definition.

Any ideas, please?

Thanks!
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
  • 0

    Hi ,

    This message would normally indicate that closing tags are not in the correct order in relation to the opening tags order, e.g. a closing <\cf...> tag has been deleted or it and/or a closing <\p...> tag is in the wrong place.

    I presume you run a tag verification on the SDLXLIFF file?

    If the tags look identical source to target, this may mean the error is already present in the document before it is converted to SDLXLIFF then it would possibly not get picked up by the verification. The changing to .doc or docx would most likely tidy the tags so the file works smoothly. If you want to correct the tags in the sdlxliff file itself, you would have to use the All content display filter to see if you can spot any closing tag that is not in the correct order related to the opening tags, or any other content that would prevent the tags being in the correct order for saving to Target.

    It is always possible that the error message is not precisely correct.

    A method I used to employ to smooth out unwanted tags in DTP files was to highlight the whole document or section that was causing problems then change an overall property (I can't remember which - Language maybe) then change it back to what it should be (not via undo). This would then remove tags that were not needed. I think I recall  recommending someone to use this method. Maybe he can help here.

    All the best,

    Alison
  • 0
    What I see as fundamental and No. 1 problem is the absolutely USELESS and cryptic message - neither the line number, nor the position number reflect anything what the USER can find and fix anywhere in the file.

    Such information for developers could be transmitted in the background as telemetry error report, but should not be shown to the user sinc it's of no help whatsoever.
  • 0 in reply to Alison Field

    Hi Alison,

    Thanks for your message

    Unknown said:

    This message would normally indicate that closing tags are not in the correct order in relation to the opening tags order, e.g. a closing <\cf...> tag has been deleted or it and/or a closing <\p...> tag is in the wrong place.

    Not in this case, I'm afraid...

    Unknown said:
    I presume you run a tag verification on the SDLXLIFF file?

    Yes, the tag verification was run and there are no tag issues in the sdlxliff. This is the first thing we always check. Besides, this problem has happened with short and long files, with and without any tags.

    After running the verification at first, you get the usual messages:

    And after you try to back convert the file, the new error is added:

    When you click on that error, it takes you to the beginning of the file, not a particular segment but just the beginning: the file type definition.

    I would think this is related to the structure of the source file somehow but when you reprocess the file, everything works fine, so it does not make sense that the structure is wrong at first but then just fine...

    Regards,
  • 0 in reply to Evzen Polenka

    Unknown said:
    What I see as fundamental and No. 1 problem is the absolutely USELESS and cryptic message - neither the line number, nor the position number reflect anything what the USER can find and fix anywhere in the file.

    I tried by opening the sdlxliff in a text editor and search for the position indicated in the message to no avail...

    Unknown said:
    Such information for developers could be transmitted in the background as telemetry error report, but should not be shown to the user sinc it's of no help whatsoever.

    Couldn't agree more...
  • 0 in reply to Evzen Polenka
    Ah yes, thank you Evzen,

    I forgot to point out that the line numbers don't refer to the segment numbers in the SDLXLIFF.

    Am I right in remembering that they refer to the line in the original format file, Evzen?

    If so, that would be possible to find the line using Ctrl+G in Word (or for XML in Notepad) for example...

    I have certainly been able to do this when I've needed to but I realise that messages like that are gobbledegook to some users.

    All the best,
    Ali :)
  • 0 in reply to Alison Field

    Yes, as I mentioned to Evzen, I also tried by opening the sdlxliff in a text editor and search for the position mentioned in the error message, but this is not easy for a Studio user (not a developer) when you just find "73h8cp2n9GubIVnFyo847IwpLDyzYBWmRJPsjWN+MaYXViiZ2EsVd/RCACsQ3+JQZI1cIOOKAjPp"... :-/
  • 0 in reply to Elisa Wenceslá
    Unlikely you'll find this on line 1... but I get your point. We are working on this to try and provide improved ways to report messages, to get the information to us, and to make it easier for users to find solutions. Part of that work will be delivered in the next update to Studio 2017 but there is a bigger project underway to improve this further.

    It's not always easy to report something sensible as the message sometimes comes from somewhere completely unexpected in the computer, in addition to which we now have apps that can also cause issues where QA will never find them, and also third party applications that can interfere with the way the software goes about its business.

    When the message is about an sdlxliff like this the reference to the location is more likely to be to a place in the underlying code so it won't help you at all... all we can do at the moment is try to use the main theme of the error that you can search in the knowledgebase and hopefully find a solution or report the error to support with the full error stack.

    Paul Filkin | RWS Group

    ________________________
    Design your own training!
    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

  • 0 in reply to Alison Field

    Hi again Elisa,

    Evzen and I were discussing in another thread the differences between SDL Trados Studio 2017 and Trados 2007. 

    As a matter of fact, in Trados 2007, one could search for such an error in a TTX file, using the line AND position number and choosing whether to search for its position as in the source file, the target file OR the bilingual file so although the error message back in 2007 would have still been the same, one had the search facility to find it without leaving the TTX file.

    I sometimes use Trados 2007 still if I really can't find a difficult error that Studio has not 'seen' because it was in the original file in the first place but the end format processing indicates it is there and causing a Save as Target error.

    Microsoft Word is particularly good at causing these sort of error messages. As you suggest, Elisa, it is always a good idea to double-check that the Word file will save as Target before translation. If not, then it's the Word file at fault and it needs to be sorted before converting to SDLXLIFF.

    Maybe another workaround would be to create and work in a bilingual Word file using SDL Legit! This app can be downloaded here:

    http://appstore.sdl.com/app/sdl-legit/299/

    Or if it's something from the Word file that is being converted in such a way that it has changed to an unacceptable entity that won't convert back to Word, you could protect it by using a TTX file which you'd then convert to SDLXLIFF as usual. I used to do this for older format Desktop Publishing files a few years back. The above app can be use for that, or also SDL TTX It! downloadable here:

    http://appstore.sdl.com/app/sdl-ttx-it/1/

    I realise how frustrating this is for you and you're neither the first nor the last to have these problems. They're not easy to foresee and program for because the rules and performance of the individual formats and their conversion aren't governed by Studio's software alone.

    It would appear that you already know about the possible workarounds and I don't think anyone would be able to solve this further.

    However, it would be good to suggest that error messages be more appropriate for the individual user to understand.

    All the best,

    Ali
  • 0 in reply to Alison Field
    Hi Alison,

    Thanks very much for your message.

    I guess we will continue reprocessing the files whenever we find this error message, although it would have been nice to have a clue about what might be causing this kind of errors to try and avoid them.

    Thank you all for your time as usual! :-)

    Kind regards,
  • 0 in reply to Elisa Wenceslá
    When I get these error messages with line and position numbers, I sometimes use Notepad++ to look into the sdlxliff file.

    Notepad++ shows you which line you are on in the file and also shows how many characters into the line the cursor is (i.e. the "position"), so you can simply move the cursor along the line until you find the position indicated in the error message. (It helps to turn on line wrap.)

    Of course, once you find the spot it can sometimes be difficult to interpret the tags, but at least it gives you an idea of where the problem is occurring.

    Best regards,
    Bruce Campbell
    ASAP Language Services