The difficulty comes in what you define the project as. If it's Lang, then we generally don't care. If it's Jakarta, then I suspect there's a strong enough pro-US vote.
As none of the non-US-english writing people so far have really cared, I'll go ahead and commit a change. Deprecating the old spelling and introducing the new spelling. Hen On Thu, 14 Aug 2003, Brett Porter wrote: > There has just been a debate on the Linux Kernel mailing list about this - > actually a lot of that code is in British English. > > I say it should be whatever the majority of developers are comfortable with > and it must be consistent across the project. Everyone else can press > Ctrl-space in their IDE :) US English sounds fine in general - the rest of > the world is usually aware of how the spellings differ (although the reverse > is not always the case :) > > Cheers, > Brett > > > -----Original Message----- > > From: Simon Kitching [mailto:[EMAIL PROTECTED] > > Sent: Thursday, 14 August 2003 9:30 AM > > To: Jakarta Commons Developers List > > Subject: Re: [lang] StringUtils misspelled method names? > > > > > > As a user of, rather than contributor to, lang, I agree with Stephen. > > > > While also a "Queen's English" user, the convention for > > programming libraries is clearly established as US English. > > All the java standard libraries use this convention, so it > > seems inconsistent to use other spelling elsewhere. I bet C++ > > libraries, Gnome libraries, etc. also use US English > > spellings for public methods. > > > > Regards, > > > > Simon > > > > On Thu, 2003-08-14 at 11:23, Stephen Colebourne wrote: > > > Although I am English and use the correct English spelling, I would > > > probably prefer these to be spelt as US english. > > > > > > Why? Well practically all computer driven spelling is US, eg. > > > capitalize (US English) not capitalise (correct English) color (US > > > English) not colour (correct English) > > > > > > If we are to change them, then this is the time. The [lang] 2.0 > > > release is the tidy up release involving deprecations. I > > don't expect > > > or want further deprecations in 3.0. > > > > > > Having said that, I can't work up the will to actually make the > > > change. So > > > +1 if someone wants to make the effort and supply a patch. > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
