I started thinking about “A room with a view” by E. M Forster when I contemplated how to start this article. But as you can see from the images on the left my mind wandered from this idea and was focused more on the “view”. This is quite possibly because our R&D team started a “Working from home” distance challenge to cover as much distance as you can every day for a month by physically getting out of your office/home and taking some fresh air. A great initiative in these days of working from home where it’s all too easy to never leave your desk! Walking, running, cycling and even swimming were acceptable activities and you get the distance converted into points based on the type of exercise you are doing. You do have to track the activity and you have to take a few pictures as evidence of your efforts… but that brings me back around to my topic for the article… the pictures, or more specifically the views. Yes, this is a very tenuous link indeed with the actual topic which is studioViews!
Contents
What are studioViews?
A “view” in database terms is often the name given to the set of data that is returned when you run a query. studioViews is basically the same thing… you make a query on your project files and the application can create views in the way you asked for them and then you can work on these views separately, eventually using them to update your project when ready. The main difference between studioViews and a view in a database is that Trados Studio doesn’t use a database, so studioViews is all file-based.
The views are particularly useful for these sorts of reasons:
- you have a huge file and would like to break it into bite sized chunks for better performance while translating
- you have a huge file and would like to translate it with colleagues
- you have filtered on your project files so you only have the segments you need to work with and now would like to have these as a single file you can send to others
- you have a project with hundreds of tiny files that were not merged when the project was created. You can virtually merge them, but you can’t save a virtually merged file to share with others.
The application itself can be found in the appstore here and you can also find a useful guide that used to be in the RWS Community (yes… I haven’t mentioned this before in my blog but in case you didn’t know RWS acquired SDL at the end of last year!) and is now in a new documentation part of the appstore. Every app can have documentation tab populated if the developer chooses to do it.
The features…
Before I get into a little detail, even though I don’t intend to delve into each option as the wiki is very explanatory, I should mention three important reasons for creating this app:
- splitting files and merging them back was only possible with SDLXLIFF Split and Merge and this is quite limited in terms of its flexibility for splitting
- SDLXLIFF Split and Merge doesn’t have any capability for merging files at all, only for merging the ones you split to put them back together again
- SDLXLIFF Split and Merge was written many years ago, and it’s a very difficult application to support, and it’s quite easy to break!
Despite this, SDLXLIFF Split and Merge actually has over 13k downloads and it’s a very popular application. So for me studioViews is a very significant development and I wouldn’t be surprised if it’s another application created by the brilliant appstore team that eventually finds its way in the main product.
So, back to the features…
Splitting/merging at file level…
This is straightforward enough. You select one or more of the files in your project in the Files View like this:
Then select the option in your right-click menu to “Split the selected files” which will bring up a window, that may look a little familiar if you’ve used SDLXLIFF Split and Merge before:
Yes… it’s almost exactly the same as SDLXLIFF Split and Merge, and deliberately so! But there are a few differences… so let’s quickly discuss these options:
- the split options are exactly the same as SDLXLIFF Split and Merge
- in this app you can set the “Split by equal parts” to “1” and the app will actually create a single file with all the files you selected. So it basically assumes that whatever you select should be split into what you needed, which in this case would be a single merged file. Very cool and you could not do this before in SDLXLIFF Split and Merge!
- the “Output” offers some new stuff… you can customise the naming convention to use. Also very cool as previously a very long ID was generated for the files and this often caused problems with long file path names as well as having no idea what the file could be related to if it got sent by email without a proper description. Check in the documentation for details, you’ll find it’s really simple!
But by now I can hear you saying…SDLXLIFF Split and Merge also did this:
Yes… indeed it did! BUT… and it’s a capital BUT… I have no idea what the “Check translation correspondence score (percent)” actually does and even when I asked around the users I know who regularly use this application at RWS, including the person responsible for the original development, nobody else seemed to know either!! So, I told the studioViews developer to leave it out and we would address it if anyone ever came back and gave us a good reason for having it. As for the wordcount… on the basis we have the excellent Reports Viewer Plus application now that is far more functional for reporting and extremely fast, we left this out as well. So far nobody has complained!
Now… what about the merge back together? Well, this is the really neat part of this application. You don’t merge the files back together! Instead you select the other option in the right-click menu to “Import into the selected files“. This means you can do things like:
- update your main project as you receive the translated or reviewed files back. No need to wait until you have them all.
- only update certain files
- support the fact users might have split/merged segments before sending them back
- support the use of comments, TQA or tracked changes
- only import parts of the files you want by excluding segment properties (locked), statuses (draft, translation rejected etc.), match type (NMT, Fuzzy Match, New etc.)
It’s a very robust application and far more suitable for working collaboratively or breaking down large files to work on by yourself. But that’s not all!!
Splitting from the Editor…
One of the best features for manipulating files in the Trados Studio Editor is the Advanced Display Filter 2.0. It’s 2.0 because Trados Studio 2021 actually uses what used to be the Community Advanced Display Filter created by the AppStore team which is why you won’t find this on the AppStore for the current version of Trados Studio anymore. It’s excellent being able to filter on almost anything you like, but there wasn’t a very good way to save the data you filtered on as an SDLXLIFF. There is a “Generate” feature that allows you to export the SDLXLIFF but it isn’t foolproof and there are things that will fail depending on how you have filtered and what type of files you had open in the Editor. Fixing this is a major piece of work and the Advanced Display Filter isn’t an app anymore which means we can’t do anything quickly to improve it. So instead we have added the improved functionality to the studioViews app.
You can enable this feature by clicking on studioViews in the View ribbon when you have your files open in the Editor, then position the window wherever you like. I dropped it in with the Terminology windows as it doesn’t need much space and I can just bring it into play when I need it:
Full instructions in the documentation as before but essentially there are two tabs, “Export” and “Import”. The “Import” options are exactly the same as they are for the Files View so I won’t address these again, but the “Export” options are interesting. Just two choices…
- Selected segments
- Visible segments
The “Selected segments” allows you to manually select any number of segments you like in the Editor and then export the selected segments as an SDLXLIFF to work on elsewhere. Very cool, and if you’re struggling with a very complicated filter to get what you want you may be able to get close, and then select all segments, and just deselect the ones you didn’t want. Very cool indeed!
The “Visible segments” option will export whatever you have filtered on. So when you scroll down, whatever segments are visible after filtering will be used to create the SDLXLIFF and export to a location of your choice.
And that’s about it… very simple and short, but a lot of ingenuity has gone into developing this plugin and I’m pretty sure that once more users become aware of the capability it offers we’ll see the number of downloads for this one going up. So if you haven’t already I recommend you take a look at the documentation and then download and install studioViews to have a play. And a quick reminder that since this is for Trados Studio 2021 you can get this through the integrated AppStore, so no need to actually go and get it from the AppStore in a web browser. Just open the AppStore in Studio and start typing studioViews into the search field:
Then click on the “Install” button, restart Studio and you’re done!
The end…
And finally… back to the beginning, the “WFH Distance Challenge”. It ended this week and I’m feeling quite satisfied with myself because whilst I didn’t do the most, I did exceed my target from day one which was 400 km… all walking. So a great way to keep fit, and sane, and enjoy the views… which you can now do in, and out, of the office!
Hi Paul,
Given that there’s always someone ready to complain, I’ll be that someone this time…
I do feel that it is a step backwards from the old Split/Merge add-in that studioViews does not allow to exclude certain statuses from the word count for splitting.
Case 1: there are a lot of projects where we lock segments to exclude them from translation and/or review: existing text in the target language, all number-only segments for annual reports, text from legislation that has already been researched and ‘translated’, etc.
Case 2: some policy document has been updated and we’ve used PerfectMatch to translate and lock the unchanged parts.
In both these cases, when we want to split our large file into equal parts or based on word count, it very much makes sense that these locked segments are not included in the word count used for splitting. So I would expect the split files to be equal in word count for translation, not equal in total word count.
For example, if I want to split into equal parts a 6,000-word file, the last 2,000 words of which are locked, then I would expect to get file 1 with the first 2,000 words and file file 2 with the last 4,000 words (of which only 2,000 need to be translated). With studioViews, I get 2 files of 3,000 words each, with the first containing 3,000 words for translation and the second containing only 1,000 words for translation.
Are there any plans yet to integrate this option in studioViews anyway, or is that still not on the cards?
Best regards,
Lieven
PS: On all other aspects, studioViews is a major upgrade on the old Split/Merge add-in, of course…
I guess you could use the Advanced Display Filter to filter in many more ways and then use the Export Visible segments option to create XLIFF files based on whatever criteria you like.
I now that doesn’t have exactly what you seem to want, but it’s possible to achieve what you want this way.
And no… we don’t have any plans to enhance this plugin at the moment. Too many other things to work on. The app is opensourced though so if yo know a good developer we’d be happy to accept a pull request with the appropriate changes.
Thanks for the info, Paul.
Pity, because it was quite useful to be able to split by volume for translation without having to spend time selecting segments to reach a certain volume.
We’ll just keep using the old Split/Merge add-in for those projects with locked segments where we need to split by volume for translation. And I’ve posted an idea on the Community, so maybe this enhancement will get scheduled some day.
Best
Hi Paul,
Excellent article as always!
Just to let you know that those pesky links to the wiki has broken. RWS redesign at work, i guess….
Thanks Jan… and I just around to fixing them after I needed to refer this article to someone and just read your comment!