Archive

Tag Archives: filetypes

The origin of Chad (if you’re British) or Kilroy (if you’re American) seems largely supposition.  The most likely story I could find, or rather the one I like the most, is that it was created by the late cartoonist George Edward Chatterton ‘Chat’ in 1937 to advertise dance events at a local RAF (Royal Air Force) base.  After that Chad is remembered for bringing attention to any shortages, or shortcomings, in wartime Britain with messages like Wot! No eggs!!, and Wot! No fags!!.  It’s not used a lot these days, but for those of us aware of the symbolism it’s probably a fitting exclamation when you can’t save your target file after completing a translation in Trados Studio!  At least that would be the polite exclamation since this is one of the most frustrating scenarios you may come across!

At the start of this article I fully intended this to be a simple description of the problems around saving the target file, but like so many things I write it hasn’t turned out that way!  But I found it a useful exercise so I hope you will too.  So, let’s start simple despite that introduction because the reasons for this problem usually boil down to one or more of these three things:

  1. Not preparing the project so it’s suitable for sharing
  2. Corruption of a project file
  3. A problem with the source file or the Studio filetype

Not Preparing the Project so it’s Suitable for Sharing

I’m only going to address the most common issues that relate to how the project has been prepared.  This usually comes down to one or more of these things:

  1. not embedding the source file into the SDLXLIFF when it’s prepared
  2. not having the same filetype that was used to create the SDLXLIFF when it’s prepared

These two things can be explained further, so if you’re still interested in more detail keep reading!

1. not embedding the source file into the SDLXLIFF when it’s prepared

This could be something you are not even aware of, but by default Studio will try to embed the source file into the SDLXLIFF itself whenever you create a project.  It’s controlled with this option in your Filetype options for SDLXLIFF:

As long as the source file is no larger than 20Mb it will be automatically embedded.  If the source file is larger than this, or this setting was changed to reduce the size of the files being sent out, then the source file will not be embedded. The effect this has on the SDLXLIFF is exactly the same whether you create a full project in Studio or if you just use the “translate single file” approach.  In case you are under the illusion that you don’t work with projects note that the “translate single file” approach still creates a project… it has less capability compared to a “standard Studio project” but it’s still a project.  I’ve written various articles on this topic in the past if you want to delve into this topic more.  But I don’t wish to digress… so the main difference where the SDLXLIFF includes the source file because it’s been embedded is that you can see it within the internal-file element as an encoded text.  Open an SDLXLIFF with a text editor and you’ll see what I mean.  This one is based on a small XML file I prepared with the default settings shown above:

The SDLXLIFF for the same file prepared by setting the Maximum embedded file size to zero is shown below, and it displays references to the source file in the external-file element as opposed to the actual file itself:

There are a few more small differences but the main point I wanted to demonstrate is this concept of the source file actually being inside the SDLXLIFF as opposed to just being referred to in the second example above.  Why is this important?  It’s important because if the SDLXLIFF files are shared on their own and the source file has not been embedded into the file then you will see something like this when you open the SDLXLIFF in Studio on another computer:

This message will appear whether you received these files as part of a project package or as single SDLXLIFF files.  It’s purely a question asking you if you would like to go and find the file that has been referenced in the external-file element.  If you also have the original source file then you can say “Yes” and that might” (I’ll come back to this point) allow you to save the target file from your project.  If you say “No” then you are going to be seeing these sorts of things in Studio when you get around to saving the target:

Note that you have two messages in the QA window now, one relating to the lack of a dependency file when you initially opened the file and the second relating to an inability to save the target file when you tried it because of the first error.  Hopefully this is clear by now that all these errors are to be expected because the project has not been created in a way that would allow Studio to work correctly, and you have not helped because you didn’t have the original source file available when needed.  These are not bugs at all because in this scenario you are dealing with an incomplete Studio project.  It’s unfortunate that the error message looks like something that is a problem with Studio because in this scenario a less emotive experience could be enjoyed if the messages were more explanatory and didn’t include the visual stimulations they do!

I’d like to say that always using a Project Package to share work would provide a resolution to this situation of the source file not being embedded in the SDLXLIFF files, but it won’t.  The source files are not included with the project package at all, even if the files are not embedded.  The only way to address this when using project packages is to either add the original source files as reference files, or send them separately.  I think there should be an option to include them when the project package is being created, particularly as this can also affect the ability to preview the files even if you don’t need to save the target… but then preview is another story!

Exceptions

As always there are some exceptions around the embedding of files.  If the source files are text files (TXT) or PO files for example, then they are never embedded.  So, for these formats you won’t find the reference element referring to the source file at all, and for the most part you shouldn’t have problems saving target files.  However, the next section could influence that if the filetype that was used to prepare the file in the first place is not available.

2. not having the same filetype that was used to create the SDLXLIFF when it’s prepared

In the previous section I said “that might” allow you to save the target file from your project.”.  The reason I said this is that if the files were prepared using the out of the box filetypes for Studio then you should be able to successfully save the target file.  But if they were prepared using a custom filetype, either by using the filetype features in Studio for this, or through the use of a plugin created using the API, then you still won’t be able to save the target unless you also have this filetype available to you in your project settings.  You will get a message something like this… which is at least a little less alarming than the message about the dependency files in the previous section:

This one can normally be resolved by using project packages because the custom filetype should be included in the project and therefore available for use.  However, this won’t work if the filetype is a custom plugin that you might find on the SDL AppStore for example, or if the filetype is not available at all in the version of Studio used to open the package.  For example, one of my test projects uses the following out of the box filetypes in Studio 2019:

If I create a project package and send this to a user of Studio 2014 then they will see something like this:

Note that the Excel file and the Word file are unidentified in Studio 2014.  This doesn’t mean I can’t translate the files and create a return package because I can.  But it does mean that I won’t be able to save the target file, or preview the files where it would be possible with an older version.  The same problem works the other way… if I create a project in Studio 2014 using filetypes that have been deprecated in Studio 2019 then I will have a similar situation.  In both scenarios 2014 -> 2019 and vice versa, I’ll get the information message telling me Studio can’t save the target file and why.

The path to project success

I wrote the title to this section right at the beginning with an idea in my head to create a flowchart, or something like that, which would show you the best way to work and always achieve success.  But as I worked through all the different scenarios, and I’m pretty sure there will be others I missed, it’s clear that the only way to ensure you will avoid this all of the time depends on understanding the variables in your translation process.

  • Is everyone using the same version of Studio?
  • Are you working with custom filetypes?
  • Were your custom filetypes created using the API or using the UI in Studio (custom XML or regex-based text files for example)?
  • Do you have a Professional licence (to be able to create a Project Package) or a Freelance licence (only work with the SDLXLIFF files)?
  • Do you need the translator (or person you are collaborating with) to be able to create a target file or will you do this yourself?

Once you have identified the variables you will know the following:

  • what instructions to provide the recipient of your files
  • how to prepare the project in the first place
  • whether you need to provide additional resources in a project package
  • what to expect from the recipient of your files

In fact, not too many things.  However, you do need to understand them if you want to have a successful workflow and I have a suspicion that the out of the box courses won’t prepare you for this.  It’s more likely to be an on the job experience!

Corruption of a Project File

The second one doesn’t happen very often and I’m not really sure how this happens.  When referring to a bilingual file in the project (an SDLXLIFF) I could hazard a guess that one reason is it’s related to security software (anti-virus checks, clean-up tools etc.) running while Studio has a file open for translation, or perhaps something happened to the file when transferring from one machine to another, maybe even between a MAC and a Windows system… or with a dodgy connection between drives… or even something in an email transfer.  But I’m guessing.  These sorts of problems are not anything we can address easily (other than to recommend you zip up project files before sharing) as they occur outside of Studio and are related to factors beyond our control.

Another reason could be a bug within Studio affecting you in two ways.  The first is that a project where the file could be successfully saved at the start suddenly fails at some point during the project.  I’m not sure what causes this either… it might be due to problems associated with security software again that corrupts a bilingual file (an SDLXLIFF), or perhaps the SDLPROJ file which contains metadata helping to manage the project resources… but at least this one is easily resolved.  You can prepare the project again from the original source file (if you have it) and pretranslate the project from your TM (or use PerfectMatch… although I’ve found PerfectMatch can sometimes reproduce the same issue perfectly!!), then save the target file.

A problem with the source file or the Studio filetype

If you can’t save the target file immediately after creating the project, which is the second way a bug within Studio can affect you, then the problem is either with the source file or the Studio filetype and in these cases you should not try to complete the translation until you have resolved this problem as it may be wasted effort.  If it’s an Office file, Word, Excel or PowerPoint, then you can try using a different version of the filetype as there are several to choose from and create the project again!  If the problem is with the source file then you can try and identify the problematic part of the file using the tried “divide and conquer” methodology which is a very quick way to find parts of the document you may be able to remove before translation.  This and a few more interesting methods for resolving filetype problems are detailed in this old, but very useful KB article.

Needless to say, if you have problems with the source filetype or the Studio filetypes you should report them through support or the SDL Community… this article refers.

At the beginning of each year we probably all review our priorities for the New Year ahead so we have a well balanced start… use that gym membership properly, study for a new language, get accredited in some new skill, stop eating chocolate… although that may be going just a bit too far, everything is fine with a little moderation!  I have to admit that moderating chocolate isn’t, and may never be, one of my strong points even though it’s on my list again this year!  But the idea of looking at our priorities and setting them up appropriately is a good one so I thought I’d start off 2018 with a short article explaining why this is even important when using SDL Trados Studio, particularly because I see new users struggling with, or just not being aware of, the concepts around the prioritisation of filetypes.  If you don’t understand them then you can find code doesn’t get tagged correctly despite you setting it up, or non-translatable text is always getting extracted for translation even though you’re sure you excluded it, or even files being completely mishandled. Read More

There are well over 200 applications in the SDL AppStore and the vast majority are free.  I think many users only look at the free apps, and I couldn’t blame them for that as I sometimes do the same thing when it comes to mobile apps.  But every now and again I find something that I would have to pay for but it just looks too useful to ignore.  The same logic applies to the SDL AppStore and there are some developers creating some marvellous solutions that are not free.  So this is the first of a number of articles I’m planning to write about the paid applications, some of them costing only a few euros and others a little more. Are they worth the money?  I think the developers deserve to be paid for the effort they’ve gone to but I’ll let you be the judge of that and I’ll begin by explaining why this article is called double vision!!

From time to time I see translators asking how they can get target documents (the translated version) that are fully formatted but contain the source and the target text… so doubling up on the text that’s required.  I’ve seen all kinds of workarounds ranging from copy and paste to using an auto hotkey script that grabs the text from the source segment and pastes it into the target every time you confirm a translation. It’s a bit of an odd requirement but since we do see it, it’s good to know there is a way to handle it. But perhaps a better way to handle it now would be to use the “RyS Enhanced Target Document Generator” app from the SDL AppStore? Read More

I’m back on the topic of PDF support!  I have written about this a few times in the past with “I thought Studio could handle a PDF?” and “Handling PDFs… is there a best way?“, and this could give people the impression I’m a fan of translating PDF files.  But I’m not!  If I was asked to handle PDF files for translation I’d do everything I could to get hold of the original source file that was used to create the PDF because this is always going to be a better solution.  But the reality of life for many translators is that getting the original source file is not always an option.  I was fortunate enough to be able to attend the FIT Conference in Brisbane a few weeks ago and I was surprised at how many freelance translators and agencies I met dealt with large volumes of PDF files from all over the world, often coming from hospitals where the content was a mixture of typed and handwritten material, and almost always on a 24-hr turnaround.  The process of dealing with these files is really tricky and normally involves using Optical Character Recognition (OCR) software such as Abbyy Finereader to get the content into Microsoft Word and then a tidy up exercise in Word.  All of this takes so long it’s sometimes easier to just recreate the files in Word and translate them as you go!  Translate in Word…sacrilege to my ears!  But this is reality and looking at some of the examples of files I was given there are times when I think I’d even recommend working that way!

Read More

A nice picture of a cutie cat… although I’m really looking for a cutie linguist and didn’t think it would be appropriate to share my vision for that!  More seriously the truth isn’t as risqué… I’m really after Qt Linguist.  Now maybe you come across this more often than I do so the solutions for dealing with files from the Qt product, often shared as *.TS files, may simply role off your tongue.  I think the first time I saw them I just looked at the format with a text editor, saw they looked pretty simple and created a custom filetype to deal with them in Studio 2009.  Since that date I’ve only been asked a handful of times so I don’t think about this a lot… in fact the cutie cat would get more attention!  But in the last few weeks I’ve been asked four times by different people and I’ve seen a question on proZ so I thought it may be worth looking a little deeper.

Read More

001Years ago, when I was still in the Army, there was a saying that we used to live by for routine inspections.  “If it looks right, it is right”… or perhaps more fittingly “bullshit baffles brains”.  These were really all about making sure that you knew what had to be addressed in order to satisfy an often trivial inspection, and to a large extent this approach worked as long as nobody dug a little deeper to get at the truth.  This approach is not limited to the Army however, and today it’s easy to create a polished website, make statements with plenty of smiling users, offer something for free and then share it all over social media.  But what is different today is that there is potential to reach tens of thousands of people and not all of them will dig a little deeper… so the potential for reward is high, and the potential for disappointment is similarly high.

Read More

001One of my favourite features in Studio 2017 is the filetype preview.  The time it can save when you are creating custom filetypes comes from the fun in using it.  I can fill out all the rules and switch between the preview and the rules editor without having to continually close the options, open the file, see if it worked and then close the file and go back to the options again… then repeat from the start… again… and again…   I guess it’s the little things that keep us happy!

I decided to look at this using a YAML file as this seems to be coming up quite a bit recently.  YAML, pronounced “Camel”, stands for “YAML Ain’t Markup Language” and I believe it’s a superset of the JSON format, but with the goal of making it more human readable.  The specification for YAML is here, YAML Specification, and to do a really thorough job I guess I could try and follow the rules set out.  But in practice I’ve found that creating a simple Regular Expression Delimited Text filetype based on the sample files I’ve seen has been the key to handling this format.  Looking ahead I think it would be useful to see a filetype created either as a plugin through the SDL AppStore, or within the core product just to make it easier for users not comfortable with creating their own filetypes.  But I digress…

Read More

%d bloggers like this: