RE: Frame 10 XML/translation question
Hello Michael, There are several issues you address here. First, if you want to know how easy would it be to pull the translated output (in XML format) back into Frame for publishing as PDFs: it's very easy - supposed your source for translation is XML authored in FrameMaker. But as you mention that your source files are Framemaker 7.2 it's not recommended to go that way. Unless, of course, you have plenty of time to migrate your content to FrameMaker 10 and XML and to learn how to work with XML .. On the other side, it's also very easy to translate FrameMake files from English to Japanese. All you need is a translation provider who accepts Framemaker MIF files for translation. And to be honest, every serious localization provider should be able to cope with MIF, it's natively supported in all translation tools (Trados, DejaVu, MemoQ, XTM, Transibar, Transit, etc etc). All you need after translation is a Windows system that supports Japanese. Contact me off list if you need advise on translation vendors that can handle your files without problems. Kind regards, vriendelijke groet, Wim Hooghwinkel iDTP - Technical Communication Consultant, Adobe Certified Expert (ACE) in FrameMaker http://www.ditatools.com/ NLDITA Winter 2011 - December 2011 in Utrecht - Special about localization and translation of DITA and XML content http://www.ditatools.com/ NLDITA Tools 2012 - April 2012 in Utrecht - Tools and best practices for Authoring, Managing and Publishing http://www.ie12.org/ NLDITA Information Energy 2012 - june 2012 in Utrecht and Ghent - DITA and topic based information development tel. +31652036811 Skype wimhooghwinkel Twitter @idtp @NLDITA mailto:i...@idtp.eu i...@idtp.eu www.idtp.eu www.nldita.nl FrameMaker support: framema...@idtp.eu ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
Re: Frame 10 XML/translation question
Hi Michael Find a translation service (or translation company) which accepts MIF as input. If this is not an option, you could save your FM files as MIF and convert those to XLIFF (XLIFF = XML Localisation Interchange Format). Translation tools like Swordfish and others (some of the ones which Wim Hooghwinkel mentioned) can handle this very well. And you don't really need FrameMaker 10 to get the Japanese translation back into FrameMaker. FrameMaker 7.2 does not support Unicode, but this does not mean that it cannot handle Japanese text. All you need is a custom font, for example MS Mincho. Kind regards www.scripto.nu On Sat, Dec 3, 2011 at 4:47 PM, Michael Norton michael.nor...@oracle.comwrote: Our company will be translating some manuals from English to Japanese. The translation service only accepts HTML and XML input and outputs the result in those same formats. I am currently using Frame 7.2. I understand Frame 10.0 works in XML. ** ** I realize you can’t give me an absolute answer, but how easy would it be to pull the translated output (in XML format) back into Frame for publishing as PDFs? ** ** Are there any major issues with taking this approach? ** ** Thanks. ___ You are currently subscribed to framers as yves.barb...@gmail.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/yves.barbion%40gmail.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info. -- Yves Barbion www.scripto.nu ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
FM 10 books - Thanks all
Thanks everyone for the information about FM 10 books. As always, this list rocks. Corinne Kenney Raytheon Aurora Colorado___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
Horizontal scrolling
I have searched for, but cannot find, any keyboard command that activates horizontal scrolling of a document window. Does anyone know if this is possible? Thank you in anticipation. -- Steve ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
documentation best practices
I could use some insight into a situation I haven't encountered before today: how does one best respond to a request (read: order) to include something in their product's documentation about a functionality that will not be released with the upcoming release (it will still be in development) but is hoped to be ready shortly (whatever that means) after the product is released. I've politely pointed out that industry best practice is to document what IS as opposed to what WILL BE and that certain liabilities might be incurred if promises are made and then something goes wrong. Any thoughts?___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
Re: 2. Frame 10 XML/translation question (Michael Norton)
Hey, it doesn't have to be that bad! Is this a prototype for a major system change, a single document being translated at customer request, or... Anyway, you see my point. The amount of time and software you throw at the solution needs to be based on the solution that you need. FrameMaker10 contains an option on the File menu called Save as XML... The nice thing about XML is that is doesn't require a structure (don't get me wrong, I prefer structured XML, but, if this is a one-off document, it may be overkill). What you need to be sure that you have is a file structure that is set up to clearly identify the XML you are sending to the translation service, and the XML that you are receiving back from the translation service. This is best done in a document management system, but, again, if this is a one-off, you can do without. At one company I worked for, the powers-that-be liked the quality and speed of the translation so much that they agreed to move from the one-off model to a full-scale system. We decided on Author-It, though, because I had in place detailed Word Stylesheets that could be transferred to structured XML with little trouble. Hope this helps. Sue Ahrenhold Roush Technical Systems Allen Park, MI -- Message: 2 Date: Sat, 3 Dec 2011 07:47:26 -0800 (PST) From: Michael Norton michael.nor...@oracle.com To: framers@lists.frameusers.com Subject: Frame 10 XML/translation question Message-ID: 7e188798-76ee-4b57-b29b-618403a19d3c@default Content-Type: text/plain; charset=us-ascii Our company will be translating some manuals from English to Japanese. The translation service only accepts HTML and XML input and outputs the result in those same formats. I am currently using Frame 7.2. I understand Frame 10.0 works in XML. I realize you can't give me an absolute answer, but how easy would it be to pull the translated output (in XML format) back into Frame for publishing as PDFs? Are there any major issues with taking this approach? ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
RE: documentation best practices
As someone who both develops and documents software, I can only answer with a hearty Hear hear!. I think youre exactly right, and I hope you can get them to see the light. Good luck, Lea _ Lea Rush Software and Documentation Specialist Astoria-Pacific International http://www.astoria-pacific.com www.astoria-pacific.com http://www.a ph: 800-536-3111 fax: 503-655-7367 mailto:l...@astoria-pacific.com l...@astoria-pacific.com Please consider the environment before printing this email. `·.¸¸.·´¯`·.¸.·´¯`·...¸ º`·.¸¸.·´¯`·.¸.·´¯`·...¸º NOTICE OF CONFIDENTIALITY This communication is from Astoria-Pacific International and is intended to be confidential and solely for the use of the persons or entities addressed above. If you are not an intended recipient, be aware that the information contained herein may be protected from unauthorized use by privilege or law, and any copying, distribution, disclosure, or other use of this information is prohibited. If you have received this communication in error, please contact the sender by return email or telephone (503) 657-3010 immediately, and delete or destroy all copies. Thank you for your cooperation. From: framers-boun...@lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of hessiansx4 Sent: Monday, December 05, 2011 2:56 AM To: framers@lists.frameusers.com Subject: documentation best practices I could use some insight into a situation I haven't encountered before today: how does one best respond to a request (read: order) to include something in their product's documentation about a functionality that will not be released with the upcoming release (it will still be in development) but is hoped to be ready shortly (whatever that means) after the product is released. I've politely pointed out that industry best practice is to document what IS as opposed to what WILL BE and that certain liabilities might be incurred if promises are made and then something goes wrong. Any thoughts? ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
RE: documentation best practices
If they insist, I would make sure that it is well-marked as a future enhancement, perhaps is a separate section of the documentation. I just had a situation where a major aircraft maker (the one that does not start with a B) gave all sorts of very specific information about a software tool to make suppliers lives easier in a reference guide and on their website. When I went to track down the tool I discovered that it does not actually exist yet. Very frustrating. Clint Clint Owen | Sr. Technical Writer | Crane Aerospace Electronics | +1 425 743 8674 | Fax: +1 425 743 8113 From: framers-boun...@lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of hessiansx4 Sent: Monday, December 05, 2011 2:56 AM To: framers@lists.frameusers.com Subject: documentation best practices I could use some insight into a situation I haven't encountered before today: how does one best respond to a request (read: order) to include something in their product's documentation about a functionality that will not be released with the upcoming release (it will still be in development) but is hoped to be ready shortly (whatever that means) after the product is released. I've politely pointed out that industry best practice is to document what IS as opposed to what WILL BE and that certain liabilities might be incurred if promises are made and then something goes wrong. Any thoughts? Check out the new Crane Aerospace Electronics Newsroom! http://newsroom.craneae.com Like us on Facebook! http://www.facebook.com/home.php?#!/pages/Crane-Aerospace-Electronics/163305413682908 We value your opinion! How may we serve you better? Please click the survey link to tell us how we are doing: http://www.craneae.com/ContactUs/VoiceofCustomer.aspx Your feedback is of the utmost importance to us. Thank you for your time. Crane Aerospace Electronics Confidentiality Statement: The information contained in this email message may be privileged and is confidential information intended only for the use of the recipient, or any employee or agent responsible to deliver it to the intended recipient. Any unauthorized use, distribution or copying of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify the sender immediately and destroy the original message and all attachments from your electronic files. ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
RE: documentation best practices
It's called marketing ;) From: framers-boun...@lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of hessiansx4 Sent: Monday, December 05, 2011 5:56 AM To: framers@lists.frameusers.com Subject: documentation best practices I could use some insight into a situation I haven't encountered before today: how does one best respond to a request (read: order) to include something in their product's documentation about a functionality that will not be released with the upcoming release (it will still be in development) but is hoped to be ready shortly (whatever that means) after the product is released. I've politely pointed out that industry best practice is to document what IS as opposed to what WILL BE and that certain liabilities might be incurred if promises are made and then something goes wrong. Any thoughts? ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
Re: 2. Frame 10 XML/translation question (Michael Norton)
FrameMaker10 contains an option on the File menu called Save as XML... The nice thing about XML is that is doesn't require a structure (don't get me wrong, I prefer structured XML, but, if this is a one-off document, it may be overkill). Sue, wouldn't Michael lose any formatting that he requires for his PDF output using that method? Or are you suggesting he use a tool like Author-It to ingest his new XML files and output PDF? Nadine ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
Re: documentation best practices
That's what I was thinking. It sounds more like marketing copy than user guide content. Nadine From: Jeff Coatsworth jeff.coatswo...@jonassoftware.com To: framers@lists.frameusers.com framers@lists.frameusers.com Sent: Monday, December 5, 2011 5:21:46 PM Subject: RE: documentation best practices It's called marketing ;) From: framers-boun...@lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of hessiansx4 Sent: Monday, December 05, 2011 5:56 AM To: framers@lists.frameusers.com Subject: documentation best practices I could use some insight into a situation I haven't encountered before today: how does one best respond to a request (read: order) to include something in their product's documentation about a functionality that will not be released with the upcoming release (it will still be in development) but is hoped to be ready shortly (whatever that means) after the product is released. I've politely pointed out that industry best practice is to document what IS as opposed to what WILL BE and that certain liabilities might be incurred if promises are made and then something goes wrong. Any thoughts? ___ You are currently subscribed to framers as generic...@yahoo.ca. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/generic668%40yahoo.ca Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info. ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
Frame 10 XML/translation question
Hello Michael, There are several issues you address here. First, if you want to know how easy would it be to pull the translated output (in XML format) back into Frame for publishing as PDFs: it's very easy - supposed your source for translation is XML authored in FrameMaker. But as you mention that your source files are Framemaker 7.2 it's not recommended to go that way. Unless, of course, you have plenty of time to migrate your content to FrameMaker 10 and XML and to learn how to work with XML .. On the other side, it's also very easy to translate FrameMake files from English to Japanese. All you need is a translation provider who accepts Framemaker MIF files for translation. And to be honest, every serious localization provider should be able to cope with MIF, it's natively supported in all translation tools (Trados, DejaVu, MemoQ, XTM, Transibar, Transit, etc etc). All you need after translation is a Windows system that supports Japanese. Contact me off list if you need advise on translation vendors that can handle your files without problems. Kind regards, vriendelijke groet, Wim Hooghwinkel iDTP - Technical Communication Consultant, Adobe Certified Expert (ACE) in FrameMaker <http://www.ditatools.com/> NLDITA Winter 2011 - December 2011 in Utrecht - Special about localization and translation of DITA and XML content <http://www.ditatools.com/> NLDITA Tools 2012 - April 2012 in Utrecht - Tools and best practices for Authoring, Managing and Publishing <http://www.ie12.org/> NLDITA Information Energy 2012 - june 2012 in Utrecht and Ghent - DITA and topic based information development tel. +31652036811 Skype wimhooghwinkel Twitter @idtp @NLDITA <mailto:info at idtp.eu> info at idtp.eu www.idtp.eu www.nldita.nl FrameMaker support: framemaker at idtp.eu -- next part -- An HTML attachment was scrubbed... URL: <http://lists.frameusers.com/pipermail/framers/attachments/20111205/aaed83f6/attachment.html>
Frame 10 XML/translation question
Hi Michael Find a "translation service" (or translation company) which accepts MIF as input. If this is not an option, you could save your FM files as MIF and convert those to XLIFF (XLIFF = XML Localisation Interchange Format). Translation tools like Swordfish and others (some of the ones which Wim Hooghwinkel mentioned) can handle this very well. And you don't really need FrameMaker 10 to get the Japanese translation back into FrameMaker. FrameMaker 7.2 does not support Unicode, but this does not mean that it cannot handle Japanese text. All you need is a custom font, for example MS Mincho. Kind regards www.scripto.nu On Sat, Dec 3, 2011 at 4:47 PM, Michael Norton wrote: > Our company will be translating some manuals from English to Japanese. The > translation service only accepts HTML and XML input and outputs the result > in those same formats. I am currently using Frame 7.2. I understand Frame > 10.0 works in XML. > > ** ** > > I realize you can?t give me an absolute answer, but how easy would it be > to pull the translated output (in XML format) back into Frame for > publishing as PDFs? > > ** ** > > Are there any major issues with taking this approach? > > ** ** > > Thanks. > > ___ > > > You are currently subscribed to framers as yves.barbion at gmail.com. > > Send list messages to framers at lists.frameusers.com. > > To unsubscribe send a blank email to > framers-unsubscribe at lists.frameusers.com > or visit > http://lists.frameusers.com/mailman/options/framers/yves.barbion%40gmail.com > > Send administrative questions to listadmin at frameusers.com. Visit > http://www.frameusers.com/ for more resources and info. > > -- Yves Barbion www.scripto.nu -- next part -- An HTML attachment was scrubbed... URL: <http://lists.frameusers.com/pipermail/framers/attachments/20111205/2d249588/attachment.html>
FM 10 books - Thanks all
Thanks everyone for the information about FM 10 books. As always, this list rocks. ? Corinne Kenney Raytheon Aurora Colorado -- next part -- An HTML attachment was scrubbed... URL: <http://lists.frameusers.com/pipermail/framers/attachments/20111205/6b028973/attachment.html>
Horizontal scrolling
I have searched for, but cannot find, any keyboard command that activates horizontal scrolling of a document window. Does anyone know if this is possible? Thank you in anticipation. -- Steve
documentation best practices
I could use some insight into a situation I haven't encountered before today: how does one best respond to a request (read: order) to include something in their product's documentation about a functionality that will not be released with the upcoming release?(it will?still be in development)?but is hoped to be ready "shortly" (whatever that means)?after the product is released. ? I've politely pointed out that industry best practice is to document what IS as opposed to what WILL BE and that certain liabilities might be incurred if promises are made and then something goes wrong. ? Any thoughts? -- next part -- An HTML attachment was scrubbed... URL: <http://lists.frameusers.com/pipermail/framers/attachments/20111205/781287f2/attachment.html>
2. Frame 10 XML/translation question (Michael Norton)
Hey, it doesn't have to be that bad! Is this a prototype for a major system change, a single document being translated at customer request, or... Anyway, you see my point. The amount of time and software you throw at the solution needs to be based on the solution that you need. FrameMaker10 contains an option on the File menu called Save as XML... The nice thing about XML is that is doesn't require a structure (don't get me wrong, I prefer structured XML, but, if this is a one-off document, it may be overkill). What you need to be sure that you have is a file structure that is set up to clearly identify the XML you are sending to the translation service, and the XML that you are receiving back from the translation service. This is best done in a document management system, but, again, if this is a one-off, you can do without. At one company I worked for, the powers-that-be liked the quality and speed of the translation so much that they agreed to move from the one-off model to a full-scale system. We decided on Author-It, though, because I had in place detailed Word Stylesheets that could be transferred to structured XML with little trouble. Hope this helps. Sue Ahrenhold Roush Technical Systems Allen Park, MI -- Message: 2 Date: Sat, 3 Dec 2011 07:47:26 -0800 (PST) From: Michael Norton <michael.nor...@oracle.com> To: framers at lists.frameusers.com Subject: Frame 10 XML/translation question Message-ID: <7e188798-76ee-4b57-b29b-618403a19d3c at default> Content-Type: text/plain; charset="us-ascii" Our company will be translating some manuals from English to Japanese. The translation service only accepts HTML and XML input and outputs the result in those same formats. I am currently using Frame 7.2. I understand Frame 10.0 works in XML. I realize you can't give me an absolute answer, but how easy would it be to pull the translated output (in XML format) back into Frame for publishing as PDFs? Are there any major issues with taking this approach? -- next part -- An HTML attachment was scrubbed... URL: <http://lists.frameusers.com/pipermail/framers/attachments/20111205/590cc65d/attachment.html>
documentation best practices
As someone who both develops and documents software, I can only answer with a hearty ?Hear hear!?. I think you?re exactly right, and I hope you can get them to see the light. Good luck, Lea _ Lea Rush Software and Documentation Specialist Astoria-Pacific International <http://www.astoria-pacific.com> www.astoria-pacific.com <http://www.a> ph: 800-536-3111 fax: 503-655-7367 <mailto:lea at astoria-pacific.com> lea at astoria-pacific.com Please consider the environment before printing this email. `?.??.???`?.?.???`?...? ><?>`?.??.???`?.?.???`?...?><?> NOTICE OF CONFIDENTIALITY This communication is from Astoria-Pacific International and is intended to be confidential and solely for the use of the persons or entities addressed above. If you are not an intended recipient, be aware that the information contained herein may be protected from unauthorized use by privilege or law, and any copying, distribution, disclosure, or other use of this information is prohibited. If you have received this communication in error, please contact the sender by return email or telephone (503) 657-3010 immediately, and delete or destroy all copies. Thank you for your cooperation. From: framers-boun...@lists.frameusers.com [mailto:framers-bounces at lists.frameusers.com] On Behalf Of hessiansx4 Sent: Monday, December 05, 2011 2:56 AM To: framers at lists.frameusers.com Subject: documentation best practices I could use some insight into a situation I haven't encountered before today: how does one best respond to a request (read: order) to include something in their product's documentation about a functionality that will not be released with the upcoming release (it will still be in development) but is hoped to be ready "shortly" (whatever that means) after the product is released. I've politely pointed out that industry best practice is to document what IS as opposed to what WILL BE and that certain liabilities might be incurred if promises are made and then something goes wrong. Any thoughts? -- next part -- An HTML attachment was scrubbed... URL: <http://lists.frameusers.com/pipermail/framers/attachments/20111205/43cc6847/attachment.html>
documentation best practices
If they insist, I would make sure that it is well-marked as a future enhancement, perhaps is a separate section of the documentation. I just had a situation where a major aircraft maker (the one that does not start with a "B") gave all sorts of very specific information about a software tool to make suppliers lives easier in a reference guide and on their website. When I went to track down the tool I discovered that it does not actually exist yet. Very frustrating. Clint Clint Owen | Sr. Technical Writer | Crane Aerospace & Electronics | +1 425 743 8674 | Fax: +1 425 743 8113 From: framers-boun...@lists.frameusers.com [mailto:framers-bounces at lists.frameusers.com] On Behalf Of hessiansx4 Sent: Monday, December 05, 2011 2:56 AM To: framers at lists.frameusers.com Subject: documentation best practices I could use some insight into a situation I haven't encountered before today: how does one best respond to a request (read: order) to include something in their product's documentation about a functionality that will not be released with the upcoming release (it will still be in development) but is hoped to be ready "shortly" (whatever that means) after the product is released. I've politely pointed out that industry best practice is to document what IS as opposed to what WILL BE and that certain liabilities might be incurred if promises are made and then something goes wrong. Any thoughts? Check out the new Crane Aerospace & Electronics Newsroom! http://newsroom.craneae.com Like us on Facebook! http://www.facebook.com/home.php?#!/pages/Crane-Aerospace-Electronics/163305413682908 We value your opinion! How may we serve you better? Please click the survey link to tell us how we are doing: http://www.craneae.com/ContactUs/VoiceofCustomer.aspx Your feedback is of the utmost importance to us. Thank you for your time. Crane Aerospace & Electronics Confidentiality Statement: The information contained in this email message may be privileged and is confidential information intended only for the use of the recipient, or any employee or agent responsible to deliver it to the intended recipient. Any unauthorized use, distribution or copying of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify the sender immediately and destroy the original message and all attachments from your electronic files. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.frameusers.com/pipermail/framers/attachments/20111205/045340ef/attachment.html>
documentation best practices
It's called "marketing" ;>) From: framers-bounces at lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of hessiansx4 Sent: Monday, December 05, 2011 5:56 AM To: framers at lists.frameusers.com Subject: documentation best practices I could use some insight into a situation I haven't encountered before today: how does one best respond to a request (read: order) to include something in their product's documentation about a functionality that will not be released with the upcoming release (it will still be in development) but is hoped to be ready "shortly" (whatever that means) after the product is released. I've politely pointed out that industry best practice is to document what IS as opposed to what WILL BE and that certain liabilities might be incurred if promises are made and then something goes wrong. Any thoughts? -- next part -- An HTML attachment was scrubbed... URL: <http://lists.frameusers.com/pipermail/framers/attachments/20111205/913bbd2f/attachment.html>
2. Frame 10 XML/translation question (Michael Norton)
>FrameMaker10 contains an option on the File menu called Save as XML... >? >The nice thing about XML is that is doesn't require a structure (don't get me >wrong, I prefer structured XML, but, if this is a one-off document, it may be >overkill). Sue, wouldn't Michael lose any formatting that he requires for his PDF output using that method? Or are you suggesting he use a tool like Author-It to ingest his new XML files and output PDF? Nadine
documentation best practices
That's what I was thinking. It sounds more like marketing copy than user guide content. Nadine > > From: Jeff Coatsworth >To: "framers at lists.frameusers.com" >Sent: Monday, December 5, 2011 5:21:46 PM >Subject: RE: documentation best practices > > >It's called "marketing" ;>) > > > > From: framers-bounces at lists.frameusers.com [mailto:framers-bounces at lists.frameusers.com] On Behalf Of hessiansx4 >Sent: Monday, December 05, 2011 5:56 AM >To: framers at lists.frameusers.com >Subject: documentation best practices > > >I could use some insight into a situation I haven't encountered before today: how does one best respond to a request (read: order) to include something in their product's documentation about a functionality that will not be released with the upcoming release?(it will?still be in development)?but is hoped to be ready "shortly" (whatever that means)?after the product is released. >? >I've politely pointed out that industry best practice is to document what IS as opposed to what WILL BE and that certain liabilities might be incurred if promises are made and then something goes wrong. >? >Any thoughts? >___ > > >You are currently subscribed to framers as generic668 at yahoo.ca. > >Send list messages to framers at lists.frameusers.com. > >To unsubscribe send a blank email to >framers-unsubscribe at lists.frameusers.com >or visit >http://lists.frameusers.com/mailman/options/framers/generic668%40yahoo.ca > >Send administrative questions to listadmin at frameusers.com. Visit >http://www.frameusers.com/ for more resources and info. > > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.frameusers.com/pipermail/framers/attachments/20111205/a90b5fb0/attachment.html>
documentation best practices
We carefully mark any new unreleased functionality as "Pre-Release" or "Draft" - even when that content goes along with released information in the same document. Z From: framers-bounces at lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of hessiansx4 Sent: Monday, December 05, 2011 2:56 AM To: framers at lists.frameusers.com Subject: documentation best practices I could use some insight into a situation I haven't encountered before today: how does one best respond to a request (read: order) to include something in their product's documentation about a functionality that will not be released with the upcoming release (it will still be in development) but is hoped to be ready "shortly" (whatever that means) after the product is released. I've politely pointed out that industry best practice is to document what IS as opposed to what WILL BE and that certain liabilities might be incurred if promises are made and then something goes wrong. Any thoughts? -- next part -- An HTML attachment was scrubbed... URL: <http://lists.frameusers.com/pipermail/framers/attachments/20111205/421405e7/attachment.html>
documentation best practices
Not necessarily, but usually, I suspect. :) In our case, in some of our API specs, we sometimes send out information to our Customers for review and comment, before it is "released into production" so to speak. We clearly identify this information as "Pre-Release" or "Draft", with an introductory description that states very clearly that the functionality may not be available, and is subject to change when it is released ... or withdrawn too! Works for us pretty well! Z From: framers-bounces at lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of Writer Sent: Monday, December 05, 2011 2:27 PM To: Jeff Coatsworth; framers at lists.frameusers.com Subject: Re: documentation best practices That's what I was thinking. It sounds more like marketing copy than user guide content. Nadine From: Jeff Coatsworth mailto:jeff.coatswo...@jonassoftware.com>> To: "framers at lists.frameusers.com<mailto:framers at lists.frameusers.com>" mailto:framers at lists.frameusers.com>> Sent: Monday, December 5, 2011 5:21:46 PM Subject: RE: documentation best practices It's called "marketing" ;>) From: framers-bounces at lists.frameusers.com<mailto:framers-bounces at lists.frameusers.com> [mailto:framers-bounces at lists.frameusers.com]<mailto:[mailto:framers-boun...@lists.frameusers.com]> On Behalf Of hessiansx4 Sent: Monday, December 05, 2011 5:56 AM To: framers at lists.frameusers.com<mailto:framers at lists.frameusers.com> Subject: documentation best practices I could use some insight into a situation I haven't encountered before today: how does one best respond to a request (read: order) to include something in their product's documentation about a functionality that will not be released with the upcoming release (it will still be in development) but is hoped to be ready "shortly" (whatever that means) after the product is released. I've politely pointed out that industry best practice is to document what IS as opposed to what WILL BE and that certain liabilities might be incurred if promises are made and then something goes wrong. Any thoughts? ___ You are currently subscribed to framers as generic668 at yahoo.ca<mailto:generic668 at yahoo.ca>. Send list messages to framers at lists.frameusers.com<mailto:framers at lists.frameusers.com>. To unsubscribe send a blank email to framers-unsubscribe at lists.frameusers.com<mailto:framers-unsubscribe at lists.frameusers.com> or visit http://lists.frameusers.com/mailman/options/framers/generic668%40yahoo.ca Send administrative questions to listadmin at frameusers.com<mailto:listadmin at frameusers.com>. Visit http://www.frameusers.com/ for more resources and info. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.frameusers.com/pipermail/framers/attachments/20111205/f626b15d/attachment.html>
Is it possible to export a FM file without including all of the conditional text?
I have a group of manuals where I use conditional text to keep track of the different variations. My customer asked to have a word copy of one of the manuals. Is there a way to choose conditional text for the manual that I want which excludes all of the other conditional text in the final output? When exporting to an .rtf file, all of the information gets exported, even if I'm only showing the conditional text that I'm interested in. As a work around of last resort, I had to do a Show All and manually strip out everything I didn't want in the final version. There must be a better way. I've been using v7.1, but on the trial version of 10 I noticed the same thing happening. Does any one have any ideas? Thanks in advance! Laura Larson -- next part -- An HTML attachment was scrubbed... URL: <http://lists.frameusers.com/pipermail/framers/attachments/20111205/2ed1680e/attachment.html>
documentation best practices
I think you are right about all of this. It's marketing fertilizer. If you have documented (via emails, memos) the risks, then you are covered, even if the company is not. Aspirational material needs that disclaimer that stock prospectives have ( and I don't think your boss will want that legalese) Grant - Nadine wrote: > That's what I was thinking. It sounds more like marketing copy than > user guide content. > > Nadine > > > *From:* Jeff Coatsworth > *To:* "framers at lists.frameusers.com" > *Sent:* Monday, December 5, 2011 5:21:46 PM > *Subject:* RE: documentation best practices > > It's called "marketing" ;>) > > > *From:* framers-bounces at lists.frameusers.com > [mailto:framers-bounces at lists.frameusers.com] *On Behalf Of > *hessiansx4 > *Sent:* Monday, December 05, 2011 5:56 AM > *To:* framers at lists.frameusers.com > *Subject:* documentation best practices > > I could use some insight into a situation I haven't encountered > before today: how does one best respond to a request (read: order) > to include something in their product's documentation about a > functionality that will not be released with the upcoming > release (it will still be in development) but is hoped to be ready > "shortly" (whatever that means) after the product is released. > > I've politely pointed out that industry best practice is to > document what IS as opposed to what WILL BE and that certain > liabilities might be incurred if promises are made and then > something goes wrong. > > Any thoughts? >
