Key Features Multiple Format Support. To translate the content (SDLXLIFF files) of an SDL project file, you have to take the thing apart.Wordfast Pro is a translation memory tool ideal for multi-platforms and also capable of satisfying the needs of translators and various corporations. The current version 5 of memoQ can't do a thing with these project files, unlike those from Star Transit, where a nicely automated wizard sets up a memoQ project with everything I need except terminology. Open.When a translation request with an SDLPPX (SDL Trados Studio project file) shows up in my inbox, it's always a bit irritating.
Sdlppx file in SDL Trados - MultiTerm. Looked like I was SOOL.how to open. It was sitting on an FTP server to which the PM had failed to give me the access data before the weekend. An error message informed me that the PPT source file for one of the SDLXLIFF resources was missing. But today that didn't work. Vast Translation Memory StorageOf course, if you own an SDL Trados Studio license, it's usually a simple matter to open the package with Trados and export the resources you need.
Open Sdlppx With Wordfast Zip Or Other
I had not noticed this before, because in the past, if the SDLXLIFF file I imported had no segments, I just opened it in SDL Trados Studio, copied source to target and resaved it, and the resultant file imported without trouble and showed all segments. When imported into memoQ it will show zero segments! A look at the same translation unit in the SDLXLIFF file out of the target language folders shows the difference (a bit more than just the target tags highlighted):Die neue MaschinenrichtlinieDie neue Maschinenrichtlinie This second SDLXLIFF file will import fine into other tools like memoQ using the XLIFF filter and allow you to translate without difficulty. This is essentially a monolingual file. Inside the ZIP file, the structure will look something like this:Inside an SDL Trados Studio project package with Source language German (DE) and target language English (UK)Die neue MaschinenrichtlinieDie neue MaschinenrichtlinieNotice anything missing? There is no tag set for target content. These are just ZIP files, so if you take a project file named MyWonderfulSubcontractedJob.sdlppx and rename it MyWonderfulSubcontractedJob.zip you can unpack it with WinZip or other utilities. Sdlppx format sdlppx vs sdlrpx how to open.In the past, when I took these SDLPPX file apart manually to get at the components I wanted, my luck was mixed.
I think you missed an easy route for interoperability with most tools from Studio and not just those able to "read" XLIFF. Most tools can take it from there, and you'll get back your finished SDLXLIFF files to review.Interesting article. If you are part of the 1% of Trados users who have a clue what to do with terminology, export the MultiTerm data, if you have any, to a delimited format of some kind. Send SDLXLIFF files and export the relevant TMs to TMX. I am encountering SDLPPX files with increasing frequency due to the general lack of understanding interoperable workflows by those living in the Trados ghetto, and this added functionality in my primary tool would be a great help.What should an SDL Trados Studio user do to ensure a less troublesome collaboration with those who use other tools? Don't send a damned project file.
Open Sdlppx With Wordfast Update With Your
So, unless there is a proper SDLPPX import/export mechanism, just extracting the SDLXLIFF and the TM may fit in some cases. But the danger to miss them and run into serious problems should not be underestimated. Not to mention AutoSuggest dictionaries, custom spell checkers, custom RegEx checkers etc.Not all of this will be used in all projects, obviously. Also Studio can add multiple TMs to a project, arrange them with priorities and penalties and specifiying which of those TMs to update with your translations and so on. It can also include “project metadata” like deadlines, comments/instructions from the PM to the translator, QA settings, verifyer settings, in case of XML files also things like embedded DTDs/Schemas and along with them validation settings or XSLT(s) for xml preview settings.
The added complexity of things like workarounds required to import many simple XLIFF files to Studio drives me to despair at times, though it does give me the opportunity to earn a bit with consulting. Despite the sophistication of the current generation of SDL's technology, there are simply too many bugs and quirks dealing with it in routine cases I encounter. And in the specific case I mentioned here, I wonder if the missing source file would cause trouble I did in fact open the package with my copy of SDL Trados Studio and I was unable to save files externally. Moreover, the need to own a license to SDL Trados Studio to make use of this option will pose a barrier to a great many of those who need it. Reply DeleteKevin Lossner 10:15 Although your "legacy converter" sounds like an excellent tool, I have serious doubts that converting XLIFF files to ancient proprietary Trados formats is really a sustainable way forward, especially as SDL has announced the "death" of SDL Trados 2007 technology with the next major release of Studio.
The instructions for the job are usually clear in my dealings, typically something like "translate this manual by the end of next week, please". Nor do I particularly care about the internal QA settings I have my own QA profiles configured in memoQ, and I doubt that my clients using SDL Trados Studio even understand how to use those features given some of the small issues they stumble over routinely trying to use that environment. I don't need SDL's AutoSuggest dictionaries to translate the XLIFF file.
The case of a sophisticated client package is an interesting one in theory, but the real cases I encounter can typically be reduced to a very practical solution with just a bit more communication required if additional data are needed. In most cases I have encountered to date, the main need is to get at a translatable file, the SDLXLIFF from the target language folder. The whorehouse TMs one often finds at agencies, where any number of translators have had their way with the data, do not inspire me to give them any priority over my own resources.
Reply DeleteOf course it isn't the way forward. Translators and their customers deserve better than that. They are mostly straw arguments heaped under the stake to which some would see interoperability and user-friendly collaboration tied and burned. I can trick out previews with an XSLT transform myself if I really feel the need, but usually a decent PDF to show me the layout of the original will suffice for context.Everyone can come up with endless excuses why Tool X absolutely must be used for a particular task, but I seldom find that these arguments hold for typical cases.
0 kommentar(er)
