CDR Tickets

We seem to be revisiting the requirements evolution that we went through for OCECDR-4193 (even though that issue said we would use the same approach for workflow management of the media and glossary documents). Here's a summary of the highlights of the discussion of the requirements from OCECDR-4193:

Users: Please provide support for workflow management of the translation of summary documents by storing translation processing state information in the CDR documents.
Developers: Doing it that way won't support all of the requirements you have identified. We need to track the progress of summary translation jobs in separate database tables, not in the CDR summary documents themselves.
Users: We understand and agree. Here is a replacement statement of the requirements.
Developers: The new requirements document still describes the process in terms of storing the progress of summary translation jobs in the CDR summary documents, not in dedicated translation queue database tables. Please present our proposed approach to Linda and ask her if this approach is acceptable.
Users: Linda Looooooves this :-). Please do it this way.

I'm hoping we can agree up front that we will use the same approach for tracking translation jobs for media and glossary documents as we used for translation of summary documents.

Yes, we can agree on that. Please ignore references to storing of translation jobs in the CDR. We do understand that it would work the same way as the translation workflow for summary documents.

Do you really want the mixed capitalization styles for the processing status value given in the requirements document (some have each word capitalized, some have some of the words capitalized, some have only the first word capitalized)?

"Rather, if possible, we want to be able to determine when to send the email notification after manually assigning multiple jobs."

I'm having a hard time picturing what this would mean. Are you picturing an interface in which you would be presented with all of the assigned jobs, from which you would say "send email notification for this job and that job but not for these other jobs"? What would be the added value from such an interface if we're sending daily email messages to all translators listing their assignments?

Daily emails with all jobs assigned should be fine. We are trying to avoid the situation where a user receives one email for each job assigned.

Please see the revised values. There are still some mixed capitalization styles but that is okay.

Ready For Translation
Translation Pending
Spanish Labels Sent to Artist
Spanish Illustration Approved
Spanish Caption and Content Description Revised
Translation Reviewed
Translation Complete

"We would want the ability to assign multiple jobs to translators on the same page at the same time."

Could you describe in detail exactly what this would look like? Or better, draw me a crude mockup of the form you're imagining, and attach it to this ticket, please.

Since we expect users to be assigned many jobs at a time, we want to be able to do that while on a page where a user can be assigned multiple jobs. So, the simplest way I can think about this is a page that lists the jobs with a USERS column so that for each job, there would be a list of users to select from. Essentially, in addition to being able to assign individual jobs, we wanted the option to assign multiple jobs to one user or the other while on a single page.
Hope this helps.

So, you're talking about re-assigning existing jobs to different users, not creating new translation jobs?

That is right. This would primarily be used by Linda when a job has been created already.

So we need two different forms, one for creating a single new translation job, and another for modifying all of the existing translation jobs?

Yes.

Translation Workflow Management Media Docs_Updated.docx

I am attaching a mockup of the interface and also an updated requirements documents.

I discussed these with Linda and she is fine with updating the Comment field only in the individual jobs page.

The second form will be used for re-assigning multiple jobs.

On the second form, when a job with "Ready For Translation" is re-assigned, would you be able to programmatically change the status to "Translation Pending"?

Yes, the software can change the status in that scenario.

Just for future reference I want to clarify that although a revised requirements document has been posted to the ticket, we are not going to be using status elements in the document to drive the workflow management process (even though that's what the revised requirements documents still specifies), but are instead planning to use separate database tables for this purpose.

Thanks! I have tried to remove all references to the status values in the document with the exception of (ii) which I am not sure if that is needed. If that is not needed, please let me know and I will remove it as well. Translation Workflow Management Media Docs_6-20-2018.docx

You can replace (ii) with the following:

Information (including status) for media translation jobs will be stored in a separate database table. The queue management software will ignore any processing status values found in the CDR documents.

Macro button, queue page, and editing form have been installed on DEV.

Is there a way to get to the queue page directly from the menu? Also, when adding a new job from XMetal, the Spanish ID field is blank. Is the user expected to enter the CDR ID of the Spanish ID?

Translation Workflow Management Media Docs_6-25-2018.docx

Attaching updated requirements document.

Is there a way to get to the queue page directly from the menu?

I've added it to the CIAT menu.

Also, when adding a new job from XMetal, the Spanish ID field is blank. Is the user expected to enter the CDR ID of the Spanish ID?

Yes, we discussed this in the CDR status meeting.

I remember the discussion as it was related to the comments but not the ID. Can you remind me why the software will not be able to populate a matching Spanish ID to the English for existing media docs?

There's no element in the Spanish Media document identifying the English document of which it's a translation, unlike the Summaries. That's why I asked if you understood that the user will need to supply both IDs.

In the Spanish document, the MediaSource wrapper element contains a MediaID element that points to the English doc.

OK. I would never have guessed that MediaSource meant "English counterpart for Spanish image"! :-)

So does this only work if the FromMethod/@method is "translate-text"?

I'll be starting over, wiping out and re-creating the tables, which need to be re-defined to omit the Spanish document ID, so the queue (and history) are empty. The scripts are being re-written to match the new approach (until that's done they won't work, so I would hold off on testing this ticket, and the corresponding ticket for the report for now). I'll need your answer to my last question to proceed.

Just wanted to make sure my last question didn't get missed. Do we assume the document linked in the FromObject block is the English original from which the Spanish document is derived even if the derivation method is (for example) "crop" or "thumbnail"?

I believe the answer to your question is yes. Do you know of a document that has either a "crop" or "thumbnail" set for the derivation method?

I just wrote some software to analyze the Media documents, and it doesn't appear that the derivation method is being specified for any of them. So we can't tell which ones are Spanish translations, and which are the result of other types of derivation.

I have re-created the tables and re-written the software, based on the assumption that all of the Media documents derived from other CDR Media documents are Spanish translations of English documents. I strongly recommend that you consider modifying the schema structure (along with the corresponding global change) to make this assumption explicit, as the current structure is misleading.

We decided in today's weekly status meeting that we will fix the schema and perform the accompanying global change (as part of Ising) to use a dedicated SpanishTranslationOf element (as we do with Summary documents). ~oseipokuw will add the new tickets for this work and move them into the Ising sprint.

Margaret indicated that CIAT should be using the existing elements/attributes to identify Media documents which are derived in other ways from other source CDR Media documents.

~oseipokuw: I have added the MANAGE TRANSLATION QUEUE permission to the Developers group (of which you're a member), so you should be able to test the queue management software now on DEV. Note that I have a question for you in OCECDR-4495.

That is right. This would primarily be used by Linda when a job has been created already.

Just want to be 100% clear: the ability to reassign jobs in bulk will be available exclusively (not just "primarily") for jobs which have already been created. Agreed?

Yes, agreed. What I meant was that this was a tool for Linda to re-assign jobs. The only time another translator would use it when Linda is on vacation. So, "primarily" was in reference to Linda and not the tool/feature. Sorry for not be clearer.

I have implemented the scheduled nightly jobs for sending each translator with active jobs the report for her queue. Test messages have gone to William, Linda, and myself. Will do the weekly report for Linda next.

Weekly report job implemented, test message sent from DEV.

This works for me. However, there are other non-translators who need access. Adding them to the list of translators works but that adds them to the list of translators (who need to be assigned jobs). Could you modify it so that non-translators can have access but not added to the list of translators displayed on the re-assignment page?

Sure. Just put them in a group which has the MANAGE TRANSLATION QUEUE permission. You can create a new group if there aren't any existing groups to which adding that permission would be inappropriate (because all of the existing groups include users who should not have that permission).

Okay. Thanks!

I'm going to install the changes to use the new TranslationOf element instead of the DerivedFrom block. When I do that, the Spanish IDs will not be displayed on the queue or in the reports until the global change (for which I waiting for user review of the the test mode output) has been run in live mode.

Sure. Thanks for the heads up.

1. Please change the icon for this queue in XMetal so that it is different from the the summary queue.
2. Also, please add a new icon in XMetal for the re-assignment page.

New macro and toolbar button added. Don't forget to change the ticket status back from Completed (Resolved) when new requirements are added.

Please add the following new statuses:
1. Translation Made Publishable
2. Translation Peer-Review Pending

Please revise the following status:
1. From "Translation reviewed" to "Translation Peer-Review completed"
2. Also, please use "Translation Made Publishable" to determine what should be purged off the list.

When you delete a Media job from the Edit Translation Job page, the resulting page goes to the Summary queue instead of the Media queue.

Please add the following new statuses:
1. Translation Made Publishable
2. Translation Peer-Review Pending

Please revise the following status:
1. From "Translation reviewed" to "Translation Peer-Review completed"
2. Also, please use "Translation Made Publishable" to determine what should be purged off the list.

Please don't make these changes yet. I will provide a new list of values shortly. Sorry about this.

Please use the following status values:

Ready For Translation
Translation of Labels Pending
Translation Peer-Review Pending (only labels)
Translation Peer-Review Complete (only labels)
Spanish Labels Sent to Artist
Spanish Illustration Approved
Translation of Caption and Cont. Desc. Pending
Translation Peer-Review Pending (Caption and Cont. Desc.)
Translation Peer-Review Complete (Caption and Cont. Desc.)
Translation Made Publishable

Also, please use "Translation Made Publishable" to determine what should be purged off the list.

Would it be possible to have a Status Date field in the Edit Translation Job page?

I found that with the summary translation jobs, where the user was expected to set that value, it was often ignored, leaving it at the value for the previous state. This resulted in meaningless values, and made it impossible to sort the history reports chronologically. Therefore, for media and glossary translation queues, the software sets the status date automatically when a change is made to the job.

Sure. Thanks for the explanation.

OK, I think I've caught up with all the new requirements for this ticket. The queue and history tables were dropped and recreated, so they're empty. This was necessary in order to recreate the state values table with the the new states.

The Purge function does not appear to work as it does not delete the one(s) marked "Translation Made Publishable".

Also, when you delete an individual job using the delete button, the resulting page is to the summary queue instead of the media queue.

I believe both problems have been fixed. Don't forget to reopen tickets when there is more work to be done.

I couldn't confirm these two changes on DEV. Should I wait until you run the script to verify?

Perhaps, though I think it should work now.

No emails are sent out nightly or weekly . I Assume that we have to run a publishing job for the emails to go out.

The jobs have been installed on QA. Do you want them running on all the lower tiers?

Verified on QA. Thanks!

Verified on PROD. Thanks!