Best practices for changed source documents

i'm following this one

Cricket so far.

@XTRF: This would be a great topic for a KB article. Could you please write something up on this topic? It is a frequent occurrence in today's LSP word.

yup, tumbleweed... 

Anxious to see if anyone has a good workaround or decent solution, as this is common practice in our daily business as well. 

I agree a KB article is needed and it is planned, indeed.

However, it would still be great to hear how others manage these scenarios without having explicit features in an integrated TMS-CAT environment.

Let me get the ball rolling by sharing our current approach. Not the most elegant and efficient, but that's all we have come up with given the current design of Smart Projects. Hope it helps some of the fellow users to deal with these situations. I think it clearly highlights the need for a systematic solution because updated customer documents are unfortunately a common occurrence at LSPs.

Scenarios:

(1) Integrated memoQ project with bilingual source documents already created, but translator hasn't started.

(a) One language pair

In this case, it is easiest to cancel/delete the current project and set up a new one. By the time you have unshared/deleted bilingual documents, source documents, CAT analysis and then cleaned up the receivables and payables, it is faster to start from scratch, with the caveat that you have to communicate a new job number to the vendors and customer.

(b) Several language pairs

Here it depends on the number of language pairs. If you have e.g. 10 language pairs and all vendors selected, it is easier to unshare/delete the bilingual documents, source documents, memoQ analysis and upload the new source documents to the project. However, the update of the receivables and payables will drive you nuts as the Finance module is the slowest and least efficient of all Smart Project cards (@XTRF: I remember seeing some mockups on an overhaul of this card; any news on rollout plans?) ... XTRF keeps popping up the in process message, no support of multiple actions for receivables and payables (thus 10x the same action instead of just 1x multiple action), scrolling up and down because right-hand finance details are always at the top right while you have to scroll down on the left-hand side to see all the language pairs. I better stop right here ... whenever a customer sends an updated source for a multilingual projects, a project manager runs down the hallways screaming ;o)

(2) Integrated memoQ project with bilingual source documents already created and translator has started, but not delivered.

Starting a new project (as described in 1) has not proved to be a good option in this scenario. Here we forego the XTRF-memoQ integration and work directly in the memoQ project by asking all the vendors to stop their work until further notice, reimporting the source documents directly in memoQ, X-translating in memoQ, creating new memoQ analysis, updating receivables and payables. At this point, we contact the vendors again so they can resume their work. Caveats: From this point onward, XTRF will display integration errors because the document ID in memoQ has changed and this breaks the integration reference. Furthermore, you have to remember to unshare the original bilingual document, otherwise the vendors will see two bilingual document versions for the same source document.

Without getting into details (I am already having a panic attack as I am writing this), it is an ever greater adventure if the vendors do not work in memoQ. Now you have to manually recreate new TM/TB subsets, import them in XTRF, categorize and share them ...

(3) Integrated memoQ project with bilingual source documents already created and translator has started and delivered. Bilingual document is now with proofreader.

In most cases, we will contact the proofreaders to stop their work. Then we start a new XTRF project, import the new source document, ensure the right Working TM is assigned in the memoQ project, and send the updated project to the translator, essentially restarting the whole process. The updating of the finances has to be closely coordinated, using Master ID to combine both projects in the customer invoice, making sure the proofreader only gets one payable for the project and the overall word count/fee for the translator makes sense.

Hi Lukasz. Any update on the KB article that outlines best practices according to XTRF's current system design? Thanks.

Anyone? Would be glad to hear about more efficient ways of dealing with such scenarios.

Hi Sancho,

We use XTM connector, and to be honest the connector is quite limited. We are not very happy with how it works. In all scenarios that you mention, we are forced to add a new task with updated files, since replacing the files if the project started, is not an option. It simply does not work. See below our scenarios and actions taken:

1. If the project has been created by the connector, but not started - it's great in terms of not paying to the linguists - we just add a new task to our project, upload new files, and create new project in XTM.

And the same would be much faster for us even for multilingual projects, you can always upload new files to 1 task (1 language pair) and than copy that new workflow to other languages.

2. If the translation has been started but not delivered - we would upload the new document directly to XTM, check the analysis against the already translated file and ask the linguist to only translate the differences/modified segments - and update the PO accordingly. The integration would be "broken" because the PM needs to manually download the translated files from XTM (the connector will not recognize there were new files uploaded) and upload them to XTRF.

3. If translator delivered, but the next step did not start or just started, then we would do exactly the same as for point 2. and let the editor know that he should work only on the new file (specify everything in the instructions).

I hope that is helpful for you :)

Best,

Monika

Thanks for your input, Monika. Sounds like the choice of CAT tool does not make much of a difference in the manual workarounds that are currently needed. Let's see whether anyone else will chime in to enlighten us.

@XTRF: Would really be interested in what your best practice suggestions are for both the Classic and Smart design.

Hi Sancho,

Our way of handling this is very similar to yours. Interested to see if there's room for improvement :)

Thanks for your input so far. 

Sorry for the prolonged silence on our part. We still need some time.

There are 4 CAT tools XTRF is integrated with and at least 3 scenarios possible with each...

@Marek: With Lukasz gone, is this best-practice manual or webinar still on the short-term to-do list? Very common situation in daily LSP work. Would be good to know how XTRF was designed to handle this.

@Marek: Could you please add your thoughts on this? There was talk of a webinar or best-practice documentation for these scenarios. What are the best workaround options and what improved solution is on the horizon?