On 8/24/07, Mr. Shawn H. Corey <[EMAIL PROTECTED]> wrote:
> Xavier Noria wrote:
> > On Aug 24, 2007, at 8:13 PM, Dr.Ruud wrote:
> >
> >> "Chas Owens" schreef:
> >>
> >>> [$db_initiali.ed]
> >>> Unless you have some funky source filter installed that normalizes
> >>> spelling variants Perl is going to have a problem.
> >>
> >> Yes, I like the idea:
> >>
> >> use autocorect;
> >
> > I think there's an Acme:: module that did something like that, it used
> > some heuristic (edit distance or whatever) and chose an already existing
> > indentifier. Something like that. But I can't find it.
> >
> > -- fxn
>
> Actually, it was I problem I encountered on an international project. The
> British team spelled if initialise and the American, initialize. We could
> fix it by search and replace but since we didn't have control of either
> source, we had to redo the s&r every time we got an update. And neither team
> would do it since they had other, more important items to finish first.
> Sadly, the project was in C :( In Perl, we could have used:
>
> *initialise = \$initialize;
snip
That would only fix global variables (and even then only if it came
after the globals were declared). Lexical variables would still be
broken, not to mention hash keys. If a simple search and replace was
all you needed then a source filter would probably work best (i.e. %80
of the time). For instance, should this be translated?
my $key = "colour";
It depends on how it is used later:
my $colour = $property{$key}; #yes, I think.
my $word = $uk_to_us{$key}; #no
and there is no way (baring strong AI*) a program can make that
decision for you.
* and if we get strong AI, well UK vs US word differences will be the
least of our problems.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
