Just to use Alex’s division of items in an attempt to make things clear: 1) Release package documents: README, RELEASE_NOTES, LICENSE, NOTICE, CONTRIBUTING, etc. 2) API names (classes, properties, styles, etc) 3) ASDoc and JavaDoc comments (really, any comments that end up in user documentation) 4) Written user documentation 5) Website 6) Wiki 7) Error messages in the tools 8) Text in the SDKs and Applications we release that show up in some GUI
The way I understand your suggestion is like this: We agree on variant “X”. 1) Anything goes as long as it’s understandable as English, but there should be an attempt at keeping the wording consistent within a file. 2) Not sure. 3) Variant “X”. 4) Variant “X” with an option to localize for anyone who cares. 5) Ditto 6) Not sure. 7) Not sure. 8) Not an issue because it’s already localized. Harbs On Nov 26, 2014, at 11:17 AM, Bertrand Delacretaz <bdelacre...@apache.org> wrote: > Hi, > > I read that thread at http://markmail.org/message/qbipsoo3k4umbh4a > > IMO that's a typical example where it's impossible to come up with a > "right" solution...people have various levels of concern for that > issue, ranging from exactly zero to "my customers say our stuff is > crap when they see that" which is very bad. So the longer you discuss > those things in email the worse it gets, in general, without anybody > being wrong...just different valid opinions that cannot be reconciled. > > My recommendation would be to find a technical solution to what is a > rightful community issue - reduce the area on which you need to agree, > make things more modular so that people who care about this can work > on it while others can completely ignore it. > > I have no idea how or where Flex handles these language translations > (*), but if it's possible to handle the language differences with > localization files, I suppose whoever cares about those things can > maintain their custom localization files, and the PMC can have a > majority vote on what language variant to use on the default > localization files. > > I wouldn't care a bit about the exact spelling in README and other > similar "technical" files - IMO whoever does the work of writing them > is right, and I'd try to follow the existing style when modifying one > of them, but that's just best effort in my book. Spelling mistakes in > READMEs? That's a good way for emerging contributors to have something > to fix ;-) > > Hope this helps, and happy to clarify where needed. > > -Bertrand > > (*) I'm still 99.7% clueless on Flex at the technical level...just > trying to help on community issues.
