TMG-L Archives

Archiver > TMG > 2002-09 > 1032231252


From: "Cheri Casper" <>
Subject: RE: [TMG] v4.0d - Sentence construction and quotes
Date: Mon, 16 Sep 2002 19:54:50 -0700
In-Reply-To: <007801c25ded$46877530$d7b9fea9@MYRNICE>


Myrnice -- This is a hard one to answer and I would have to say "yes" and
"no." If, using the [L] variable only, you only have the state, then you
generate an unwanted period after that element as Diana Powell's problem
pointed out. If the [L] variable is applicable to more than just the state,
then "yes" the comma is needed between each and after the state (at least by
U.S. conventions; but you will note that the default US place style has an
erroneous comma after the state and before the country which is different
from placing a comma between the name of a state--preceded by a city and/or
county--and following text--note: *Not* text that refers to *location* but
garden-variety text). TMG only semi-adheres to current U.S. punctuation
usage (haven't used the language feature so can't speak to using alternative
languages). Because in some contexts certain punctuation is needed/wanted
and in other contexts it is not, I personally would prefer to have absolute
control over punctuation output by hardcoding the punctuation into any
output templates, even if that means changing all [L] variables to something
else which is what I do anyway. Idiosyncractic punctuation is one of the
reasons that I have abandoned the [L] variable in sentences altogether in
favor of [LCI] [LC] and [LS], etc. I can get the sentence output the way I
want it, can omit the name of the county in sentences on a default basis if
I choose, among other reasons. If my sentence still for some reason doesn't
come across as I wish (and I am fanatically about using the IN to check
readability), I cut to the chase, wipe the sentence, replace it with [M] and
stick the whole thing in the memo field or key it directly into the
sentence.

I would prefer to fix it once in TMG even if it means having to futz with
every cotton-pickin' sentence in the whole program than to have to
perpetually fix it all in the word processor *every time a report is
generated.* Sure for many things (like the insipid quote-period instead of
period-quote on certain source titles--and, yes, I realize that this is
dependent on which reference book and which country you live in but it is a
perfect case on point why you need more punctuation placement control) a
search and replace will do the trick, but I don't think that fixing in the
word processor is always the answer. After all, had I wanted to do all of
this cleanup and junk in the WP, I would scrap the sentences and just write
the "story" in the WP to begin with. The ability to create sentences was
one of the big selling features for me when I decided to buy TMG; I only
wish I had even tighter control on those sentences. Overall I feel that a
little more work at the input level would, in the long run, eliminate much
work at the output level.

CheriC



-----Original Message-----
From: myrnice [mailto:]
Sent: Monday, September 16, 2002 6:55 PM
To:
Subject: Re: [TMG] v4.0d - Sentence construction and quotes


Cheri

Are you suggesting that the commas between the different place elements of
[L] be omitted also?

Myrnice

"Cheri Casper" wrote on Monday, September 16, 2002 5:03 PM
Subject: RE: [TMG] v4.0d - Sentence construction and quotes


> Peter - Why would all of the existing rules be down the toilet? If, for
> example, TMG assumes a comma after the [L] variable, and the user wanted
it
> left there, why couldn't the sentence just be defined with the user
placing
> the comma there? What is the difference between the program assuming
> punctuation in certain spots and the user placing the punctuation in the
> spot that *s/he* wishes it to be? It would merely mean that all sentences
> that used the default sentence structure would now have the punctuation
> where you wanted it, not where TMG determined it should be. Any custom
> sentences wouldn't be affected. Thus, if the user didn't want the comma
> after the [L] variable, they would simply omit it; users who wanted it
there
> would add one (which is what you get now).
>
> I do not understand the difference between a default that reads: [P] was
> born <[D]> <[L]> <[M]> where TMG will make some decisions about
punctuation
> placement and a sentence where I apply the punctuation of *my* choice:
[P]
> was born <[D]> <[L],>< [M] enabling me to decide *if* I want a comma after
> the [L] or not? Won't the resultant output be identical? However, by
> omitting the comma, I won't get it if I don't want it. Now I have no
> choice.
>
> While I haven't thought through all of the ramifications, it doesn't seem
to
> me that this would screw up anything. Default sentences would have no
> punctuation in them unless & until you placed it there; custom sentences
> wouldn't be affected. The only problem would be that if people didn't
> realize they needed to add their own personal punctuation to the defaults
or
> incorrectly used the punctuation. All this would do is shift the burden
of
> making punctuation decisions away from the program and leave it up to the
> user. So if I forgot to put a comma in some place in a default sentence,
it
> wouldn't take me too long to realize that, go back and add it, and voila
it
> would be appropriate for every default sentence.
>
> I think you are suggesting two modes: w/punctuation and w/o. I am
> suggesting w/o only; punctuation applied by the user to defaults as
desired
> or not--much as people modify default sentences anyway or default source
> templates.
>
> CheriC
>
>
> -----Original Message-----
> From: Peter B.Hill [mailto:]
> Sent: Monday, September 16, 2002 1:10 PM
> To:
> Subject: RE: [TMG] v4.0d - Sentence construction and quotes
>
>
> At 09:16 AM 9/16/2002 -0700, Cheri Casper wrote:
>
> >Juergen - I suggested sometime ago that TMG forego any built in
punctuation
> >and associated assumptions and let the user place all punctuation
directly
> >into the sentence structures as s/he wishes. That went down with a loud
> >thud. I think that a lot of folks were fearful that making such a change
> >would cause all existing sentences using the current defaults to be
> >erroneous. However, if you are adding to the defaults and assuming you
> >place the punctuation correctly, this shouldn't be a problem. Any
sentence
> >that has been modified at the tag level would stay just as is (like it
> >currently does when you make modifications at the tag definition level
for
> >sentences).
>
>
> Cheri:-
>
> I liked this idea when I first saw it, and still like it. But I
> think that getting there from here would probably be nightmareish, because
> of all the memos and sentences that have already been created under the
old
> rules. I suppose it would be possible, in converting to a
> no-punctuation-added mode, for the converting program to go through and
add
> punctuation to all existing sentences first, before going into the
> user-punctuation mode. From then on, the program would have no further
> responsibility for punctuating sentences.
>
> Another alternative is to permit persons using another language
to
> define to TMG the punctuation rules, capitalization rules, etc., adhered
to
> in that language. For example, Robin Lamacraft could define the language
> STRINE, in which full-stops are not automatically tucked within quotation
> marks, as is the rule in Mercan. But I have a feeling that the
> implementation of multiple punctuation strategies would be horrendous.
>
> Far better, I think, to find a way to implement a
> no-automatic-punctuation scheme that somehow provides a soft landing for
> all the memos and sentences generated to date.
>
> Pete Hill
>
>
> ==== TMG Mailing List ====
> Send all messages and replies to <>.
>
>
> ==== TMG Mailing List ====
> Visit the TMG Tips web site <http://www.tmgtips.com>; for items of interest
to TMG users.
>
>


==== TMG Mailing List ====
To un-subscribe from TMG-D (digest mode), send a message to
<> with just the word "unsubscribe" (no quotes)in
the text and turn off your signature.

This thread: