Re: Spelling

H.Merijn Brand wrote:
> For my own projects (which includes two DBD's), I have been working on
> spell-check issues. I'm not born in an English-speaking country, nor
> was I raised in one, so I make errors. Probably quite a few.
>
> spell-checkers help a lot, but most work on en_US, not en_EN, and I try
> to at least be consistent inside a project.
>
> When I was done with my own projects, I threw my newly built utility at
> the perl source tree itself, and found a few mistakes as well. Then I
> implemented Text::Aspell into it and fixed all that it found that was
> obviously wrong. It supports reading local aspell lists of words that
> are considered to be correct for the given project.
>
> DBI documentation is written in en_EN instead of en_US, so the
> spell-checker will see "behaviour" as wrong and suggests "behavior".
> Same for "ACKNOWLEDGEMENT" vs "ACKNOWLEDGMENT".
>
>   
So it spells it correctly good thing.
> That was my trigger to implement project specific language support.
> Done.
>
> Before I try to get deeper into DBI docs and its spelling, would it be
> considered good-work?
>
> As an example to start (this part DOES contain real errors, like
> abreviate (one b) and unlikey (instead of unlikely)):
> --8<---
> diff --git a/DBI.pm b/DBI.pm
> index ad14fed..0cf59e9 100644
> --- a/DBI.pm
> +++ b/DBI.pm
> @@ -1101,7 +1101,7 @@ sub data_diff {
>
>  sub data_string_diff {
>      # Compares 'logical' characters, not bytes, so a latin1 string and an
> -    # an equivalent unicode string will compare as equal even though their
> +    # an equivalent Unicode string will compare as equal even though their
>      # byte encodings are different.
>      my ($a, $b) = @_;
>      unless (defined $a and defined $b) {             # one undef
> @@ -2267,7 +2267,7 @@ Perl supports binary data in Perl strings, and the DBI will pass binary
>  data to and from the driver without change. It is up to the driver
>  implementors to decide how they wish to handle such binary data.
>
> -Perl supports two kinds of strings: unicode (utf8 internally) and non-unicode
> +Perl supports two kinds of strings: Unicode (utf8 internally) and non-Unicode
>  (defaults to iso-8859-1 if forced to assume an encoding).  Drivers should
>  accept both kinds of strings and, if required, convert them to the character
>  set of the database being used. Similarly, when fetching from the database
> @@ -2303,7 +2303,7 @@ use by the DBI. Extensions and related modules use the C<DBIx::>
>  namespace (see L<http://www.perl.com/CPAN/modules/by-module/DBIx/>).
>  Package names beginning with C<DBD::> are reserved for use
>  by DBI database drivers.  All environment variables used by the DBI
> -or by individual DBDs begin with "C<DBI_>" or "C<DBD_>".
> +or by individual DBD's begin with "C<DBI_>" or "C<DBD_>".
>
>   
the first one is correct. As you are referring to many DBDs not  
something that belongs to a DBD

Seems like your spell checker cannot tell or (does not know) the correct 
use of "s" in its plural, possessive, and plural possessive.

Most likely just taking a guess based on wheather of not the first 
letter is capitalized. 

Welcome to the wonderful world of English.

have a go at this

http://www.meredith.edu/grammar/plural.htm

I guess if you really want to use the possessive you could try

All environment variables used by the DBI begin with 
"C<DBI_>" while the DBDs' environment variables begin with "C<DBD_>".

but that would be twisting it a bit.



>  The letter case used for attribute names is significant and plays an
>  important part in the portability of DBI scripts.  The case of the
> @@ -2416,7 +2416,7 @@ Binding an C<undef> (NULL) to the placeholder will I<not> select rows
>  which have a NULL C<age>!  At least for database engines that
>  conform to the SQL standard.  Refer to the SQL manual for your database
>  engine or any SQL book for the reasons for this.  To explicitly select
> -NULLs you have to say "C<WHERE age IS NULL>".
> +NULL's you have to say "C<WHERE age IS NULL>".
>
>   
again "NULL's" is incorrect as were are using NULL in its plural form, 
and not in the singular possessive.
>  A common issue is to have a code fragment handle a value that could be
>  either C<defined> or C<undef> (non-NULL or NULL) at runtime.
> @@ -2651,7 +2651,7 @@ It is recommended that drivers support the ODBC style, shown in the
>  last example above. It is also recommended that that they support the
>  three common names 'C<host>', 'C<port>', and 'C<database>' (plus 'C<db>'
>  as an alias for C<database>). This simplifies automatic construction
> -of basic DSNs: C<"dbi:$driver:database=$db;host=$host;port=$port">.
> +of basic DSN's: C<"dbi:$driver:database=$db;host=$host;port=$port">.
>   
again DSN is used in the plural not the possessive
>  Drivers should aim to 'do something reasonable' when given a DSN
>  in this form, but if any part is meaningless for that driver (such
>  as 'port' for Informix) it should generate an error if that part
> @@ -4933,7 +4933,7 @@ B<NUM_PREC_RADIX>: The radix for numeric precision.
>  The value is 10 or 2 for numeric data types and NULL (C<undef>) if not
>  applicable.
>
> -B<NULLABLE>: Indicates if a column can accept NULLs.
> +B<NULLABLE>: Indicates if a column can accept NULL's.
>  The following values are defined:
>
>    SQL_NO_NULLS          0
> @@ -4969,7 +4969,7 @@ data type column.
>
>  B<ORDINAL_POSITION>: The column sequence number (starting with 1).
>
> -B<IS_NULLABLE>: Indicates if the column can accept NULLs.
> +B<IS_NULLABLE>: Indicates if the column can accept NULL's.
>  Possible values are: 'NO', 'YES' and ''.
>
>  SQL/CLI defines the following additional columns:
> @@ -5548,7 +5548,7 @@ would return C<'Don''t'> (including the outer quotation marks). For others it
>  may return something like C<'Don\'t'>
>
>  An undefined C<$value> value will be returned as the string C<NULL> (without
> -single quotation marks) to match how NULLs are represented in SQL.
> +single quotation marks) to match how NULL's are represented in SQL.
>
>  If C<$data_type> is supplied, it is used to try to determine the required
>  quoting behaviour by using the information returned by L</type_info>.
> @@ -6818,7 +6818,7 @@ and values).
>
>  It is possible that the values in the hash returned by C<ParamTypes>
>  are not exactly the same as those passed to bind_param() or execute().
> -Param attributes specified using the abreviated form, like this:
> +Param attributes specified using the abbreviated form, like this:
>   
Well at least you caught one
>      $sth->bind_param(1, SQL_INTEGER);
>
> @@ -7081,10 +7081,10 @@ Here's a complete example program to insert some data from a file.
>    $dbh->commit;
>    $dbh->disconnect;
>
> -Here's how to convert fetched NULLs (undefined values) into empty strings:
> +Here's how to convert fetched NULL's (undefined values) into empty strings:
>
>    while($row = $sth->fetchrow_arrayref) {
> -    # this is a fast and simple way to deal with nulls:
> +    # this is a fast and simple way to deal with NULL's:
>      foreach (@$row) { $_ = '' unless defined }
>      print "@$row\n";
>    }
> @@ -7210,7 +7210,7 @@ to be delivered $seconds in the future. For example:
>    if ( $@ eq "TIMEOUT\n" ) { ... }
>    elsif ($@) { ... } # some other error
>
> -The first (outer) eval is used to avoid the unlikey but possible
> +The first (outer) eval is used to avoid the unlikely but possible
>   
yeah one more
>  chance that the "code to execute" dies and the alarm fires before it
>  is cancelled. Without the outer eval, if this happened your program
>  will die if you have no ALRM handler or a non-local alarm handler
> @@ -7463,7 +7463,7 @@ Currently the DBI only defines two trace flags:
>
>    ALL - turn on all DBI and driver flags (not recommended)
>    SQL - trace SQL statements executed
> -        (not yet implemented in DBI but implemented in some DBDs)
> +        (not yet implemented in DBI but implemented in some DBD's)
>
>  The L</parse_trace_flags> and L</parse_trace_flag> methods are used
>  to convert trace flag names into the corresponding integer bit flags.
> -->8---
>
>   
We could play this game for a long time as we here in Canada have some 
of our own funny ways to spell things??

cheers
John