• State Suggested Answer
  • Replies 22 replies
  • Answers 6 answers
  • Subscribers 437 subscribers
  • Views 12958 views
  • Users 0 members are here
Options
Related

Problem with WordprocessingML v. 2 file type

Fabio Gagliardi

Hello,

We have some difficulties with the new file type „WordprocessingML v. 2“ for Microsoft Word 2007-2016 in Trados Studio 2017. Here some examples:

  1. We had a project a few days ago, where a normal text, as in the first screen shot below (Word), was turned into a tag in Trados, as in the third screen shot below (Trados), and therefore was not translated by our linguist.

But when using the „Word 2007 v. 2.0.0.0“ file type by unchecking the „WordprocessingML v. 2“ in the file type’s overview before loading the document into Trados, we did not have this problem, as you can see in the screen shots below.

 

 

  1. Also, sometimes when we create a project using this file type, Trados won’t allow us to create a target file after finishing the translation process (error message: "This file was created using a file type definition that does not exist on your system"). We then had to uncheck this file type in the menu for Trados to automatically choose the „Word 2007 v. 2.0.0.0“ for the docx-file and pre-translate it by choosing the corresponding translated file, what also meant we had to check all the segments due to differences in tags and formatting.

To avoid this kind of additional work, we just left the „WordprocessingML v. 2“ file type unchecked for all new projects and used the „Word 2007 v. 2.0.0.0“, which worked just fine for all .docx files.

Unfortunately, with today’s Trados Update SR1, this file type is no longer available (see screen shot below).

We hoped, that maybe the „WordprocessingML v. 2“ file type was updated and fixed, so we tried the above described project once more, but still got the same “text-to-tag-problem” as before.

Is there any way we/you can fix this file type? Or would it be possible to regain the „Word 2007 v. 2.0.0.0“ file type?

Thank you in advance!
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
Parents
  • 0
    I'd also like to echo that we have a lot of freelance translators that use older versions of Trados Studio, and do not have access to this new filetype, and we rely on them running QA tasks to ensure errors are fixed, which they are now unable to do. We would find it preferable if the either the old filetype is included in Studio 2017 to support those translators, or that the new filetype was provided as an update to the older versions so they can continue to function fully. These little changes cause ripples which have sometimes fairly significant impacts on our workflows.
  • 0 in reply to Darren Ki-Fun
    Hi ,

    The old file type is available but hidden, to ensure that we can provide support such as save as target, preview, etc. when a Studio 2017 user receives packages or sdlxliff files created with the older version. The only thing you cannot do in 2017 is to create a new project with the older filetype.

    We don't intend to do any more work on this old filetype and it has been replaced by the new one as there were too many limitations in being able to support many of the things users have been asking for to support features in the ever expanding Microsoft Word. If we were to retain the old one and you started to find that you were getting files that could not be processed with it then what would you expect us to do? We wouldn't fix it because this is what the new filetype is for.

    I think the answer to this conundrum is for users to upgrade their software and use a version that supports the filetypes we are currently using OR they just handle the SDLXLIFF for translating, ignore the warning messages, and you deal with the finished translation when complete.

    Regards

    Paul

    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

Reply
  • 0 in reply to Darren Ki-Fun
    Hi ,

    The old file type is available but hidden, to ensure that we can provide support such as save as target, preview, etc. when a Studio 2017 user receives packages or sdlxliff files created with the older version. The only thing you cannot do in 2017 is to create a new project with the older filetype.

    We don't intend to do any more work on this old filetype and it has been replaced by the new one as there were too many limitations in being able to support many of the things users have been asking for to support features in the ever expanding Microsoft Word. If we were to retain the old one and you started to find that you were getting files that could not be processed with it then what would you expect us to do? We wouldn't fix it because this is what the new filetype is for.

    I think the answer to this conundrum is for users to upgrade their software and use a version that supports the filetypes we are currently using OR they just handle the SDLXLIFF for translating, ignore the warning messages, and you deal with the finished translation when complete.

    Regards

    Paul

    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

Children
  • 0 in reply to Paul
    I understand the necessity to move with the times, and appreciate that what is being asked may be stretching the possibilities of software compatibility, but I also cannot rely on freelance translators to keep up to speed with each new studio version or have the luxury of picking only the most up to date Studio users - this has never been a realistic prospect, even when, as we do, encourage upgrading whenever we can. We cannot fully control adoption rates.

    In the situation you describe above, my thought would be that having the filetypes available provides some degree of damage limitation at least - we need to maximize the number of users who we can work with, employing our workflows fully. Having access to filetypes, old and new, could allow them to work with our projects fully, if they do happen process correctly. Prior to SDL removing the old filetype for SP1, this was how it was working. If, as you say, the new source document doesn't work properly with the old filetype, then obviously we're back to the same problem again. I think it's completely understandable not to expect a fix for old filetype support, so a workaround would be necessary. But the key here is to reduce the number of times you need to use this workaround.

    Implementation of a robust, built-in QA process is a something I very much want to implement into our Studio workflows. If we cannot guarantee our translators can even run QA after translation, or trust that this will be the case for the other filetypes SDL are currently updating, then we have an immediate roadblock to this concept. Our current situation, is to do as you suggest, dealing with the QA internally after translation, but this itself is not sustainable in the long term as it creates a big bottleneck and places responsibility for linguistic decisions with the wrong group of people, at the wrong time. Perhaps time will see enough people upgrading to render the problem obsolete, but in the meantime I think I will need to look into alternative options, but thank you for replying.
  • 0 in reply to Paul
    Paul, "not supporting" something is fundamentally different from "not allowing to use" :( This is just completely twisted way of thinking, sorry.
    No one will ask you to provide fixes/improvements if you clearly state that it's obsolete and unsupported. But why on earth should be people NOT ALLOWED to use it if they want, if it works just fine for them and if they do not need any extra features?!?!?!?!

    Is Microsoft DISALLOWING anyone to use Windows XP?!?! No, it's not... despite the fact that it's not supported for quite some time, quite a number of users is happily using it since it's good enough for their purposes!
  • 0 in reply to Paul

    Unknown said:
    I think the answer to this conundrum is for users to upgrade their software

    If the software upgrade is FREE or for SYMBOLIC fee, then this would be a legitimate answer. But the upgrade is NOT FREE, it costs a lot actually.

    Sorry, but such "smart recommendations" usually come from people who don't really know how much money this means in real world... usually because they never had to pay it (for the software they talk about).
    Just wondering - did you actually PAY for the Studio licenses you use? I doubt so, because you obviously use some internal company licenses. One then very easily forgets that others have to pay real money...

    Studio is not antivirus software where one gets all new releases within one's subscription period for free...
  • 0 in reply to Evzen Polenka

    Unknown said:
    Sorry, but such "smart recommendations" usually come from people who don't really know how much money this means in real world... usually because they never had to pay it (for the software they talk about).

    Of course... I get every piece of software I own for free and don't have to pay for anything.  Here at SDL we live in a bubble completely sheltered from the rest of the world and just go about our business in a dream like state.  Even the software on my personal computer is all for free!

    In all seriousness Evzen, I have told you before that it helps to build a case for anything we need to change.  And you fight me on every single thing I ever do.  You are your own worst enemy!  It would be enough for you to make a reasoned response as Darren did, but you make me not want to help you at all!

    And another thing I find quite incredible is that people don't take a support contract.  If this is your professional business and you need to rely on it then why would you not pay half a euro a day to support it and then you get all the benefits of updated software and access to support.  When you look at it like that there is no excuse for not being able to upgrade even when I consider it from my position up here in the ivory dreamland.

    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 Paul

    Unknown said:
    Of course... I get every piece of software I own for free

    Note the part I wrote in brackets... That's what I was talking about.

    Unknown said:
    And you fight me on every single thing I ever do.

    It's not really my fault that you seem to miss the core point of my notes and only see in them something what's not there.

    So back to the point... I understand the need to "support only newest stuff"... it lowers development costs, etc... I know all that, no need to explain this.
    And I agree with that, these are all legitimate reasons.
    BUT!
    You simply can't start enforcing users to upgrade every time WITHOUT CHANGING THE LICENSING...
    If you don't change the licensing to subscription model - like e.g. the malware companies did years ago, just because they had the same problem with keeping the users on the newest technologies - you can't scrupulously ask users to pay (pretty high) money for upgrade every time you release one.

    It's as simple as that - you want to keep only one codebase and simplify development? Change the licensing mechanism to subscription and then you can do it!

    Pushing users to spend money for upgrade this way is simply bad and immoral, no matter how good intentions there may be in the background.

    Unknown said:
    And another thing I find quite incredible is that people don't take a support contract

    And I find quite "incredible" this mafia-like practice to want users to pay for the right to report bugs, which should have been found and fixed during development already.
    As I said in some other thread, the company I work for did not renew support contract simply because it was useless... We don't have stupid noob questions like "where is my file?", so no need such kind of support... and the real complex technical problems we tried to solve via support were obviously too much for the support... the poor support guy simply was not able to understand what our guys are talking about...
    And the support contract is not cheap either, so the decision was pretty clear...

    If it's an EXTRA support (i.e. not some "how to use computer" for translator noobs) AND is reasonably priced AND one gets some extra service for the extra money (e.g. hotfixes for complex problems, etc.), then I find it a good idea and something worth using. But I'm afraid we are not there...
  • 0 in reply to Paul

    Forgot this one...

    Unknown said:
    It would be enough for you to make a reasoned response as Darren did

    Sorry, but if it's really necessary to explain the obvious (as Darren did) to people who are expected to already know that by the nature of their jobs, then something is really weird.

    What kind of weird world is it where I'm seriously asked to explain an electritian that electricity can kill him... or explain a taxi driver that red traffic light means "stop"? :-O
  • 0 in reply to Evzen Polenka
    I believe my post covered pretty much the same ground as your own first one. Just not as charmingly worded as your, perhaps. Best of luck trying to get this issue fixed through the tactic of random hysterical abuse though.
  • 0 in reply to Paul
    Dear Paul,

    I wanted to mention another reason for keeping the old file type in SDL Studio 2017 SR1 (perhaps it can be restored in the next CU8 or could it be made available through the AppStore?):

    An organisation with a number of internal translators which is planning the upgrade from Studio 2014 to Studio 2017 SR1 might want to use a staggered approach to minimize the risks of issues during the roll-out.

    In this situation, there might be a time frame in which some systems will have Studio 2014 and some other systems will have Studio 2017 SR1. With the current situation, this lack of interoperability makes the situation more complicated. during the roll-out period.

    You might argue that there are alternatives: Studio 2014 and Studio 2017 can be kept in the same PC for a period of time, contingency plans can be arranged, etc. but at the end of the day, all this costs time (which means money). Something which could be easily avoided if both versions were more compatible.

    One should expect that the period with a mixed environment should be short but then again, IT policies and procedures are a world of their own.

    Just my two cents to show another possible use case.

    Daniel
  • 0 in reply to Daniel García Magariños
    Thanks ,

    Notifying and in case they wish to engage with you over this one?

    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 Paul
    Hi - thanks for your off-forum e-mail in the meantime - we'll pick this up off-forum. Thanks, Daniel

    Daniel Brockmann
    Team Trados @ RWS