Issue using 'Merge Files' feature for reviewing files Tópico cartaz: Atso Puronen
|
|---|
Hi all,
I have projects where I want to use several translators but only one reviewer. Translation is not the problem but reviewing is. Let me show you my workflow:
1. Create and translate a project which has multiple files (I won't merge them since I need to use multiple translators AND merging merged files creates a project meltdown)
2. Create a new project for review purposes (and base it on the current project).
3. Select the bi-li... See more Hi all,
I have projects where I want to use several translators but only one reviewer. Translation is not the problem but reviewing is. Let me show you my workflow:
1. Create and translate a project which has multiple files (I won't merge them since I need to use multiple translators AND merging merged files creates a project meltdown)
2. Create a new project for review purposes (and base it on the current project).
3. Select the bi-lingual sdlxliff files from the main project's target folder as working files.
4. Merge the files using Merge Files in the same dialog. I have named it merged.sdlxliff.
5. Proceed until you get to Task sequences.
6. Select Custom… and select “Copy to translatable format” and “Copy to target languages”.
7. Finish and now you have a review project with one merged file.
8. Review the file in Trados 2009.
9. Run Finalize.
10. Now, Trados SHOULD split merged.sdlxliff back to several files. It doesn't. My separate sdlxliff files are not updated (e.g. modification date has not changed and changes are not there).
If Finalize would work, I would then:
11. Copy those sdlxliff files back to the original project’s target folder.
12. Open the original project and all my changes should be there.
13. Run Finalize to get final files out.
My obvious workaround (and salvation) is that I base my review projects on the main projects. This automatically utilizes same TMs and they get updated already in the review stage. That's why I can just run Pretranslate files on the main project.
I would still like to understand WHY my merged.sdlxliff won't split back to separate sdlxliffs during Finalize? ▲ Collapse
| | | | Jerzy Czopik 
Alemanha
Local time: 18:27
Membro (2003)
polonês para alemão
+ ...
| Run the project | Feb 28, 2011 |
update a TM with the merged SDLXLIFF, then take UNTRANSLATED single files and translate from TM. That is the only solution I can offer for the moment.
AFAIR I also have run in problems trying to edit a SDLXLIFF file in the way you wanted to.
| | | | Emma Goldsmith
Espanha
Local time: 18:27
Membro (2004)
espanhol para inglês
| same problem here | Feb 28, 2011 |
Yes, I needed separate sdlxliffs the other day too, and was only able to produce separate target files and an enormous merged sdlxliff.
I agree this is a problem.
| | | | | Why this process? | Feb 28, 2011 |
Hi Atso,
I'm interested to know why you work this way, unless the answer is because you use Freelance? If I had the Professional edition, and if you are creating work regularly for more translators perhaps this would make sense, then perhaps a better of working would be this:
1. Create and translate a project which has multiple files (unmerged)
2. As you get the files back create review packages and send them to your reviewer, or, wait until you get them all back... See more Hi Atso,
I'm interested to know why you work this way, unless the answer is because you use Freelance? If I had the Professional edition, and if you are creating work regularly for more translators perhaps this would make sense, then perhaps a better of working would be this:
1. Create and translate a project which has multiple files (unmerged)
2. As you get the files back create review packages and send them to your reviewer, or, wait until you get them all back and then create a single review package
3. Review the files in Trados 2009.
4. Run Finalize.
You could even create Word files for review as you go with the SDLXLIFF Converter and then import the reviewed docs with a status of reviewed (this would work with Freemance quite nicely too).
Why do you choose to go the other route? Apologies for my ignorance here if there is an obvious reason I can't see.
I also played a little with the merged sdlxliff idea. I think the reason the files don't save as sdlxliff again is because they already exist as bilingual files and the process of finalizing is intended to produce the finished translation. If you finalise twice, you actually get the target translations. However, I'm not 100% on whether this is by design or not so I will check tomorrow.
Regards
Paul ▲ Collapse
| | |
|
|
|
Atso Puronen
Local time: 19:27
inglês para finlandês
CRIADOR(A) DO TÓPICO
Hi Paul,
I also work with freelancers, but mainly we share projects inside our office. We keep the projects on a shared file server and access them where and when ever we need to. I don't like sending out projects packages inside the office, mainly because it takes translators "offline": we sometimes need to share TMs across projects even though this is not officially supported by SDL. And no, we don't want TM Team or Server since this approach is still working fine (no corrupted TM... See more Hi Paul,
I also work with freelancers, but mainly we share projects inside our office. We keep the projects on a shared file server and access them where and when ever we need to. I don't like sending out projects packages inside the office, mainly because it takes translators "offline": we sometimes need to share TMs across projects even though this is not officially supported by SDL. And no, we don't want TM Team or Server since this approach is still working fine (no corrupted TMs).
I've also used SDLXLIFF Converter for Office with my projects but that has another bug which makes it mostly useless for merged projects: It cannot import back DOCX files which were generated from merged SDLXLIFFs because the segment IDs are not unique anymore. In other words, Segment 23 from file1.sdxliff and Segment 23 from file2.sdlxliff are conflicting in the merged.sdlxliff.
Regarding your question on whether merged.sdlxliff should Finalize into SDLXLIFFs or targets: as my review project source files were 25 SDLXLIFFs, I expect 25 SDLXLIFFs back from Finalize. I would say this is a bug. ▲ Collapse
| | | | | Thinking again I don't... | Mar 1, 2011 |
... think this is a bug.
Hi Atso,
I tested this again this morning. I added three sdlxliff files all with draft translations to a new project as a single merged file, and then confirmed them. Then I Finalised the Project.
The result is that the merged file is no more and I now only have the three sdlxliff files as seperate files in the target folder, all fully confirmed as translated.
Perhaps you only thought they were not produced because th... See more ... think this is a bug.
Hi Atso,
I tested this again this morning. I added three sdlxliff files all with draft translations to a new project as a single merged file, and then confirmed them. Then I Finalised the Project.
The result is that the merged file is no more and I now only have the three sdlxliff files as seperate files in the target folder, all fully confirmed as translated.
Perhaps you only thought they were not produced because they were all there in the first place as part of the project creation process, as usual?
So I actually think this works as intended. Do you see something different when you do this?
I also suggested the SDLXLIFF Converter to you because you specifically said you did not merge projects. In my workflow I did not create two projects as you do. I would also check you are using the latest version of the SDLXLIFF Converter because as far as I am aware it handles merged sdlxliff files too.
Regards
Paul ▲ Collapse
| | | | | One more thing... | Mar 1, 2011 |
Sorry, meant to comment on this part but had to dash off.
Atso Puronen wrote:
I also work with freelancers, but mainly we share projects inside our office. We keep the projects on a shared file server and access them where and when ever we need to. I don't like sending out projects packages inside the office, mainly because it takes translators "offline": we sometimes need to share TMs across projects even though this is not officially supported by SDL. And no, we don't want TM Team or Server since this approach is still working fine (no corrupted TMs).
I wanted to add that this is fine. It isn't ideal for secured performance but we do support it. See this KB article if anyone wants more details on this:
http://kb.sdl.com/article.aspx?article=2550&p=1
For a second I thought you thought I was going to try and sell you something
Regards
Paul
| | | | Atso Puronen
Local time: 19:27
inglês para finlandês
CRIADOR(A) DO TÓPICO | I hate compulsory title fields... | Mar 1, 2011 |
Hi Paul,
For a second I thought you thought I was going to try and sell you something.
Haha! 
Please note I did also this step:
11. Copy those sdlxliff files back to the original project’s target folder.
As I was replacing existing sdlxliff files, I got a dialog for every file I was copying. All of them had identical Modification dates as ... See more Hi Paul,
For a second I thought you thought I was going to try and sell you something.
Haha!
Please note I did also this step:
11. Copy those sdlxliff files back to the original project’s target folder.
As I was replacing existing sdlxliff files, I got a dialog for every file I was copying. All of them had identical Modification dates as the files I used to create my review project in the first place.
I also double-checked my main project after copying the sdlxliffs back to main project's target folder: My review changes were not implemented into the sdlxliffs (I could see the changes in TM though).
I would love to go back to my review project and try this again, but there's another annoying bug/feature: After finalizing the merged.sdlxliff my Files list now shows me the separate sdlxliffs, which I cannot revert back to merged.sdlxliff anymore. If I now re-Finalize, I end up with target files without my review changes.
In your successful test, did you do any changes to your translations? Did those changes end up to your separate sdlxliffs? I will try this out again with another project.
About SDLXLIFF Converter: I have to try downloading the tool again. It seems to have been updated on 24/02/2011, but its version number is the same (1.0) as my current installation? ▲ Collapse
| | |
|
|
|
| This is the basic test I did | Mar 2, 2011 |
Hi Atso,
I was going to go through in detail what I did here step by step so we could compare what we were doing, but as I was preparing the screenshots and the project I think I found the problem. This time around I was able to replicate your problem in that none of the individual sdlxliff files were updated.
So after Finalize I ran a pretranslate batch task on the Project and they were all updated because the TM did actually contain the changes.
I'm look... See more Hi Atso,
I was going to go through in detail what I did here step by step so we could compare what we were doing, but as I was preparing the screenshots and the project I think I found the problem. This time around I was able to replicate your problem in that none of the individual sdlxliff files were updated.
So after Finalize I ran a pretranslate batch task on the Project and they were all updated because the TM did actually contain the changes.
I'm looking at this with the Product Manager to determine whether there is something I've missed, or if we need to address something, so I will get back to you again on this. So the workaround would be to add a pretranlsate on the end. If you have the ability to create custom tasks you could add to your finalize task for these sorts of projects and then it wouldn't matter, but I will come back to you on this in due course.
The same thing goes with revert to sdlxliff. I think the problem is that they are already sdlxliff, and this command is intended to restore the files to their bilingual state after they were made safe. You can also get around this because the merged sdlxliff should still be in the target folder so you can use that in a new Project if you wanted to and still be able to get the target files out (source not sdlxliff).
Finally, on the SDLXLIFF Converter. It looks as though you are correct for your use case. If the source files are merged then there is no problem, but it indeed does not like merged sdlxliff files. I have also reported this to the developer.
I'm still unsure of why you need to work this way because all of these problems could be avoided if you did this:
1. Create a Project for Translation (don't merge if you don't want to although this would cut out a few steps)
2. Create a review project using the source files (so not the sdlxliffs) and merge these, pretranslating against the Project TM for the translate Project
3. Use the SDLXLIFF Converter (or whatever review process you want) to get your merged review document
4. Import this back in again and Finalize
That's it, target translations are out and your TM is updated. If you still want the seperate sdlxliff files to be update too, then pretranslate the translation project against the updated TM from the review.
I think that would work. But I will come back to you once I have more to report on this.
Regards
Paul
[Edited at 2011-03-02 11:48 GMT] ▲ Collapse
| | | | Atso Puronen
Local time: 19:27
inglês para finlandês
CRIADOR(A) DO TÓPICO | I would lose information... | Mar 2, 2011 |
Hi Paul,
I cannot use your suggested workflow because [I want to/I'm only paid to] review new/changed translations. Pretranslating source files again through TM would mark them all ContextMatches hence making it impossible to distinguish old and new segments.
| | | | | Same issue in Studio 2011 | Sep 8, 2011 |
Hi all,
Apologies from bringing this topic back from the dead, but I just experienced the very same issue that Atso describes (running Studio 2011 Beta, but the situation is otherwise identical - I tried doing the same in 2009 and got the same results). I just wanted to chime in to say that this is indeed a problem - and definitely doesn't seem like logical behaviour on the part of Studio.
In my particular case, I had received a number of small files for translation -al... See more Hi all,
Apologies from bringing this topic back from the dead, but I just experienced the very same issue that Atso describes (running Studio 2011 Beta, but the situation is otherwise identical - I tried doing the same in 2009 and got the same results). I just wanted to chime in to say that this is indeed a problem - and definitely doesn't seem like logical behaviour on the part of Studio.
In my particular case, I had received a number of small files for translation -already in SDL XLIFF format- from my client. Rather than deal with such a large number of files, I decided to create a new project and merge them, expecting to get fully translated individual SDL XLIFF files after finalising the project, which I could then deliver to the client (who, ideally, should not even be able to tell the files had been merged at some point).
However, this is what happens when I try to generate the target files:
- If I select the merged file and click "Export files", no files are generated, even though the task doesn't return any errors. The individual SDL XLIFF file remain unchanged.
- If I click "Finalize" (or "Generate Target Translations"), the individual SDL XLIFF files in my language folder (es-ES in my case) remain unchanged. Moreover, the merged file disappears from the "Files" pane and I'm left with the individual SDL XLIFF files (which Studio claims are 100% translated but, when clicked, are revealed to be empty).
Could someone try to reproduce this behaviour on their machine (specifically Paul, if he's reading this)? If Studio is proving unable to export files from merged SDL XLIFF files, this is actually a bigger deal than the usual Studio idiosyncrasies - it means that the Export function is broken, plain and simple, at least when it comes to merged SDL XLIFF files..
As Paul mentioned earlier, this does not have to be a complete disaster if you can simply open the individual untranslated files and re-apply the TM using Pretranslate, but this is far from an ideal solution. For one, as Atso said, segment status is lost in the process, which complicates the task of the reviewer. Besides, there really is no excuse for the "Export files" / "Generate Target Translations" not working in this scenario.
Cheers,
Fran ▲ Collapse
| | | | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » Issue using 'Merge Files' feature for reviewing files | Wordfast Pro | Translation Memory Software for Any Platform
Exclusive discount for ProZ.com users!
Save over 13% when purchasing Wordfast Pro through ProZ.com. Wordfast is the world's #1 provider of platform-independent Translation Memory software. Consistently ranked the most user-friendly and highest value
Buy now! » |
| | CafeTran Espresso | You've never met a CAT tool this clever!
Translate faster & easier, using a sophisticated CAT tool built by a translator / developer.
Accept jobs from clients who use Trados, MemoQ, Wordfast & major CAT tools.
Download and start using CafeTran Espresso -- for free
Buy now! » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
Translation news related to SDL Trados
