Mark Morgan Lloyd schrieb:
Considering your particular example, I'd suggest that the manual should
be written as "If the compiler cannot find", but that compiler messages
which are basically declamatory may lean towards the spoken contraction
"Can't find suchandsuch". This also has the advantage that it keeps the
fixed part of error messages comparatively short, allowing more space
(per acre) for information on paths etc.
This just remembers me of several topics. As a non-native English reader
I prefer the short forms, which are easier to parse. In German one can
form huge words by appending obviously unrelated terms, with the common
example of "Donaudampfschifffahrtsgesellschaftskapitän". I bet that
non-native readers would appreciate a rewrite as e.g.
"Donau'dampf'schiff'fahrt'gesellschaft'kapitän" or
"DonauDampfSchiffFahrtsGesellschaftsKapitän", with the former form for
informal purposes, the latter in source code.
However, the overriding consideration is that many users of development
tools will select English as the working language, even if it is not the
language that they are most comfortable with.
Indeed!
In former times, at least, it was a good idea to install every program
in its *original* language, because the translated terms were often
ugly, misleading or plain of translation errors, what made menus, error
messages and documentation unreadable.
I'd suggest that the
"bottom line" is that if somebody such as yourself finds the more formal
"cannot" more intelligible than the "can't" contraction, then that's the
one to use. Or, of course, vice versa.
I'd not depend on personal taste here. Msegui is my favorite example for
unreadable source code, which makes (not only) my eyes bleed due to lack
of parsing aids in all-lowercase composed identifiers, while its author
has the opposite opinion :-(
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
