TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
On Thu, 19 Jul 2012 13:17:00 -0400, Margaret Cekis <margaret -dot- cekis -at- comcast -dot- net> wrote:
>
> Peter Neilson asked, "To whose benefit is it, to have all the
> languages sqwooshed in together?"
> _________________________________
> Peter:
> Probably the manufacturer benefits becaues the overhead for
> stocking and
> shipping only one item (that multiple-language monstrosity) is at
> least
> nominally less than stocking, selecting, and shipping separate
> language
> manuals for different country destinations. Such differentiation
> would
> probably also require multiple bills of materials and differentiation
> of
> the outer packaging to indicate the country/language a specific unit
> was
> destined for. So they go the cheapest all-in-one route, regardless of
> whether it matters to the buyers and users or not.
> Margaret Cekis, Johns Creek GA
I can't remember the last time I saw a multi-language guide/manual
that included right-to-left languages.
The implication there - if not simply that I'm unobservant... or
that the first thing to go is the memory, and not the knees... or
not that other thing... - is either that the vendor didn't sell into
affected countries, or that they did indeed keep a separate
document on the Bills of Materials for right-to-left.
I guess it's not an issue with Chinese and other languages
that read along columns rather than across rows? Because I
do encounter lots of guides/manuals with oriental languages
among the occidental left-to-right languages.
Generally, they are all little self-contained books, with ToC and
compliance pages and other front-matter for each one. But
all bound as one book.
If it's a book, with each language in its stand-alone section, and
if I think I'll need it more than the first five minutes, I'll probably
shove in a bookmark for each end of my (English) section.
Or I'll use a skinny rubber band.
If the binding is glued and the separation of sections works,
I might just rip out the section for my language and toss the
rest... unless I think I might ever sell/give-away the product...
in which case I preserve the documentation and packaging.
I'm not usually bothered by the multi-language-ness of it
all, because my section has a readily identifiable beginning
and end.
Where I get a little cranky are the mixed graphic-and-text
instruction/quick-start folders, where each step is an illustration
followed by five or six repetitions of explanatory text, with the
paragraphs marked by symbols for the respective languages.
It can be visually confusing when both pictures and text
have been shrunk for space, especially if you hit a wordy
step that spills over to a new column. As well, usually a
vendor that's going to go that cheap on documentation
is also going to use cheap paper, so legibility suffers further.
But, back to books-of-many language sections...
I don't see that there should be a problem including
Arabic, Hebrew, etc. in a book with left-to-right
languages if each language is its own, self-contained
section.... and, if you can print with section-marker
edge-bleeds, even better. You don't need to keep
continuous page numbering. Number pages within
each section, and then just post an ordered (but not
numbered) list of language names at the start of
the book. One list in the order a left-to-right reader
would encounter the sections, and the other list,
at the other end (that we'd call the back) that lists
the names in the order that a right-to-left reader
will encounter them.
All a user wants to know is roughly where his material
lives among all those other pages. If his language is the
third of nine (in the list he's looking at), then he turns the
document slightly edge-on and counts clusters of pages
with edge-bleed blocks identifying the extent and location
of each section, and splits at what should be the correct
one - between the second section and the third in this case.
He'll be within a page or two of where he needs to be.
The only flaw that I see is that Arabic and Hebrew
readers would need to become accustomed to "reading"
and counting the edge-bleed blocks from bottom-to-top,
while the rest of us would see them starting at the top
and going down the edges of pages toward the end/bottom
of the book.
Even if your printing budget won't include edge-bleed,
it doesn't diminish the usefulness very much. A user
just bends the book slightly, and thumbs the pages
or lets them flip to rapidly find his spot.
(Assume "she" and "her" in place of "he" and "his", above, as applicable.)
Keep the rtl languages in alphabetical order, but place
the ltr languages at the back of the book, so they'll be
the first two or three that rtl readers encounter when
thumbing from *their* front.
What the rtl reader loses in having to count up from
the bottom, rather than down from the top, s/he
gains in having to poke through just two or three
sections at most.
Ok, everyone, resume napping.
-k
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create and publish documentation through multiple channels with Doc-To-Help. Choose your authoring formats and get any output you may need.
Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.
