DCL Learning Series

Marianne Calilhanna:

Hello, and welcome to today's webinar, "Reach Your Target DITA ROI with Localization-Ready Content Practices." My name is Marianne Calilhanna. I'm the vice president of marketing for Data Conversion Laboratory, and I will be your moderator today. Before we get started, I want to let you know, we will allow time at the end of the webinar for Q and A. So please submit your questions in the dialog box as they come to mind. If we don't have time to answer all the questions, we will get in touch with you personally after this webinar. And also this webinar is being recorded.

Today's agenda includes introductions to our panelists and their organizations, so that you can understand their expertise in both DITA and localization. Next, we are going to open a couple of quick polls to assess where you and your organization stand with the topic. And then we'll dive deep into the reason you are all here with us today. Localization ROI considerations and metrics. We are fortunate to have with us today two experts in the topic of DITA and localization.

We have Christopher Hill from Data Conversion Laboratory. Chris has a long history with structured content, DITA, XML and other types of conversion projects. We also have Dominique Trouche. He is the CEO of WhP. He is also a DITA expert, helping documentation teams of leading technology groups publish future ready content. Thank you both for putting this program together for us today. And now I'd like to turn it over to Chris Hill, from Data Conversion Laboratory. Chris.

Christopher Hill:

Thank you. Thanks, Marianne. For those of you who may not be familiar with Data Conversion Laboratory, let me just take a second and give a really big picture of what we do. So as you can tell by our name, we provide data and content transformation services. That's the data conversion part, and solutions around that. So we've really evolved over several decades of using a lot of innovations in the computer industry to accomplish this goal.

And that includes a lot of artificial intelligence technologies like machine learning, some natural language processing. Whatever it really takes to help businesses organize and structure the data and content they need for today's modern platforms and technologies. We work across a number of industries, and if you look at this slide, there's a lot of information here, but this covers the breadth of what we do.

So it really isn't just data conversion. There's a lot around that in today's age of content that accompany that. And that might include metadata enrichment. We may be extracting information from content that already exists, harvesting data, doing quality assurance on the content that is created. And then of course, around the DITA topic, we do a lot with structured content delivery and content reuse. So that really is where we intercept with this topic.

And we work across a lot of industries. We have quite a huge portfolio. We go back to the '80s. So that gives you some idea of how many organizations we've encountered over the years. This is just a small set of them, but it gives you an idea of the verticals that we've served over the years and continue to serve, as well as some of the big customers that we have in those verticals. So I'd like now Dominique, to tell us a little bit about what he does at WhP.

Dominique Trouche:

Yeah. Good morning. And I'm Dominique, so for those who are wondering where my accent is coming from. So I'm French and living in Canada. So WhP, we are a language service provider. We're serving global technology group. We've been serving global technology group for 25 years, mainly focusing on technical documentation. So starting with SGML, XML and for the last 15 years on working with DITA.

So around DITA, we provide localization services. So multilingual localization services, we have a lot of subject matter expertise to the customers. So that's where we started, some 15 years ago. And then for the last four, five years we've been adding consulting services, because we've been supporting customers in setting up best practices and help them improving the content. And they ask us to come and help them a little bit further.

So we work with them to optimize their content, to optimize their processes, whether the content processes or the localization processes, and then we help them as well on content migration. I would say beyond what DCR is doing. We help the customer migrate from their DITA content to their DITA localization ready content. And then we also have design technology at very beginning for our own services.

So we have designed DITA layer on top of what we call the TMS, which is a transition management system. And this DITA layer copes. We have a lot of DITA specificities and automated workflows and linguistic quality control. So this technology we designed for ourselves at the very beginning, and now we are also setting it up for several customers.

So we address different markets, you can see on the left. So IT, telecoms, software publishers, life science, industrial automation, energy and transportation. And you can see this is the adoption rate of DITA. Actually DITA was started some 15, 16 years ago with IT, telecom and software publishers, then life science and medical device especially, then industrial automation.

And we are now in ... Most of our new coming customers are in transportation and energy. That's where we stand. And on the right hand side, you've got the services. So one label has been skipped, it's about software, but we localize documentation and software around DITA. In some industries, we've got product labeling as well, which is also managed with DITA. And more and more growing training content managed with DITA as well.

Christopher Hill:

Great. So before we dive into the meat of this presentation, let's get our viewers involved and have a quick poll here. So we're curious about where you currently stand regarding DITA, and you can just choose whatever answer best fits your organization from this list. I'll give you half a minute or so to answer this, and then we'll share some results.

Marianne Calilhanna:

Chris, I can see a couple people are still ... We're still collecting a couple of responses, so we'll give it just another minute. And we're really looking ...

Christopher Hill:

Yeah. No problem.

Marianne Calilhanna:

We're just asking our attendees to select the answer that really aligns the best with your organization. Okay. I see that most folks have submitted. So I am going to close the poll, and I'm going to share the results.

Christopher Hill:

Great. Looks like a lot of people are thinking about DITA, which is my experience as well. So that's the majority here, but I'm pleased to see that there's a substantial number of attendees who are using DITA and are satisfied. So that's great to hear. I think if we had done this poll about five years ago, the results would be very different. Things are evolving in the content industry, good to see. So those are the results. So Dominique, as a local [crosstalk 00:09:09].

Dominique Trouche:

If I can just add on that. There's also something which is interesting, is that the first line is using DITA for years and planning a new model. That's a new trend we are seeing right now, because the early adopters of DITA have been using data for seven, eight years. And many of them are now switching to a next gen project, we want to do more with DITA or to work better than we're used to work with DITA 1.1 some years ago. So I think it's significant.

Christopher Hill:
Yeah. Actually, that is good. I'm glad to see that too. I guess we're just seeing an overall maturing of the DITA projects and use. So Dominique, as a localization expert, what thoughts can you share with us for people who are either contemplating a move to DITA or are evolving their DITA projects?

Dominique Trouche:

Okay. So we can see ... So we've been working with plenty of different customers. And what we've seen is that DITA adoption, most of them have been migrating to DITA. They have a DITA project as triggered by the documentation manager or documentation team, but wants to use a standard, but they have different objectives. They want to be able to do more content, reuse to improve the content, the user experience, to have a better, more efficient content management.

There are plenty of other reasons. More delivery channels, easier onboarding of new technical writers, plenty of different objectives. But when it comes to selling this project to the C-level managers, these managers, they want to see figures and commitment. And the commitment from the documentation team to the C-level is okay. On the long run, we'll do more with less.

So we'll have more languages, we'll have more publishing outputs, something like that, with less money. But for the time being, it won't change that much. All the rest, content reuse, user experience, it's going to be soft factor. It's very difficult to factor in. And then what we can see is that 95% of the ROI sold to C-level is quite exclusively based on cost savings in localization. And it's really impressive that all this ROI are exclusively based on localization.

While to be honest, localization is hardly really taken into account in the adoption projects. Very often it's considered as a given, that once we'll be reusing, once we'll have less words, we'll have less cost. And it's going to save a lot of money. That's basically what you can see from this ROI. So everything is, let's say it's driven by localization. So I'm here to be the voice of localization and to see okay, all the ROI are based on localization. So how can we ensure that these ROI are actually matched or reached?

Christopher Hill:

Yeah. Great. So since you brought up the topic of localization, as I expected, let's go ahead and ask our viewers where they stand regarding localization. So again, here's a short poll, if you would just select one of these five answers that best matches your organization or you with localization. And I'll give you a minute here to get those answers in. And if you haven't answered yet, go ahead and just click one of the five that best aligns with your organization. And in a second here, we'll see if there's any interesting trends in that result.

Marianne Calilhanna:

I'm going to allow folks just another couple of seconds, we're inching up to the same response rate as the first poll. So thank you all for your input. I'm now going to close the poll and share the results with everyone.

Christopher Hill:

Okay. So it looks like as I expected, the majority of the people on this webinar are very interested in localization, because they're actually localizing to more than five languages, five or more languages. And although there are a significant number, the number two result I see there is that they aren't doing localization right now, but likely will in the future. And I do see still a lot of that across the industry right now.

Dominique Trouche:

Okay. So quite interesting. Yeah.

Christopher Hill:
Yeah, for sure. So Dominique, when I first moved to DITA, I know that there's a fairly substantial investment. That's one of the reasons that as you mentioned in the previous slide, that I go to localization as one of the places to try to make an ROI case for moving to DITA. So maybe you can share with us some of your thoughts on that initial investment and when to start expecting payoffs or when people think they should expect payoffs.

Dominique Trouche:

Okay. So first of all, I want to share with you all a short survey that we performed with a hundred companies recently. We asked those a hundred companies, have you reached your ROI? We've taken companies which have been migrating to DITA for more than two years, because the first two years, it's very difficult to say exactly where we stand with the ROI.

But you can see that, let's say three out of four actually claiming that they have not reached the ROI or not at all a reached the ROI. And that's quite, I would say disappointing, I would say. Maybe it was because the ROI was, expectations were too high. But mostly it's because the way it was implemented didn't reach it. Marianne, can you switch to the next one?

So basically we analyzed with those companies and that why this ROI was not reached. And when I speak about ROI, I also speak about turnaround time, because in many instances turnaround time is as important for customers than ROI is actually. So we've been looking at why it was not achieved. And basically we found several reasons we want to share with you, and you want to see how it matches your issues or your concern.

So the first reason is that the content very often is redesigned. When people migrate to DITA, they want to implement many changes they had in mind and that they didn't have time or didn't plan to migrate. So they redesign the content. And of course, when you redesign your content, since you are relying on transition memories and your content was already well managed with transition memory.

When you redesign your content, you have a lower leverage with transition memory and you can see an increase in the cost of localization, even though you might have less words. The second point is the low reuse. When you migrate your legacy content, you migrate several documents and you might have different, let's say different paragraphs, which are migrating topics. And you might have redundant topics.

It's very difficult to actually see what's a reuse and to be able to leverage this reuse from the former content. Another one, which can seem let's say small one, but it can be very significant. It's a loss of transition memory leverage. When you migrate from a Word document or you migrate from FrameMaker document into DITA, you change a little bit of format. You migrate the content to XML, also a PDF, might be exactly the same.

The structure of the content might be slightly different and you might have inline tags, which are a little bit different. So when you go to localization, the transition memory might have a lower leverage. So you might lose five or 10% of leverage, about five or 10% when you localize into plenty of languages and you have a huge content, might be very significant.

And the last point we've seen there is that very often customers over estimate the value of legacy transition memory. They were working from time to time with plenty of vendors with different transition memories, different setup, something like that. When they put all of them together, because when they switch to DITA, they switch to only one vendor, because it's more complex and they channel all their transition to one vendor.

When we put all the transition memories together, they're not that consistent and there's some loss in this transition memory. So very often we can see customers which have expected or they have thought that they will have a decrease in the transition costs from very first year. They can see a significant increase the first year.

Christopher Hill:

So we had some customers where the increase was 70, 80% on the first round of transition. Fortunately, all those are related to transition memories. And once it's been run once in the transition memory, then we get the actual leverage. This short term impact, which can be rather significant is as it's named, it's short term. So once you passed over that, it should be over.

So it sounds a bit like when I learned to advance my skiing. I started off snowplowing, got quite good at that. And then for a while, while I was trying to switch to learn to parallel ski, I was falling down again and couldn't go down the same slopes I used to. I guess it's, when you're trying to make an advancement like this, there's always some of that short term investment.

Dominique Trouche:

So it has to be considered as investment. You have an investment when you migrate to DITA, you have an investment in training people, in setting up tools, something like that. You have to consider that's going to be an investment in your localization as well, because you decrease efficiency of your transition memories. It has to be considered as an investment, but it should not be forgotten.

Christopher Hill:

And it sounds like, for sure that expectation should be set early on in the project. So that you don't catch a lot of heat that first year, as you make that investment.

Dominique Trouche:

I know some documentation manager, which had some heat when they came to their C-level and explain that instead of a decrease in localization, we have an increase.

Christopher Hill:

Yeah. Nobody wants to go to their boss with that, for sure.

Dominique Trouche:

Okay.

Christopher Hill:

So looking at the next slide that you offer here. It sounds like there's more to the move to DITA than just changing the format, right? It sounds like there's still some strategic things that have to be taken into account.

Dominique Trouche:

Yeah. Especially when you think about localization, and we think that your content will have to be localized. We analyze ... Let's say some important impact is coming from the content information model and the content quality. As you can imagine, the translator is translating the content which has been written by a technical writer. And of course his cost depends a lot on the content itself.

So let's see how it can impact. So first thing we've seen is that the reuse ... Let's say we had less reuse than expected, because sometimes customers are missing the reuse strategy. Reuse is not coming by chance because you are using DITA, reuse is coming because you are having a reuse strategy. And if you enforce this strategy, because very often we've seen, let's say technical writers, which are a little bit independent, missing style guide, missing a re-use strategy in order to be able to share content. So that's quite important.

Second one is the content update. And when you are maintaining content in different languages, you might have a lot of updates which are coming, software UI, product names, support numbers, something like that, which are embedded in the software and which are out of control of the technical writer. And since more and more the localization technical writing is becoming agile.

So the content is written more and more, while the product itself is not stabilized. So there's far more maintenance to be doing on the content side. And if maintenance is not properly supported by the content, it can be very expensive. Just take an example. If you localize software into several languages and you write the documentation of the software, which is to be localized for instance, in Chinese.

So if after a couple of months someone wants to change the UI in Chinese, you have to go to all your documentation languages, to your transition memories, to update the UI term in the translation. And this can be very costly if you a huge content. So the information model shall support this content maintenance. The third one is someone which is very difficult to understand for most technical writers, because they speak English and English is a very simple language.

And when you go to another language especially, and when you have content. For instance, let's suppose you want do reuse, and you are using a lot of variables, conrefs, conkeyrefs, however you want to do it. Your sentence might be perfectly correct in one instance with one set of variables or conref, but it can become completely wrong when you go to another conref. Because in the target language, the noun could have a different gender or could have a different way of spelling, depending on the case, on the plural.

And just think about a smart phone, or you have one sentence where you speak about operating your smartphone. Your smartphone in Spanish is masculine. But if you replace smartphone and say, okay, now let's talk about operating my iPhone. iPhone in Spanish is feminine. So all the wording, the articles, the adjectives will be different. And you can write as technical writers, content which is completely non-translatable.

It's not just because people don't like to do it. It's because it's not translatable or you won't be able to ensure that whatever configuration, your content will be right. So it's something which is very important to take into account when you write the content. Fourth one, we see very often is graphics. You have graphics. And there's a saying that say, okay, an image is worth a thousand words. When it comes to localization, I will say an image is worth a thousand words as well.

So it's costing a lot. Because when you have to type graphics, one is called bitmaps. So with JPEG, PNGs, another one is vectorial. When we think about vectorial is usually we think about SVG, scalable vector graphics. But it's also EPS or CGM when we're working in a CAD environment. This vectorial format means that the text is available in full transition, usually where XML file. SVG is actually an XML file.

So it means that the text is available for translation, is available as such in the file. So it's easy to localize. When you go to bitmaps, you need to find the original content. For instance, an illustrator or visual or any other tool, and then to localize it. And then to regenerate with PNG and of JPEG. And we see very often documentation that's still embedding PNGs for a graphics. Of course, obviously part of a graphics are screenshots.

And screenshots are by essence bitmaps, but there are still solutions around screenshots. Some of them more user friendly than others, but there are solutions on that. So graphics can be a very significant part of a cost. Especially when you might have some DTP. When you migrate to DITA, many people will tell you, okay, at least you get rid of DTP. But if you've got plenty of graphics, and if you manage them in PNGs, you going to still have significant DTP for your project.

Then conditional content, reuse very often is supported by conditional content. We've seen some of our customers are managing a huge set of conditions. One of ours is managing at least 200 conditions, depending on the content. And text is very complex to maintain, because of conditions. It's very difficult to have sentences where part of sentences is changing depending on the conditions.

So it's difficult to maintain in English, and it's very difficult to translate it. It can also mean that the content is not translatable at all, because you can have the same thing as a non translatable structure. You can end up with content, which depending on conditions will not work. So it's extremely complex to translate. So that's a simple recommendation, do not conditionalize part of sentences, conditionalize sentences or DITA elements. It's even better.

I appreciate that sometimes you cannot conditionalize DITA elements. When you think about title or CMD, where you can only have one. But then at least conditionalize sentences within this sentence level. Then there are many others. And I'm pretty confident every time we work with a new customer, we'll find a new potential issue. For hardware suppliers, measurement units might be an issue.

You might know that the United States and part Canada is using a measurement system which is not the metric system. And when you localize to other countries, measurement units have to be converted.  It should not be left to the translators to convert these measurement units into others. There should be some ways to do it a little bit better to ensure that the transition and the localization for different countries will be consistent and reliable.

Another requirement that we see more and more now is the accessibility. In the U.S. there's a lot of requirement now, a lot of RFPs require that documentation is compliant with accessibility act, which usually means that every single ... There are plenty of, let's say the book is four or five centimeters thick when you print it. Very often, it means for technical documentation, it means that every single image has to have alt text in order to be read by screen readers.

And this alone has a significant impact in localization, if you are using icons within sentences. Because when you have alt text embedded into a sentence, so it makes it more difficult. So plenty of small things like that. Formatting, I'm personally lobbying the Technical Committee of Data to cancel the bold, italic and any formatting elements from DITA, because these are very difficult to translate for several reasons.

First, think about a traditional Chinese character printed in italic bold, how it's going to look like, or Arabic language. How it's going to look, Arabic character in italic. It doesn't work. But then for the translation, it also means that the translator, when he's translating your content which has been set to italic by a technical writer, he knows that this content he is translating is special. But he doesn't know why. He doesn't know to what it should be consistent.

So even something that is italic, the technical writer has put it in italic on purpose. So it should be mentioned clearly why it's been put into italic. It might be because it's a warning, because it's a system input. So it might be tagged with a semantic tag if available with DITA. If it's significant, it might deserve a specialization.

But if it's not that significant to deserve a specialization, maybe a simple output class that would be managed by your CSS will be able to fulfill your requirements and will certainly help the localization. So there are plenty of others. So you've seen the three dots eventually, because basically we have a list of maybe 200 tricks we have identified with different customers. And therefore every single data instance, we can find other tricks for localization.

So this, all what I mention here lies in the information model. So whatever the technical writer is writing, it might make it difficult. But even when information model is correct, the content quality is very important. And it's very important that you have style and terminology consistency, and that you enforce it. There should be style guides for technical writers, and this style guides should be improved on a regular basis.

So what we strongly recommend is to make sure that we have some rules that can be enforced. So you can have some tools like Acrolinx, [inaudible 00:34:14] or many others on the offering level. But you have some simple rules that you can set up, some Schematron rules that you can implement, to implement some simple rules.

One rule we are supplying for free is sentence length control. If you have a sentence which is 50 words, it's going to take four times more to translate than a sentence which is 25 words. So when you multiply sentence number of words by two, you multiply the cost by four. And I guess for content maintenance, it's a similar metric. So a lot of rules should be implemented and best practices among technical writers. And we strongly advocate, and we have set up for several customers.

We strongly advocate for DITA peer review. Let's say, when you are doing software design, you set up peer review between developers to make sure that the code is written the same way, and some qualities is enforced. I believe we should do the same for technical writers, and to have these people reviewing the way they write DITA among themselves.

And not just to have a review of the published output. And this would be worth a lot of money, because there's going to be significant reuse of content and transitions afterwards, if you implement that. So these rules short term are basically the most important rules that you need to implement on your content to make sure that it's going to be localization friendly.

Christopher Hill:

Great. Now, you've talked a lot about the content here and that's great. What about the localization process? What are some of the issues that we need to be aware of when we're translating XML and DITA content, as opposed to just translating say plain text?

Dominique Trouche:

Yeah. Of course, once the content is perfect then you need to have a perfect process to manage this content. The first thing we found in a localization process is, when people are migrating to DITA, is that there's explosion of a number of files. When you have one single Word file or one single FrameMaker project, when you go to DITA, sometimes you've got 400, 500 files. We've got customers which has up to 7,000 topics for one document.

And of course, then it can't be handled manually any longer. You need to have some servers with workflow, with proper file management. You just cannot track the progress on an Excel table and work with a desktop transition management system. And this is quite important. It might be very significant. The second we've seen is, let's say LSPs. LSP stands for localization service provider or language service providers. Some of them which are not DITA aware.

This can end being uncorrect settings of a TMS. I think there a couple of rules which are rather important to identify if your LSP is DITA aware. If you ask them, do you know about DITA? And if the answer is yes, we know about DITA, it's just another XML. You better worry. And if they tell you, yes, we know about DITA. Can you send us a PDF as well?

So these are two indications that although he claims to be DITA aware, he might not be that much DITA aware. So this can lead to unproper segmentation, can lead to tags which are not properly managed, whether inline tags or a segmentation or element tags. It can lead to content which is not properly filtered. So the worst case is that you're going to pay a little bit more to match.

In the worst case, you can have content which does not publish correctly. And that's of course, or you have a lot of exception handling afterwards to make sure that when it's delivered, it's going to work in your CMS or in your environment, whether Git or whatever. So that can lead to ... And then what's happening as well very often, is that when you migrate to DITA, you are in a change management process, you are in some kind of unsafe situation.

And if you have to train at the same time, your LSP to DITA how to manage it, you're going to be in an even more difficult situation. While if you work with a DITA competent LSP, this DITA competent LSP will help you and will help you stabilize or make sure your process is properly under control. So instead of being a help, it's going to create problems. So this is quite important.

Third one is a little bit more unexpected, I would say for many of our customers. In many regulated industries ... Sorry. In many industries, especially regulated industry, you have to ensure that your content is reviewed once translated. That someone, what we call a local subject matter expert or in-country reviewer. Someone that can speak the target language is reviewing the content once translated.

What was usually done when we were talking about Word, FrameMaker documentation, I would say unstructured content, is that usually there is the local subject matter experts were redoing the PDF. And they were able to make changes and then to finalize the PDF afterwards. When we get to DITA, you cannot expect the local SMEs to be able to review the XML content, the DITA content.

So if you expect them to read you a PDF, it's going to be too late. It means that the transition memory have been set up. It means that it's been delivered in the CMS. Then you will have a complete workflow, someone making the change, sending it back to the translator so that the translator delivers again. And so there's a lot of exchanges there, which can damage the turnaround time and damage the ROI.

So this is really to be taken seriously into account. So how do you perform a linguistic review, once you have migrated to DITA or to any structured content? It's valid as well if you're using any other XML, including S1000D. You will have the same issue on linguistic review. And this shall not be underestimated. It's true for regulated industry where you have to commit that it's going to be done.

For other industries, you can claim, okay, well, I'm working software. It doesn't really matter ... Let's say we can afford having no linguistic review. The point is that if you let your LSP work without any review for several years, you can expect that the eventual quality will decrease. So you cannot let your LSP work without any control on your side of why it's going to be striking back sooner or later. So linguistic review is an important part of it.

And then, last point is DTD and schema compliance. It's surprising that even the best in class LSPs, which are well aware of DITA, something like that. They quite never have over 90% right first time delivery. So it means that 10% of the project which are delivered are not publishing, for plenty of reasons. Let's say, it can be most of the TMS check, ensure that the content which is delivered is XML compliant. But it can be fully XML compliant, but not compliant with your DTD.

Take an example, you have the menu cascade element. Menu cascade element is a list of UI controls. Let's suppose someone adds a character to match. So for instance, a space in between the UI controls. It's going to be fully XML compliant. It will not publish in DITA, and it will not publish in your DITA especially. So these are the type of things which are impossible to prevent by filtering the content.

And it can lead to content which is not consistent and compliant with your DTD or [inaudible 00:44:31]. And every time a project is delivered which is not compliant, it means that you have an exception to handle. You have to come back to your LSPs and say, hey, this file doesn't work. And can you please check and correct and so forth. So it can be significant as well in terms of duration, in terms of cost.

Christopher Hill:

Okay. Well, now if you ... Yeah. Go ahead.

Dominique Trouche:

There might be a couple others as well, that I just mentioned in the slide. When you go for publishing as well, you might have ... And you use DITA open tool kit, you might have some tricks as well coming there from different languages. But these are the main points. There are plenty of others, of course.

Christopher Hill:

So, you've familiarized us with a lot of issues there. And there's a lot to think about with that. That leaves us wondering now, how much is at stake here? And are there some tips you can give us to help us navigate these waters?

Dominique Trouche:

Okay. So first, how do we start? I hope I give you some ideas, some tips about things that can go wrong or can go better. So how do you address them? So I think it's not ... There cannot be a list of all the tips, because it might not be relevant if we were to implement all of them, it would be too much an effort.

So basically what you need to implement this type of, let's say process of improving your content. You need a little bit of DITA expertise. You need a little bit of localization expertise, and you need a huge beat of common sense. And I guess if you are listening to this webinars, it's because you have already some common sense and you realize that it would be interesting to learn.

So common sense, and if you believe, you're going to find very soon all the tricks that are relevant for your content. But if you want to save time, of course DCL experts or WhP experts, we are ready to help you on that. But what's at stake? And that's surprising. Usually when we're doing this type of, let's say benchmark with our customers, usually often we might be working in plenty of different industries.

We've been doing for medical device, for pharmaceutical companies, for companies which have been using DITA for a long time. Some companies more recently software publishers, something like that. We very often come back to the same order magnitude. We identified this 40% efficiency, which is available in quick wins.

When I say efficiency, I mean return on investment or turn around time, effort, cost of vendor. You will find this 40%, a little bit everywhere. And it's in quick wins. Very often, it's something that's very simple. So just one example is, instead of saving as PNG, you save as SVG. And you might save already five or 10% just by doing that. So these are the types of things that very significant.

Then usually we'll have another 20%, which is available on the longer run. It might be more consistent. It might be implementing tools for offering. It might be working on terminology, it might be setting up some specialization or managing more output classes in publishing.

So those 20% might be only available on the longer run. So they're more difficult to reach. But this 30% efficiency in quick wins, I'm ready to bet whoever is listening. That if we work with you, we're going to find easily with you, this 40%. Or if you work, you're going to find this 40% very easily.

Christopher Hill:

Great. So looking a bit further down the road then. And you mentioned this actually, when we did the DITA poll at the beginning of how some people are in their next generation of DITA. So looking down the road, what trends do you see ahead?

Dominique Trouche:

Okay. So there are several trends. The most common, and I mentioned already, it's not even a trend. It's something which is happening. It's agile content management. Can you switch to the next one, Marianne? There might be another slide. Yeah. So agile content management. Let's say, this is coming from software industry. Agile software design is becoming ... It's no longer a question, it's based on that.

So 90% of software company are working agile. In the documentation offering, it's becoming more and more common. So very often now, the technical writer is embedded in the Scrum team designing the software. And we can see that happening as well for the hardware design. And of course, that's the same requirement for content localization. So we can see that for instance, for many software companies.

We have helped them migrate from simultaneous shipment in different languages, from three, four months to three weeks. And it's rather important. The second is taking into account documentation as part of a product. When you design the UI, designing the documentation to have contextual help in the product, completely integrate the software, the documentation in the product design itself.

Last part, and it's documentation offering beyond ... I think documentation shouldn't have been the right word here. It's content offering beyond documentation. We can see many, many companies which said, okay, we are managing now documentation in DITA. So what's next? And we can see many more types of content.

We've got some customers I mentioned, which are doing multimedia and training content with the learning and training specialization, which from DITA 1.3 has been included in DITA standard. But we can see as well, maybe WhP on our side, for instance. Our commercial proposals are written in DITA. So we see people are writing their documentations and their commercial proposals in DITA.

So we can see for instance law firms, which are building their documentation in DITA. And now, we see more and more requests around multimedia, and that's something we are working on. So how to make videos from the documentation, or to make sure that the video is localized at the same time the content is localized. So that's for content.

And we can see localization, that we have a request to go more and more languages. So we can see plenty of customers that say, okay, we will not localize. Everything will be in English. Sooner or later, they come and say, hey, now we have a special agreement contract with one customer and we need to have it done, or we've been acquired. Plenty of things. So I've seen at very beginning, a couple of people that claim that their content will never be translated. It would be worth challenging.

Christopher Hill:

Never say never. Right?

Dominique Trouche:

Yeah. Definitely.

Christopher Hill:

Well, thank you, Dominic. This has been really informative for me I know, and hopefully for our audience. Do you have any final closing thoughts we should ...

Dominique Trouche:

No. I think I'd say, I've been working in language industry and that's a wonderful industry, because you have so many nuances. It's very difficult to anticipate all the issues. So we have plenty of issues, plenty of tricks we discover, and that's the beauty of our business.

Christopher Hill:

Great. All right. Well, thank you. I'm going to turn this back over to Marianne, and we'll see if we have some questions from the audience. I think we still have a few minutes left.

Marianne Calilhanna:

We do. We do have a few questions. Let's see if we can get through a couple of these. So one of the first ones is, do we need a CCMS, a component content management system, if we are localizing into many languages?

Dominique Trouche:

Yeah. It's a question which is coming rather often. You will need at some point to manage the dependencies between languages, the content into different languages. You don't need the ... I know large companies which are working without CCMS, but it's worth considering a CCMS. It might save you effort in managing the links and the dependencies of all the topics and different languages.

When you localize, it's adding another dimension on your control and managing with the CCMS would certainly be worth. I'm not a CCMS vendors, so I will not tell you which one. I believe the prices are not that high compared to value. So it's worth considering, but it's not mandatory. If you have a proper LSP, the LSP will be able to manage your content, even if it's not coming from a CCMS which is featuring the content. So we can see sizable customers using Git very often. Especially software publishers. It's very popular there.

Marianne Calilhanna:

All right. So here's one, can you give us a range of how long it would typically take to migrate from a FrameMaker based offering tool to DITA?

Dominique Trouche:

I think it's a question for you as well. So I think the answer is very simple, so it depends. It depends on the volume. Of course, it depends on how you want to achieve. I think usually the projects are in the range of, we are talking about a couple of quarters, in between a couple of quarters to one year. So Chris, maybe you can answer that as well. So it's a little bit depending on of course, on the volumes you are having.

Christopher Hill:

Yeah. Yeah. I would echo that. For sure, it varies widely. And I think one of the things that I have often seen in the past is people underestimate a lot of the softer issues that you brought up earlier. So they focus a lot on what it takes technically to move the content itself and training [inaudible 00:56:48] on the software. But I really liked that you highlighted a lot of the things, just the way I offer and what I write has to change too.

Dominique Trouche:

Yeah. One of the challenges obviously is the training of the people, is let's say change management and you shall not forget that these people still have to deliver at the same time. So technical writers, they have to deliver to maintain the former content while investing in the new structure. So it's very often challenging in terms of manpower, this transition.

Marianne Calilhanna:

All right. I think we'll end with this one question that is my favorite. Are there languages that are more problematic than others?

Dominique Trouche:

Oh yes. All of them. All of them have a different reason to be problematic. If you go for Latin languages like French, Spanish and Italian, one of the main challenges is text expansion. So you might have graphics that will overlap, some tables that do not format properly, work properly in different languages. When you go to German, you will have the compound words, which are very difficult to hyphenate, very often.

When you go to Arabic or Hebrew, you might know that they are right to left. So it might be challenging for publishing right to left languages in your environment. When you localize into Asian languages, they have different alphabets or sometimes none at all. So the notion of acronyms doesn't exist in Japanese or Korean. Or if you go to Chinese for instance, you won't be able to sort. There's no alphabetic order, because there's no characters. So there are some workarounds.

If you go to Finnish, and that's my favorite – and when I mentioned that it's difficult to build accurate sentences if you have conref or conkeyref – in Finnish, you might have 18 forms of some adjectives, depending on the genders, depending on the cases, depending on the plurals. So the chances that something very simple in English will be correct in Finish, are significantly very low. So every single language is having its own challenge. And it's worth them knowing upfront.

Marianne Calilhanna:

Very interesting. Thank you. And I think that really reinforces why working with organizations who have this experience is really key to your success. Well, I want to thank you gentlemen very much for your time. I want to thank everyone who's taken time out of your busy day to join us at this webinar. This now concludes today's broadcast. You can access many other webinars related to content structure, XML standards, DITA and more, from the webinar archive section, from our website at dataconversionlaboratory.com. We do hope to see you at future webinars and enjoy the rest of your day. Thank you very much, everyone.