: How should we plan for translations' space needs when designing diagrams that require text? Our documentation set includes some diagrams where text is integral and can't be handled in callouts,
Our documentation set includes some diagrams where text is integral and can't be handled in callouts, like flowcharts and entity relationship diagrams. Our documentation is translated, so these diagrams need to be translated too. But diagram design is informed by the amount of text we need to include -- this box needs to be big enough for that word, this branch in the flowchart needs to be able to hold that four-word question, and so on.
But not all languages are equally verbose. If our diagrams were translated to German, probably many bits of text would overflow their bounding shapes or otherwise not fit well. If the translation were to Hebrew, much of the text would be swimming in vast seas of excess space. And I have no idea what would happen in Japanese (which is actually one of our current target languages, unlike my other examples).
When I'm laying out a fairly complex diagram that uses text, how should I account for the space needs of translation? Are there well-known ratios I should use in planning, for example that language X averages needing 1.5 times the horizontal space of English (so I should just add in some extra space)? Are there things I can do technically (in Visio) to support auto-scaling, so that if all the boxes need to be wider that can be done globally and not by editing each box? Or do technical translators routinely redraw diagrams and I shouldn't worry about it? (I don't have a way to ask ours what they do, so I'm asking what's commonly done.)
In this related question I asked about the mechanics of translating text in diagrams. In this question I'm asking about content, not mechanics.
0 Reactions React
2 Comments
Sorted by latest first Latest Oldest Best
@Cugini967
Due to the lack of consistency in languages across the globe, and the number of random outliers [well, weird overly long compound words in German mainly...], I've yet to come across any good 'hard and fast' rules to go by.
The three main options, ranked best to worst, that I've employed in the past:
Define your draft diagrams in a way that is flexible enough that you can effectively hand off final layout to the localization team, and collaboratively work with them to adjust and modify as needed for finished localization.
Giving them the authority to request minor changes for clarity and layout as needed can result in a far more usable end product, if slightly increased cost.
Rough Draft the diagrams, sort out everything you expect to want for labels, and pass that text off for localization before beginning final diagram edits. Good localization teams will be able to phrase things to at least ball-park text lengths towards a box size if needed, or at least will clearly flag them as an issue to be addressed. [This is basically option one, without being able to pawn as much work off on the other team]
Guess [or get estimates from your localization team], and upsize your text fields enough that the longest language 'should' fit while still being a reasonable sized font, and then up the font size on languages that feel a little too small when placed in the box.
Allow Localization team to raise issues as needed
The impact of issues like insanely long compound words in German can at times be offset by the creativity of your localization team.
Also consider the option of replacing what ends up as overly complicated text in a diagram with an icon...
Depending on diagram design, you might actually get away with using only icons on the diagrams, and localizing a key instead, which could make sizing issues far less of a problem without giving up clarity or consistency.
0 Reactions React
@Karen856
I would design the charts with generous space allowed for the original language. I would also allow for a section at the bottom of the diagram for notes. This section could be empty for the native language but could hold additional information for less space-efficient translations.
If I had more control over the diagram language (such as a more parametric version of Visio), I could tie font size to the amount of text, and change the relative sizes of the content. This is hard, though, and the possibility of bugs is huge in the general case.
Translation must serve several masters. The top-level meaning must be preserved. The connections that exist between ideas must be maintained, which can force word choices. [A professional translator would find legitimate fault with these two choices, and add many important other constraints on translation.]
Preserving the structure and readability of the diagrams is naught but one more constraint. A "notes" escape hatch to convey more when needed can work.
0 Reactions React
Terms of Use Powered by ePowerPress Stock Market News!
© selfpublishingguru.com2024 All Rights reserved.