From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,a82f86f344c98f79
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news2.google.com!news.germany.com!news.belwue.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Newsgroups: comp.lang.ada
Subject: Re: Avatox 1.0: Trouble with encoding in Windows
From: Georg Bauhaus <bauhaus@futureapps.de>
In-Reply-To: <JGGOg.51789$aJ.33083@attbi_s21>
References: <45051d37@news.upm.es>
	 <45053aec$0$5142$9b4e6d93@newsspool1.arcor-online.net>
	 <5ZednRK-0M3K15rYnZ2dnUVZ_o2dnZ2d@megapath.net>
	 <1158145462.921837.152720@i42g2000cwa.googlegroups.com>
	 <1158224191.059815.103080@i42g2000cwa.googlegroups.com>
	 <lEjOg.187763$1i1.48666@attbi_s72>
	 <450a74ae$0$17404$9b4e6d93@newsspool2.arcor-online.net>
	 <JGGOg.51789$aJ.33083@attbi_s21>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: #
Message-ID: <1158400338.12070.56.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.1 
Date: Sat, 16 Sep 2006 11:52:19 +0200
NNTP-Posting-Date: 16 Sep 2006 11:50:49 CEST
NNTP-Posting-Host: c0e57a4f.newsspool1.arcor-online.net
X-Trace: 
 DXC=^El`3>9[[IK[kmHKHnaEnMic==]BZ:afN4Fo<]lROoRAgUcjd<3m<;BcW958<ha<mAPCY\c7>ejVHG8K:Li[=VkOIGIBK>hfYdK
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:6611
Date: 2006-09-16T11:50:49+02:00
List-Id: <comp.lang.ada>

On Fri, 2006-09-15 at 23:28 +0000, Jeffrey R. Carter wrote:

> > So using your native language or problem domain language might add
> > value to the local mode of expression.
> 
> Sure. So would using a programming language with reserved words in that 
> language.

I have seen this in teaching, and in the translations of the Logo
and Basic languages. In normal programming contexts I think it just
adds confusion, because there is no clear choice of the proper
translation. Libraries are frequently written using the "English
edition" of the grammar, so you'd have to switch recognition patterns
anyway.
For example, when we have to write Perl code we don't even use Perl's
translations from English to English so to speak, like writing "unless
(expr)" instead of "if (! expr)" (when positive logic would tear things
apart). We just stick with the language neutral if/then/elsif etc..
Keeps it simple.

When our program text is mixing formal words from the language grammar
and from the problem domain, the result will be formal anyway.
E.g. I have an idea what Martin's identifier "Abschluss_Datum"
might mean. Translating such words can add misunderstandings even
when they are correct in US English, because of different British
traditions. Or worse:
When you fill in a deposit slip (pay-in slip, paying-in slip),
then I guess you wouldn't be surprised to see a field
labeled "DATE".
The German label of this field is probably "Wert". The uninitiated
might translate this as "worth", "value", "asset", etc., but
not as "date". And even "date" might refer to different things,
implying unintended consequences of the translation.
Choosing an unambiguous word from the "profession languages" spoken
by local trades people will reduce a number of risks I think,
including cost. So my preferred rule will be:
Use Ada's formal English words, because you have learned what
they mean, and use words from the problem domain even if they
aren't English words, again because you know what they mean,
as do users and developers of the software. If there
is time and money for a proper translation, delegate.


> Actually, that would be a past tense and 
> past participle. The past participle, of course, is used in
> forming the passive voice.

Thanks for the corrections.


-- Georg