If you are a veteran of projects involving translation of your MadCap Flare content, you know the drill:

  • Zip up your Flare project
  • Upload it to your translation provider’s FTP or project portal
  • Explain to your translation provider what you need for your current project

It sounds simple enough, but factor in busy schedules, aggressive delivery timelines, and a constant workflow (can we say “agile”?) and these three steps can become cumbersome. The name of the game in today’s localization workflow is “continuous localization”. When it comes to your company’s core product, continuous localization of small subsets of UI strings for your app is an absolute requirement. The localized versions of the interface can tolerate no gaps in localization. User help and documentation are a bit more forgiving—to a point.

The critical nature of UI localization makes the higher cost of continuous localization—due to smaller translation volumes and faster turnarounds—a justifiable expense. While user help and related product documents are not as time-critical and do not drive revenue, it means that the additional cost and effort of maintaining a continuous workflow—at least at a cadence like UI localization—is not as easily justified. It makes more sense to do the translation in larger chunks and at a slower cadence.

“Git” Connected

Manually monitoring your Flare project and deciding when to proceed with a round of translation is another administrative burden you may want to avoid. A time and cost-effective solution is to use a Git repository to store and share your Flare project with your translation provider. For this solution to be most beneficial it is important that your translation partner’s translation management system can connect to your version control repository. The goal is to minimize the setup and lead time to translation and take the churn out of initiating your translation projects.

“Git” Started

Setting up the infrastructure you will need is easy:

  1. Set up a Git account (e.g. GitLab or GitHub)
  2. Upload your Flare project
  3. Provide the login credentials to your translation provider
  4. Your translation provider connects their TMS (translation management system) to the repository

If you are already using your own source control tool to manage your Flare project, you can connect it to the Git repository and push projects to Git when you are ready to start a translation round.

Preparing Your Content

Another step that should be taken is to prep your Flare project for translation. The goal is to identify which content is translatable and which is not. By using a “Do not translate” file tag at the folder level, for example, it is easy to provide the right project scope to your translation company. It is important that your translation provider knows Flare well and can carry out a thorough assessment of your Flare project and can make the necessary changes when it comes to properly defining conditions and file tags. Their knowledge of Flare and their own TMS should also enable them to prepare proper filters to reliably handle Flare project file types.

Will the Git Approach Work for Your Translation Needs?

Assessing whether a more streamlined workflow using source control and a content-connected translation management system is right for your company is worth a discussion with your translation partner. The discussion should cost nothing and knowing if your translation partner can support a greater level of automation is always good to know. But there are aspects of your Flare projects and your company’s translation needs that will drive whether such an approach will work:

  1. Publishing frequency: if your company only needs to publish translation updates once or twice a year, then it may not be worth the effort of setting up a source control solution. If your publishing schedule is active over each quarter and is consistent throughout the year, then better integration with the translation process is worth it.
  2. If the scope of work for each project/translation cycle varies—either the scope of target languages or documents—this diminishes the benefits you will get from the content connector. But if your menu of languages and document targets are stable then having a source control connection is a must!
  3. If you require that every translation effort be quoted prior to starting work then having Flare in translation-connected source control may not be for you. The process works best with an agreed threshold level for translation for each cycle and that the work is billed upon completion or monthly.

What Will Git Integration Look Like Once Implemented?

Once your Flare project has been uploaded to a Git repository, managing translation projects will get a lot easier.

  1. Your parent and translated projects will reside in Git.
  2. Files and folders marked for translation can be “watched” by your translation provider.
  3. All the benefits of source control now apply to your Flare projects:
    1. Secure
    2. File versions are automatically tracked and managed
    3. Easily accessible
  4. Your administrative work is greatly diminished since you no longer need to move and manage files.

If you are looking to improve the flow and efficiency of your translation projects—especially those that involve MadCap Flare—we would be happy to assist you in evaluating this approach for your company.