nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Recognise updated files and update TS with those files

Nissan

Hi,

We are trying to use Idiom WorldServer for our Translations.

The method that the Idiom people are proposing is:

1. Deploy files (DCR's or output files) to a file system which could be IW Teamsite itself or outside TS and initiate their application.
2. then they would pick it up from there and do the translations and drop it back into respective folders in the file system and send us an email that the translation is complete.
3. What they want to know is would IW TS be able to recognise that the files have been translated and are back in the file system to go pick it up from there and update IW with those translated files.

I had told them that we could deploy files on to a file system but i was not sure if IW could recognise that files have been translated and are ready for IW to pick it up from the fle system and update IW TS folders.

Please let me know.

TS version: 6.5 SP3
OS : Solaris

Best Regards!

Find more posts tagged with

Comments

nipper

I have done a couple of integrations with translations (neither were Idiom).

It tends to be a more complex beast than it appears (not product related but more infrastructure).

1st, keep the data in TeamSite. That will make your life easier. Point Idiom to the /iwmnt to pick up the data.

You can use a workflow (would need to be custom) to kickoff the translation. Need some smarts there. If you are really good the WF can pause waiting for the translated data and then Idiom could kick off a script to restart the WF. Not rocket science, but not out of the box.

Idiom should have a GUI, either integrated in TS or outsite. Youcan point the GUI to the en-US folder, select the files for translation and langauge (es-MX) and when Idiom is done, it moves the files into es-MX, view source and submit.

There are 20 other little things you will learn about this. So I hope you are not afraid of getting your hands dirty, ie you may have a link to /en-US/index.html but that should get remapped to /es-MX/index.html.

Good luck

Andy

Nissan

Andy,

That was a great response!

Could you explain the below mentioned part in detail?

"the WF can pause waiting for the translated data and then Idiom could kick off a script to restart the WF"

Thanks in advance!

markers.rptdesign

nipper

Hard to explain. If you have written custom workflows you can do it.

There are a few ways to do this.

You could have an external task that executes the push to Idiom. Then it ends without running the CallBack (these are WFT terms, insert WFM verbiage where appropriate). Idiom, after it pushes the data back, can restart the WF external task that would continue the workflow. There is a lot to do with this solution, the DCRs would need to be run through iwpt_compile (if necessary) spread out to review tasks, submit, deploy.

THat is assuming that the es-MX content was on the same branch as the en-US, if they use different branches, then you have added complexities.

The 1st thing you really need to do is define the exact use case of this. Doing it all in workflow sounds good, but there things to consider when doing this.

Nissan

yeah that is true! I do understand your point...

How would Idiom restart the WF is my question?

Appreciate your response!

nipper

There are several tricks to doing this. They can always start a new workflow from a script.

But you can also execute an external task that does not do a callback. It is hung. Then Idiom executes it & this time it knows to do the callback, after it attaches the new files to the workflow. Then procede to the generate HTML step, approve, submit deploy etc.

Nissan

hmmm....Sounds Interesting!!!

Thanks a lot for your valuable inputs!!!

ISCBorisB

hmmm....Sounds Interesting!!!

Thanks a lot for your valuable inputs!!!

Please note that hung Workflow is a serious drag on System Resources. Multiple hung workflows can become a show stopper real fast.

If I were you, I would've terminated the "Send for Translation" WF then and there - it's done.
Then all you have to come up with it the mechanism to start a new "Translated - Go process it!" Workflow on some events.

To do that you'd have to talk to Idiom folks and identify their Delivery mechanism details. If that is (for example)
OpenDeploy, you can configure a script to initiate a "Translated!" WF and make Idiom to configure DNR "On Target", etc...
Some SFTP products have built-in triggering mechanisms and/or api's to create one.

Worse come to worse, you can schedule "Pull" process to run oh say, every hour, check Target Directories and start
post-translation WFs if there is something there - just do not forget to clean it afterwards.

Nissan

Thats a good thought!!!

Appreciate your input.

So from your statement:

"Worse come to worse, you can schedule "Pull" process to run oh say, every hour, check Target Directories and start
post-translation WFs if there is something there - just do not forget to clean it afterwards."

Could you explain this in detail...are you saying that run a job that would check to see if there are any new files in folders and if IW finds then start a WF and attach those files to the WF and continue...

Please explain if otherwise...

ISCBorisB

Thats a good thought!!!

Appreciate your input.

So from your statement:

"Worse come to worse, you can schedule "Pull" process to run oh say, every hour, check Target Directories and start
post-translation WFs if there is something there - just do not forget to clean it afterwards."

Could you explain this in detail...are you saying that run a job that would check to see if there are any new files in folders and if IW finds then start a WF and attach those files to the WF and continue...

Please explain if otherwise...

In a nutshell yes, that's what I had in mind. Devil is in details though - and you'll have to work out plenty of those.
Personally I would've tried to set triggering mechanism before resorting to the scheduler.

- To minimize dependency and maintain inventory you may want to consider 3 directories: something like "Filed", "InProgress",
and "Processed". Triggered or scheduled, your process will move Files from "Filed" to "InProgress" immediately upon detecting,
thus priming "Filed" for the next cycle regardless of the Flow participants procrastination.

- Note that CMS Store may or may not be exposed to "Idiom" to drop Files to. My current Project for example has strictly
internal CMS Access policy. If that's the case you may not be able to attach Files to WF directly and would create/pass
Job File Manifest (in the spirit of OD Manifest - List of this particular Job Files) for external/CGI/URL Tasks to process, etc...

new_report_2.rptdesign

source.txt

nipper

Please note that hung Workflow is a serious drag on System Resources. Multiple hung workflows can become a show stopper real fast.

True, but you could do this with a 2 week timeout You might have 50 or 100 workflows waiting for translation. Performances issues start in the several thousand hung workflows.

Adam Stoller

True, but you could do this with a 2 week timeout You might have 50 or 100 workflows waiting for translation. Performances issues start in the several thousand hung workflows.

Although I haven't had to deal with this much [yet], I kind of like the idea of a continuing end-to-end single workflow process rather than a disjointed two-step dual-workflow process. But as with many such things - it's the specifics of the environment / requirements of the customer - that [help to] determine the proper strategy to take.

ISCBorisB

True, but you could do this with a 2 week timeout You might have 50 or 100 workflows waiting for translation. Performances issues start in the several thousand hung workflows.

Ah, good! Got it. With something like "dummy task with the timeout" transition we may loop back on certain Flow Phase.
That will make it wait and keep WF active, not hung.