I don't have an opinion on this general topic one way or another (I prefer using British English spelling, but I was raised on American English)
However regarding class names... Class names are class names. If Adobe for the past 10-15 years had a class named BakgroundColorz, BakgroundImagez and BakspaceControllerz, I would not advocate changing the class name just so its is spelled correctly after so many years of it being another way. I don't see the point in that. Class names are class names, they are not words which require correct spelling. Though they do require consistent spelling and usage. brought to you by the letters A, V, and I and the number 47 On Sun, Nov 23, 2014 at 7:53 AM, Alex Harui <aha...@adobe.com> wrote: > > > On 11/21/14, 11:53 PM, "Justin Mclean" <jus...@classsoftware.com> wrote: > > >Hi, > > > >> IMO, we should not be trying to decide between US and Int’l English. > > > >And nor should we be using US English for an international audience given > >who are the majority of our users. > > If you agree that we should use backgroundColor, color, and ColorPicker, > doesn’t that count as US English? > > IMO, we should not be changing US English words to Int’l English words. > Let’s just find words that work for both, and if we can’t, maybe use both > terms. But I think “color” should stay as “color”. > > So far nobody has stepped up to support your idea of changing US English > words to Intl English so until that happens I’m not sure it is worth > continuing the debate. I’d say that the community’s energy is better > spent on localizing. > > > > >> For example, I don’t know if our documentation actually contains the > >> phrase “your email address is missing a period”, > > > >It's doesn't but our resource files did, and that was handled by the > >locales, I don't think we need to go than the path of making different > >versions of the release notes / readme however. The differences are > >reasonable minor. > > Hold on a second. Are we debating a theoretical? Can you supply 3 > examples of words that you want changed? > > > > >> Before we go off spending energy rewriting the doc, I would like to see > >> evidence that folks are finding it confusing and that some change is > >>going > >> to make a difference. I don’t recall very many JIRA issues about > >> confusing documentation or threads on the mailing list. > > > >Over the years I've had numerous people complained to me about this, but > >them I'm based outside the US and the issue is a lot more visible there. > > Get them to complain on the list or in JIRA so we can try to find words > that are “neutral”. > > > > >> And thus, I would not be in favor of our default documentation saying > >>things like “Use > >> the ColorPicker to select a colour”. > > > >I don't see any problem with that, it's actually correct. > > It’s not correct in the US. Again, let’s find a way to localize our > documentation so we don’t have to choose one over the other. In the > bigger picture we want to localize to non-English languages as well. > > > > >> We’ve localized the Installer > > > >Well some of it. The ant for air component isn't localise, so you get a > >mix of local language and US english in the install log. > > Actually, it looks to me that ant_on_air does support locales. You > checked in the en_AU file into Git. I hadn’t realized it until now, but > the Installer isn’t linking in those files. > > > > >> Do we know if any other Apache projects localize all of their content? > > > >A lot do - Open Office be probably the best example, but it's audience is > >different to ours. > > Are you willing to do the homework on how these other projects do their > localization and whether we can leverage that somehow? > > -Alex > >
