When one has used a number of e-mail addresses in the past, it is often difficult to "retrain" clients to use special e-mail addresses to integrate with the workflows of an online translation process management system like OTM from lsp.net. A simple way to redirect request messages which arrive on the "wrong" e-mail account so that they can be used most easily as the basis for setting up a project in OTM is to use the "resend" feature of Microsoft Outlook.
When an inquiry is directed to the "wrong" e-mail account
Open the mail message and select the command "Resend This Message..." from the Actions menu of the mail message window.
A confirmation dialog appears
Click "Yes" to re-send the message. The message will arrive at the new recipient's inbox with the original sender indicated as the sender of the rerouted message.
Erase the original e-mail recipient's address and enter the new e-mail to which the message is to be re-routed
In this case the message will be re-sent to a project manager's address in OTM.
I'm curious how long did that take you in screen steps Kevin? Looks like a very interesting program to save all the faffing about. Was that HTML or blog output? (A bit off topic I know - sorry) :)ReplyDelete
It took just a few minutes, Alex. It took me longer to figure out how to export a package for a colleague to translate it. (The two export options via the button and the file menu command are not the same for some odd reason.) The output option I used to post here was the one Karin H. suggested - "styled blog" as a draft. To be honest I couldn't see any real difference compared top the "neutral" blog option. I still didn't like the looks of the subheaders and changed them manually. I'm sure I can save myself effort by tweaking preferences somewhere.ReplyDelete
I've also tested various HTML outputs, the MS Word output and PDF output - all quite good (looks better than the default blog output).
Screen Steps has a pretty fast learning curve - even faster if one actually follows the RTFM principle. I can literally whip together a set of instructions in about the time I would usually take to explain it to someone in person or on the phone, and I have the content in a single-source authoring environment for re-use. I've been reading up on the "manual" feature too... this sounds very useful for a few documentation projects I've been putting off because of the technical hassles involved.
I posted a tutorial on our site that will show you how to customize your step titles so that they look like they do in this post:
Let us know if you need any help.
Thank you, Greg! Your explanation is quite easy to follow and very useful :-)ReplyDelete
@Greg: What's the underlying format for the data in packages? I'm thinking of compatibility with common translation tools here. It would be great if the XML filters or other tools in standard environments like OmegaT, Déja Vu, memoQ or even SDL Trados could interpret your content for translation purposes.ReplyDelete
@Greg: Just followed your suggestions for creating and adapting a customized blog output template. Very simple. I uploaded a new short tutorial on quotation that used a different maximum graphic width and a different style for subtitles. Not optimal yet, but it's definitely an improvement.ReplyDelete
@Kevin: The package format is essentially a zip file that contains the images and the encoded lesson/manual data. This wouldn't be an appropriate format to share with others.ReplyDelete
If you just want to get content out of ScreenSteps and into another system you could customize an HTML template to output XML. We have a tutorial on this.
A common XML format for getting content into and out of ScreenSteps is something we plan on adding in the future.
@Trevor: Figures it's a ZIP file. Everyone seems to make & rename those for the packages. What's the encoding scheme for the data file? Perhaps I can build a filter for that.ReplyDelete
The objective here isn't to migrate to another system (though I suppose your tutorial will come in handy if I want to port content to a CMS). It is to keep the content in ScreenSteps but translate it (so that SS can be used as a single source output tool for the German version of a tutorial, for example). Overwriting in the ScreenSteps environment is not a desirable option, as it would deny the translator the use of the support media (translation memories, digital terminologies, etc.) that the majority use today.
What's your timeline for I/O via XML?
@Kevin: If you email support at bluemangolearning I can fill you in on the package format details and we can discuss XML I/O. We are planning on including XML I/O in 3.0. I would be interested in knowing what needs you may have when integrating with some others systems.ReplyDelete
Cool, Trevor, I'll do that. You have a great tool here - it saves me a LOT of time creating instructions, especially if I plan to re-use the content in various ways. However, my circles are multi-lingual, and it is very, very important to offer optimized processes for translating useful content into X languages. Fully generic XLIFF is perhaps worth considering for this, as most respectable translation tools can deal with it now, and it looks like this format has some future. In any case, I'll be pleased to test whatever you come up with and suggest a few brighter folk worth talking to about the technical aspects.ReplyDelete
searching for translation workflows / multilingual support in ScreenSteps, I found this pretty old article and the comments between you and the Trevor. Did anything happen since then? They completely migrated to cloud services, which is fine by me, but the only possiblitly to translate your content seems to be a HUGE step back. Just look at the recommendation here: http://help.screensteps.com/m/9096/l/121190-does-screensteps-support-multiple-languages
"1) Create the article in English
2) Duplicate the English article and update the text and screenshots to be in Spanish"
Very disappointing in 2016.
Do you still use SS? If so, how do you handle translations there?
I haven't used ScreenSteps in some time. It was helpful in assembling the draft of my first memoQ help guide in 2012, but afterward when revising the text and format for publication, I had too many hassles with the style template. This was probably as much an issue with my workflow as anything else, but my feeling is that more complex documentation tasks will have difficulties with the tool. And localization is probably best done with converted formats.Delete