This will hopefully avoid questions over which spelling and grammar should be used. Translators are of course free to create localizations for other specific English dialects. Signed-off-by: Marc Branchaud <marcnarc@xxxxxxxxxxx> --- A little less stringent now. Documentation/CodingGuidelines | 6 ++++++ Documentation/SubmittingPatches | 10 ++++++++++ 2 files changed, 16 insertions(+) diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 559d5f9..fc397f3 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -242,6 +242,12 @@ Writing Documentation: processed into HTML and manpages (e.g. git.html and git.1 in the same directory). + The documentation generally follows US English (en_US) norms for spelling + and grammar, although most spelling variations are tolerated. Just avoid + mixing styles when updating existing text. If you wish to correct the + English of some of the existing documentation, please see the documentation- + related advice in the Documentation/SubmittingPatches file. + Every user-visible change should be reflected in the documentation. The same general rule as for code applies -- imitate the existing conventions. A few commented examples follow to provide reference diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index d0a4733..998e407 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -65,6 +65,16 @@ feature does not trigger when it shouldn't. Also make sure that the test suite passes after your commit. Do not forget to update the documentation to describe the updated behaviour. +Speaking of the documentation, if you are attempting to correct typographical +or grammatical errors use one patch for indisputably correct changes (e.g. +"teh" -> "the") and put subjective/stylistic changes in a separate patch. +This helps to streamline reviews of your patches. Also, although the +documentation is mainly written in US English, most non-US spelling variants +are acceptable. Patches that change one common spelling to another (such as +changing "behaviour" to "behavior") are generally not helpful, as +oftentimes a few months later some generous soul will want to change the +spelling the other way. + Oh, another thing. I am picky about whitespaces. Make sure your changes do not trigger errors with the sample pre-commit hook shipped in templates/hooks--pre-commit. To help ensure this does not happen, -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html