Hello all. Sorry for the longish post. I'm currently a RoboHelp user using RoboHelp 9, but I do own the latest MadPak (got it about a month ago), and started doing an extended evaluation to see if the rest of my team should switch to Flare instead of upgrading to the latest version of RoboHelp. I understand that since I'm posting this here, I'm sure to get some biased responses. That's fine though. I really want your candid opinions for or against from real users in the real world, especially those who have switched from RH in the last few years. Is it better or worse? About the same?
We're going through growth pains in our company and have to get more done on less time. I'm sure you're all familiar with the refrain.
Our main pain points right now are:
1) Printable outputs. Our main RH project results in ~2300 pages of content that we're trying to combine into a single manual (word doc and then print to PDF). Unfortunately, RH uses MS Word to generate it's printable output, and Word simply cannot handle large amounts of content efficiently. I've tested it in my trial version of RH 11 too. Same result. So we currently export our manual in chunks of about 6 chapters apiece and then manually combine them. Unfortunately, the post process time for this keeps getting longer and longer with more content added to our software product and more and more buggy behavior experienced working in Word. While I've tried Flare's printable output on the same project. It's an entirely different beast but I haven't found the time yet to get the result I wanted. What I'm looking for is as close to a 1 click printable output generation as possible, without any or much post processing work. Our ultimate desired target output for printed is actually PDF, not word. From what I can tell, Flare doesn't use Word under the hood to generate the PDF. We're really losing a lot of time on these post process issues each version. For example, just this week, I spent many hours on just a couple of printable outputs trying to figure out why Word ate my numbered and bulleted lists in some chapters with no way of getting them back. We need something that just works regardless of the size or complexity of the project. But what are your experiences with Flare's printable output? Do you had good experiences with Flare easily generating massive manuals from huge projects like this?
2) Localization. We're looking to be more efficient here as well. We currently localize the RH project into about 17 different languages. My team of writers is in charge of supplying the content to our localization coordinator who then uses contract Across Systems to store the translation memory from the imported topics. The untranslated items are then sent out for localization to the translators and they do their thing and make sure all the tags are placed correctly in the output. However, to just get the information into Across, with our largest project, our localization coordinator has to go through a long merging process that takes about a day to merge all the .htm topics together since Across chokes on so many little files. After localization, he then splits the translated merged files back into htms. My team then gets the localized RH project back, and we change the language settings in the returned RH project to the target language, and then build the necessary outputs (currently .chm and again printable Word as discussed above). There's quite a bit of post process work here too. Does Flare or Flare with Lingo offer a more efficient localization process?
Overall, we're happy with RoboHelp's easy-to-use UI, and after using it for a decade, I'm comfortable enough with it that were it not for the above pain points, I probably wouldn't consider switching.
Thanks in advance for your thoughts.
Is Flare (MadPak) the right product for my team?
-
Nita Beck
- Senior Propellus Maximus
- Posts: 3672
- Joined: Thu Feb 02, 2006 9:57 am
- Location: Pittsford, NY
Re: Is Flare (MadPak) the right product for my team?
Re your second question, I've pinged a Flare localization expert to see what she has to offer. I know that the company she works for has experience localizing both RoboHelp and Flare projects.
I'll weigh in on your first question: Is Flare better than RH for producing large PDF documentation? As a former RH user, let me shout "YES!" Flare is a far superior tool, and in the right hands, Flare can produce stuff that is much more sophisticated, attractive, and usable than what RH produces.
I used RoboHelp for almost 10 years and now am exclusively on Flare, having completed the migration all of my RoboHelp projects (and Word docs) to Flare by 2010. I used to use RoboHelp for creating Help and Word for creating user guides (saved then as PDF). I used RoboHelp to create Word docs only for review purposes, and I told my reviewers not to worry about formatting, as I didn't want to waste any time with all the post-processing to clean up the Word files, just as you describe as your experience. Anyway, I digress.
I do indeed now create large PDF documents out of Flare with a "click of a button," with VERY little post-processing. Flare is a marvel at this. That said, whereas one can dispense with all that post-processing work, the set-up work can be very time consuming; there're the style sheet (perhaps with mediums), table stylesheets, page layouts, and TOCs (not to mention the target itself) that have to be coordinated in order to produce that "click of a button" PDF. You'll probably also need to set up your variables (for things like the document title, among many others), snippets, and conditions. But that setup work is a one-time cost in sunk time, in contrast to the post-processing tasks that you have to do again and again and again.
For one of my RH projects, having now imported it into Flare, I produce a variety of PDF documents with it. One is a 7x9inch user guide, another is a DVD-case-sized quick start guide, and another an 8.5x11inch PDF intended as a tech support bulletin. (And the same project produces two different flavors of online Help.) Many of the same topics appear in all three PDFs, but they are formatted quite differently depending on the stylesheet and page layouts associated with the individual PDFs. And not only can I produce each with a "click of a button," I can produce all three + the two Help systems in a single operation. It's a much smoother operation than anything I ever did in RoboHelp + Word.
Start with importing just one RH project to Flare. In fact, BEFORE importing it into Flare, spend time cleaning it up as much as possible. Get rid of inline formatting as best you can. Then, when you import the project into Flare, be prepared to spend time doing more cleanup in Flare. But that cleanup time is well worth it because the cleaner your code is, the better it'll be for single-sourcing.
I also suggest that you migrate a project to Flare outside of a release cycle. Don't attempt a migration under that kind of pressure. You really need to take your time, observe, experiment, keep good notes, and finally work out what your processes will be.
Lastly, some of us (myself included) needed a lot of time to learn Flare properly. The learning curve for many is quite steep. Make sure that your group gets properly trained in the tool, and also gets trained in CSS at least to a competent level.
(P.S. I deleted your other post...)
I'll weigh in on your first question: Is Flare better than RH for producing large PDF documentation? As a former RH user, let me shout "YES!" Flare is a far superior tool, and in the right hands, Flare can produce stuff that is much more sophisticated, attractive, and usable than what RH produces.
I used RoboHelp for almost 10 years and now am exclusively on Flare, having completed the migration all of my RoboHelp projects (and Word docs) to Flare by 2010. I used to use RoboHelp for creating Help and Word for creating user guides (saved then as PDF). I used RoboHelp to create Word docs only for review purposes, and I told my reviewers not to worry about formatting, as I didn't want to waste any time with all the post-processing to clean up the Word files, just as you describe as your experience. Anyway, I digress.
I do indeed now create large PDF documents out of Flare with a "click of a button," with VERY little post-processing. Flare is a marvel at this. That said, whereas one can dispense with all that post-processing work, the set-up work can be very time consuming; there're the style sheet (perhaps with mediums), table stylesheets, page layouts, and TOCs (not to mention the target itself) that have to be coordinated in order to produce that "click of a button" PDF. You'll probably also need to set up your variables (for things like the document title, among many others), snippets, and conditions. But that setup work is a one-time cost in sunk time, in contrast to the post-processing tasks that you have to do again and again and again.
For one of my RH projects, having now imported it into Flare, I produce a variety of PDF documents with it. One is a 7x9inch user guide, another is a DVD-case-sized quick start guide, and another an 8.5x11inch PDF intended as a tech support bulletin. (And the same project produces two different flavors of online Help.) Many of the same topics appear in all three PDFs, but they are formatted quite differently depending on the stylesheet and page layouts associated with the individual PDFs. And not only can I produce each with a "click of a button," I can produce all three + the two Help systems in a single operation. It's a much smoother operation than anything I ever did in RoboHelp + Word.
Start with importing just one RH project to Flare. In fact, BEFORE importing it into Flare, spend time cleaning it up as much as possible. Get rid of inline formatting as best you can. Then, when you import the project into Flare, be prepared to spend time doing more cleanup in Flare. But that cleanup time is well worth it because the cleaner your code is, the better it'll be for single-sourcing.
I also suggest that you migrate a project to Flare outside of a release cycle. Don't attempt a migration under that kind of pressure. You really need to take your time, observe, experiment, keep good notes, and finally work out what your processes will be.
Lastly, some of us (myself included) needed a lot of time to learn Flare properly. The learning curve for many is quite steep. Make sure that your group gets properly trained in the tool, and also gets trained in CSS at least to a competent level.
(P.S. I deleted your other post...)
Nita
RETIRED, but still fond of all the Flare friends I've made. See you around now and then!
RETIRED, but still fond of all the Flare friends I've made. See you around now and then!
-
alt_jennifer
- Propeller Head
- Posts: 57
- Joined: Mon Mar 08, 2010 12:33 pm
- Location: Fayetteville, NC
- Contact:
Re: Is Flare (MadPak) the right product for my team?
Hello Jared!
Thanks for the ping Nita
I have indeed done localization projects in both RoboHelp and Flare, and let me just confess from the start: I did learn Flare first, so I might be a little bit biased in that regard. But I do very much prefer localizing Flare projects over RoboHelp projects. It just feels like an easier process, in general. Although it's probably improved some lately, RoboHelp has generally been more sensitive to the code page of the computer where it's running than Flare, and in the past it has sometimes been a pain to get a language other than standard romance languages to look right everywhere. Localizing Flare projects is fairly straightforward -- you just have to make sure you get all the content, know where to set the language setting, and know about language skins, and it'll run pretty smoothly.
To address your specific pain points...
- Across Systems needing all the small files glued together in order to process will not change with Flare. That's just a quirk of Across -- the number of files between RoboHelp and Flare won't be that dramatically different. Flare might require a different import filter than RoboHelp...I say might because I haven't used Across much, so I'm not sure what the filters look like these days, but I know that in our translation tools, we have different filters for each. Also, the tools that we've used with Flare and RoboHelp files (Trados Studio and MemoQ) have never really needed to have the files glued together. I have done that in the past, so I know what you're referring to. Some tools (like MemoQ) just really churn through files easily and quickly, while others don't.
- Post-Processing work... if you're referring to all the clean-up in Word that you've done for RoboHelp (fixing bullets, etc), you definitely won't need to worry about that in Flare for localization. The PDF outputs from Flare are immaculate -- they do exactly what you tell them to do in the styles, TOCs, conditions, etc. Now, if it's not doing something that you want, odds are that there is an error in the setup. It really does pay to get good training for Flare, and CSS if you aren't already comfortable with that.
However, anytime that there is translation being done (whether it's in RoboHelp or Flare), there is a good chance that some linguistic clean-up might be needed. I'm talking here about language-specific issues. For example, changing the fonts used to an appropriate Chinese font, copying in localized screenshots, or resizing a table column with a fixed width. The scope of this clean-up effort partially depends on how well the Flare project was setup for translation -- the greater the number of in-line snippets, variables, and conditions, the greater the chance of clean-up needed. (And this is true of RoboHelp as well.) There are steps you can take to internationalize your Flare project to reduce the number of issues during and after translation. (I have actually presented a webinar on this topic with MadCap: Publishing Multilingual Content from Flare - Best Practices for Quality Assurance, and I've compiled several potentially useful free resources on our site: http://advancedlanguage.com/services/madcap-flaretm/) Please note that this idea of setting up your project for translation to optimize clean-up efforts is also true of RoboHelp and any other authoring tool, so it's not specific to Flare.
With regards to Lingo, if you were to use it, it would essentially replace Across for you. You would import the entire Flare project, apply your translation memory, and bundle up the files that need translation to send to the translator. There definitely are some differences between Lingo and Across:
1) Lingo was designed for Flare projects, specifically, so it has a few Flare-related features that Across won't, like a nice preview function. (Lingo does support other file types too, like Word.)
2) It sounds like with Across, your coordinator is sending only the untranslated segments out to the translator. (I know some tools do that, not sure if Across does.) With Lingo, you have to send whole files -- so if a topic only has 1 untranslated segment, then the whole file gets exported for translation. Now, all the existing translations do appear in the exported file, and those segments should be marked as translated. So, when the translator receives these .xlf files (Lingo's import/export format), they just need to filter out the translated ones, so they don't get touched. XLIFF files are an industry standard that most translation tools support.
3) In the past, when I've worked with Lingo I've experienced a few difficulties with importing translated bundles. I think that's generally improved, but just know that it has happened. What I'm referring to is primarily that you might start an import, but then it stops in the middle with a vague error. Usually it's due to a tag error in translation, which can be mostly avoided with good translation checks, but it's hard to spot the problem when it does occur.
4) A lot of translation tools have standard segmentation rules pre-programmed in. Segmentation rules are what tells the translation tool how to split up the text into translatable chunks for the translation memory. Each of these chunks or "segments" should be a complete thought. All tools will say to break a segment after a period and a space, for example, since that's the end of a sentence. Most translation tools (like Trados Studio and MemoQ) also include exceptions to this rule, where a segment should not break after a period. For example, i.e. Mr. ca. etc. ... and I would imagine that Across already has many of these as well. With Lingo 8, you are now able to setup your own segmentation rules prior to importing files. The exceptions to the rules are not already programmed in, so if you need any of those in your content, you will want to add them in.
5) Here's the kicker for you: Lingo projects only work with 1 language, so since you are translating into 17 languages, you will need 17 Lingo projects. You also cannot change the language once you've created a project, so you can't just import into Lingo once, copy the project, and change the language. You would have to import the Flare project into Lingo 17 times. Across probably has multi-lingual projects, I assume, as most mainstream translation tools do.
6) Lingo projects also only work with 1 Flare project at a time, so if you do have more than one Flare project, each one gets it's own Lingo project.
I'm not trying to scare you away from Lingo, just show you that while there may be some overhead with Across right now, you will also have overhead with Lingo. If the only issues that you have with Across is the 1 day merging and 1 day splitting, I would probably stick with it. Better the devil you know, then the devil you don't But since you already own Lingo, your coordinator might just do a test import, and test-round trip to see how it works.
One final note: if you do switch to Flare, a lot of translators will not be familiar with it. It is definitely growing in popularity as a tool, so more and more translators will have experience with it, but many will not. Several translation tools have developed plug-ins to filter Flare files, but several still may not have a filter for it. At my company, we created our own filters awhile ago, so we have no issues. Some translators may not be able to set that up. If all of your translators are using Across, and translating the imported files that you give them, then you should only have to worry about setting up the import filter on your end. And if you use Lingo, the translators only have to worry about importing .xlf files, which most tools can do.
I hope this helps!
Thanks for the ping Nita
I have indeed done localization projects in both RoboHelp and Flare, and let me just confess from the start: I did learn Flare first, so I might be a little bit biased in that regard. But I do very much prefer localizing Flare projects over RoboHelp projects. It just feels like an easier process, in general. Although it's probably improved some lately, RoboHelp has generally been more sensitive to the code page of the computer where it's running than Flare, and in the past it has sometimes been a pain to get a language other than standard romance languages to look right everywhere. Localizing Flare projects is fairly straightforward -- you just have to make sure you get all the content, know where to set the language setting, and know about language skins, and it'll run pretty smoothly.
To address your specific pain points...
- Across Systems needing all the small files glued together in order to process will not change with Flare. That's just a quirk of Across -- the number of files between RoboHelp and Flare won't be that dramatically different. Flare might require a different import filter than RoboHelp...I say might because I haven't used Across much, so I'm not sure what the filters look like these days, but I know that in our translation tools, we have different filters for each. Also, the tools that we've used with Flare and RoboHelp files (Trados Studio and MemoQ) have never really needed to have the files glued together. I have done that in the past, so I know what you're referring to. Some tools (like MemoQ) just really churn through files easily and quickly, while others don't.
- Post-Processing work... if you're referring to all the clean-up in Word that you've done for RoboHelp (fixing bullets, etc), you definitely won't need to worry about that in Flare for localization. The PDF outputs from Flare are immaculate -- they do exactly what you tell them to do in the styles, TOCs, conditions, etc. Now, if it's not doing something that you want, odds are that there is an error in the setup. It really does pay to get good training for Flare, and CSS if you aren't already comfortable with that.
However, anytime that there is translation being done (whether it's in RoboHelp or Flare), there is a good chance that some linguistic clean-up might be needed. I'm talking here about language-specific issues. For example, changing the fonts used to an appropriate Chinese font, copying in localized screenshots, or resizing a table column with a fixed width. The scope of this clean-up effort partially depends on how well the Flare project was setup for translation -- the greater the number of in-line snippets, variables, and conditions, the greater the chance of clean-up needed. (And this is true of RoboHelp as well.) There are steps you can take to internationalize your Flare project to reduce the number of issues during and after translation. (I have actually presented a webinar on this topic with MadCap: Publishing Multilingual Content from Flare - Best Practices for Quality Assurance, and I've compiled several potentially useful free resources on our site: http://advancedlanguage.com/services/madcap-flaretm/) Please note that this idea of setting up your project for translation to optimize clean-up efforts is also true of RoboHelp and any other authoring tool, so it's not specific to Flare.
With regards to Lingo, if you were to use it, it would essentially replace Across for you. You would import the entire Flare project, apply your translation memory, and bundle up the files that need translation to send to the translator. There definitely are some differences between Lingo and Across:
1) Lingo was designed for Flare projects, specifically, so it has a few Flare-related features that Across won't, like a nice preview function. (Lingo does support other file types too, like Word.)
2) It sounds like with Across, your coordinator is sending only the untranslated segments out to the translator. (I know some tools do that, not sure if Across does.) With Lingo, you have to send whole files -- so if a topic only has 1 untranslated segment, then the whole file gets exported for translation. Now, all the existing translations do appear in the exported file, and those segments should be marked as translated. So, when the translator receives these .xlf files (Lingo's import/export format), they just need to filter out the translated ones, so they don't get touched. XLIFF files are an industry standard that most translation tools support.
3) In the past, when I've worked with Lingo I've experienced a few difficulties with importing translated bundles. I think that's generally improved, but just know that it has happened. What I'm referring to is primarily that you might start an import, but then it stops in the middle with a vague error. Usually it's due to a tag error in translation, which can be mostly avoided with good translation checks, but it's hard to spot the problem when it does occur.
4) A lot of translation tools have standard segmentation rules pre-programmed in. Segmentation rules are what tells the translation tool how to split up the text into translatable chunks for the translation memory. Each of these chunks or "segments" should be a complete thought. All tools will say to break a segment after a period and a space, for example, since that's the end of a sentence. Most translation tools (like Trados Studio and MemoQ) also include exceptions to this rule, where a segment should not break after a period. For example, i.e. Mr. ca. etc. ... and I would imagine that Across already has many of these as well. With Lingo 8, you are now able to setup your own segmentation rules prior to importing files. The exceptions to the rules are not already programmed in, so if you need any of those in your content, you will want to add them in.
5) Here's the kicker for you: Lingo projects only work with 1 language, so since you are translating into 17 languages, you will need 17 Lingo projects. You also cannot change the language once you've created a project, so you can't just import into Lingo once, copy the project, and change the language. You would have to import the Flare project into Lingo 17 times. Across probably has multi-lingual projects, I assume, as most mainstream translation tools do.
6) Lingo projects also only work with 1 Flare project at a time, so if you do have more than one Flare project, each one gets it's own Lingo project.
I'm not trying to scare you away from Lingo, just show you that while there may be some overhead with Across right now, you will also have overhead with Lingo. If the only issues that you have with Across is the 1 day merging and 1 day splitting, I would probably stick with it. Better the devil you know, then the devil you don't
But since you already own Lingo, your coordinator might just do a test import, and test-round trip to see how it works.One final note: if you do switch to Flare, a lot of translators will not be familiar with it. It is definitely growing in popularity as a tool, so more and more translators will have experience with it, but many will not. Several translation tools have developed plug-ins to filter Flare files, but several still may not have a filter for it. At my company, we created our own filters awhile ago, so we have no issues. Some translators may not be able to set that up. If all of your translators are using Across, and translating the imported files that you give them, then you should only have to worry about setting up the import filter on your end. And if you use Lingo, the translators only have to worry about importing .xlf files, which most tools can do.
I hope this helps!
Jennifer Schudel
Localization Manager/Flare Operator
Advanced Language Translation / http://www.advancedlanguage.com
* MadCap Recommended Translation Vendor *
Localization Manager/Flare Operator
Advanced Language Translation / http://www.advancedlanguage.com
* MadCap Recommended Translation Vendor *
Re: Is Flare (MadPak) the right product for my team?
Thank you both for taking the time to respond! I appreciate the prompt replies.
So, it sounds like switching to Flare would certainly help us in our printable ouptut pain, but maybe it wouldn't improve our Localization process all that much.
We'll certainly have to do something to get our printable output under control. Either switch to a better tool, or break up our Core printable manual in some way that makes sense.
Are there other reasons we should switch from RH? I have my own list of pros and cons I'm developing as I'm evaluating Flare, but I'd be interested in hearing your thoughts.
Also, does anyone know anything about AuthorIT and how it stacks up against Flare? AuthorIT came highly recommended by one of our sister companies in a recent meeting, so that's on the table too. Are there users here who used to use that, but are now using Flare? If you switched, what did Flare offer that AuthorIT didn't?
So, it sounds like switching to Flare would certainly help us in our printable ouptut pain, but maybe it wouldn't improve our Localization process all that much.
We'll certainly have to do something to get our printable output under control. Either switch to a better tool, or break up our Core printable manual in some way that makes sense.
Are there other reasons we should switch from RH? I have my own list of pros and cons I'm developing as I'm evaluating Flare, but I'd be interested in hearing your thoughts.
Also, does anyone know anything about AuthorIT and how it stacks up against Flare? AuthorIT came highly recommended by one of our sister companies in a recent meeting, so that's on the table too. Are there users here who used to use that, but are now using Flare? If you switched, what did Flare offer that AuthorIT didn't?
Re: Is Flare (MadPak) the right product for my team?
I haven't used RoboHelp in years. In fact, not since Adobe sunsetted RoboHelp, then decided a year later to keep it around because MadCap came out with Flare and Adobe suddenly decided that maybe they should keep the product. That put me off Adobe with regards to RH. The fact that MadCap was started by the RH developers that Adobe had laid off/fired didn't hurt.
All that is to explain that I haven't used RH in years and can't give an informed response, but one thing I have noticed from reading the forum posts is how much more responsive and helpful MadCap Support is compared to Adobe. Even if you don't pay for a maintenance plan with MadCap, they still provide a lot of help. (Quite frankly, I get the maintenance plan because it's cheaper than purchasing a new license of Flare each year, since the maintenance plan includes a free copy of the next major Flare release.) If you're someone who likes taking the time to solve problems and issues yourself and figure out your own workarounds, then support may not be a major consideration for you, but if you think you'll need help occasionally, then you can't underestimate the importance of a good (and responsive) support team. So really good product support from the manufacturer (in addition to this user forum) is another factor in Flare's favor.
All that is to explain that I haven't used RH in years and can't give an informed response, but one thing I have noticed from reading the forum posts is how much more responsive and helpful MadCap Support is compared to Adobe. Even if you don't pay for a maintenance plan with MadCap, they still provide a lot of help. (Quite frankly, I get the maintenance plan because it's cheaper than purchasing a new license of Flare each year, since the maintenance plan includes a free copy of the next major Flare release.) If you're someone who likes taking the time to solve problems and issues yourself and figure out your own workarounds, then support may not be a major consideration for you, but if you think you'll need help occasionally, then you can't underestimate the importance of a good (and responsive) support team. So really good product support from the manufacturer (in addition to this user forum) is another factor in Flare's favor.
Lisa
Eagles may soar, but weasels aren't sucked into jet engines.
Warning! Loose nut behind the keyboard.
-
alt_jennifer
- Propeller Head
- Posts: 57
- Joined: Mon Mar 08, 2010 12:33 pm
- Location: Fayetteville, NC
- Contact:
Re: Is Flare (MadPak) the right product for my team?
I don't know too much about Author-it. I've never worked with it or files from it before... I know that all the content is stored inside of a database, not in separate HTML files like with RoboHelp and Flare. And I know that they have a Localization Management module that would probably allow you to skip the Across step entirely, because their database will store all the content for all languages, and allow you to export only the new/changed strings into an xml file for translation. (Keep in mind that translation out of context like that means that having a linguist proof the final outputs would be even more beneficial.)
Beyond those two things, I don't know much else. You could request a demo I suppose.
But what LTinker68 said about MadCap support is spot on. They are super helpful, friendly, and very quick to respond. It's a huge advantage to using Flare!
Beyond those two things, I don't know much else. You could request a demo I suppose.
But what LTinker68 said about MadCap support is spot on. They are super helpful, friendly, and very quick to respond. It's a huge advantage to using Flare!
Jennifer Schudel
Localization Manager/Flare Operator
Advanced Language Translation / http://www.advancedlanguage.com
* MadCap Recommended Translation Vendor *
Localization Manager/Flare Operator
Advanced Language Translation / http://www.advancedlanguage.com
* MadCap Recommended Translation Vendor *
-
rob hollinger
- Propellus Maximus
- Posts: 661
- Joined: Mon Mar 17, 2008 8:40 am
Re: Is Flare (MadPak) the right product for my team?
Hello Jared and welcome to the forums.
My answer is biased because I work for MadCap. I was also one of those folks that used to work on RoboHelp (X5).
1. Flare should not have a problem producing a 2300 page PDF file. Our PDF compiler is native to our application and does not require any 3rd party software. The lists you see in the topics will be the same lists you see in the PDF file. Very few people ever have to do any post processing in PDF files if the content is set up correctly.
2. I see this a lot out there and it's a labor intensive expense that does not have to happen. Using Lingo as a management tool, it can import the Flare projects, send untranslated bundles to translators (XLIF standards work with Across) which are then sent back after being translated. Lingo imports and merges the translated bundles back into the topics. Lingo also supports the use of Translation Memories to avoid the expense of translating the same strings over and over. Lingo does import TMX files (Standard Translation XML files) and if you can get the current TM exported into a TMX file, it can be imported into Lingo.
The process would look something like this:
- Import RH Project into Flare
- Proof topics and clean up where needed
- Test PDF output
- Import Flare project into Lingo
- Get TMX file from Translation folks (one language at a time for testing purposes if this is an option)
- Import TMX into a new TM created in Lingo
- Apply TM to Lingo project
- Use statistics to report on what is left that needs translated
- Translate topics through use of bundles
- Import translated bundles
- Export Flare project fully translated from Lingo and deliver back to authors
- Build translated outputs and deliver
Of course this is a very high level look at the entire process. Let us show you first hand how we can help your entire team work more seamless with the translation process.
We can demo this process entirely using your specific workflow anytime you like, just send a message to sales@madcapsoftware.com. In that message link to this Forum post and that will get the ball rolling.
I'm not here to throw a sales pitch and realize you're asking your peers for advice, but feel we can offer you exactly what you are looking for.
Thanks
My answer is biased because I work for MadCap. I was also one of those folks that used to work on RoboHelp (X5).
1. Flare should not have a problem producing a 2300 page PDF file. Our PDF compiler is native to our application and does not require any 3rd party software. The lists you see in the topics will be the same lists you see in the PDF file. Very few people ever have to do any post processing in PDF files if the content is set up correctly.
2. I see this a lot out there and it's a labor intensive expense that does not have to happen. Using Lingo as a management tool, it can import the Flare projects, send untranslated bundles to translators (XLIF standards work with Across) which are then sent back after being translated. Lingo imports and merges the translated bundles back into the topics. Lingo also supports the use of Translation Memories to avoid the expense of translating the same strings over and over. Lingo does import TMX files (Standard Translation XML files) and if you can get the current TM exported into a TMX file, it can be imported into Lingo.
The process would look something like this:
- Import RH Project into Flare
- Proof topics and clean up where needed
- Test PDF output
- Import Flare project into Lingo
- Get TMX file from Translation folks (one language at a time for testing purposes if this is an option)
- Import TMX into a new TM created in Lingo
- Apply TM to Lingo project
- Use statistics to report on what is left that needs translated
- Translate topics through use of bundles
- Import translated bundles
- Export Flare project fully translated from Lingo and deliver back to authors
- Build translated outputs and deliver
Of course this is a very high level look at the entire process. Let us show you first hand how we can help your entire team work more seamless with the translation process.
We can demo this process entirely using your specific workflow anytime you like, just send a message to sales@madcapsoftware.com. In that message link to this Forum post and that will get the ball rolling.
I'm not here to throw a sales pitch and realize you're asking your peers for advice, but feel we can offer you exactly what you are looking for.
Thanks
Rob Hollinger
MadCap Software
MadCap Software
-
jknasinski
- Propeller Head
- Posts: 36
- Joined: Tue Jul 10, 2012 9:31 am
- Location: Milwaukee Wisconsin
Re: Is Flare (MadPak) the right product for my team?
We switched from AuthorIT to Flare a while back. We also have legacy projects in RH. AuthorIT was a pain; poor tech support, very expensive, long compile times, etc. Flare is so much easier and produces far better output with less work. Producing PDF from AuthorIT required a lot of post publishing time and effort.
AuthorIT also doesn't have the flexibility to set up everything for the HTML5 and PDF outputs that we needed.
Also using Flare with Lingo and Capture enables us to work faster and easier than anything we did in AuthorIT.
I love Flare. It takes time to do the initial planning and setup for PDF outputs but once done, it's single click.
The MadCap tech support has also been far superior to AuthorIT.
AuthorIT also doesn't have the flexibility to set up everything for the HTML5 and PDF outputs that we needed.
Also using Flare with Lingo and Capture enables us to work faster and easier than anything we did in AuthorIT.
I love Flare. It takes time to do the initial planning and setup for PDF outputs but once done, it's single click.
The MadCap tech support has also been far superior to AuthorIT.