H.Merijn Brand wrote: > On Mon, 07 Jun 2010 13:51:26 -0400, John Scoles <sco...@pythian.com> > wrote:
Others have answered individual items you highlighted, I only have one point below: >> 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. > > Huh? "it"? So you want to move everything to en_US? > I'm really trying to be serious here (and learn). > Consistency is VERY high in my goals, so IMHO we > should stick to en_EN for DBI. My belief was that the DBI docs were more en_EN than en_US. Given Tim probably wrote most of it that is no surprise. I think the documentation should be consistent and probably should be en_EN. >>> 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)): > > Summary: > > ☑ unicode => Unicode > ☐ DBDs <= DBD's > ☐ DSNs <= DSN's > ☑ unlikey => unlikely > ☑ abreviated => abbreviated > ☐ NULLs <= NULL's > >>> @@ -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. > > My spell checker is a perl script using Text::Aspell and doesn't know > any context at all. > >> 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 >> >>> : >> We could play this game for a long time as we here in Canada have some >> of our own funny ways to spell things?? > > Thanks for the insightful remarks. > > Things I also noted: > > # 'DEFERABILITY' => (DEFER ABILITY DEFER-ABILITY DESIRABILITY DURABILITY > DIVISIBILITY) > # 'deferrability' => (desirability durability divisibility) > # 'DEFERRABILITY' => (DESIRABILITY DURABILITY DIVISIBILITY) > I'm blank on this: one or two 'r's? > My "Collins Cobuild" English Language Dictionary doesn't know the word, > but spells alle deferr... with two 'r's > > # 'implementors' => (implementers implements implementer's implement's > impalement's implementer) > > # 'thru' => (Thur thrum Thu thou) > isn't it "through" in English? > > # 'piggback' => (piggyback piggybacks piggyback's piggybacked) > piggyback? > > # 'scaleable' => (scale able scale-able scalable saleable salable > callable) > > I fixed "a subtile difference" to "a subtle difference". Unless sub-tile > has some weird meaning, that looked soooo weird. > > I have no idea how to change "ommiting" in: > 'You can put every SQL-statement you like in simply ommiting > "sql => ...", but the more important thing is to restrict the > connection so that only allowed queries are possible.' > > This line has two errors: > =item * "accept" tells the dbiproxy-server wether ip-adresse like in "mask" > are allowed to connect or not (0/1) > > WTF does 'Pern' mean in: > > But you'll note that there is only one call to > DBD::_::db::selectrow_arrayref but another 99 to > DBD::mysql::db::selectrow_arrayref. Currently the first > call Pern't record the true location. That may change. > > lib/DBD/Multiplex has different/wrong line endings :( > > I have committed fixes to all the obvious errors. > Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
