Merge branch 'jc/doc-manpages-l10n'

The SubmittingPatches document now refers folks to manpages
translation project.

* jc/doc-manpages-l10n:
  SubmittingPatches: advertise git-manpages-l10n project a bit

diff --cc Documentation/SubmittingPatches
index 20f4311e54d094f0f4ffeae8c6d4816032bcfce2,ff31049dceac8116f5a62835d2251491f39646ca..7cc8b15f85e19e5b613f148a7ca798acc3a04c6b
--- 1/Documentation/SubmittingPatches
--- 2/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@@ -630,6 -548,62 +630,13 @@@ repositories
  
  Patches to these parts should be based on their trees.
  
 -[[patch-flow]]
 -== An ideal patch flow
 -
 -Here is an ideal patch flow for this project the current maintainer
 -suggests to the contributors:
 -
 -. You come up with an itch.  You code it up.
 -
 -. Send it to the list and cc people who may need to know about
 -  the change.
 -+
 -The people who may need to know are the ones whose code you
 -are butchering.  These people happen to be the ones who are
 -most likely to be knowledgeable enough to help you, but
 -they have no obligation to help you (i.e. you ask for help,
 -don't demand).  +git log -p {litdd} _$area_you_are_modifying_+ would
 -help you find out who they are.
 -
 -. You get comments and suggestions for improvements.  You may
 -  even get them in an "on top of your change" patch form.
 -
 -. Polish, refine, and re-send to the list and the people who
 -  spend their time to improve your patch.  Go back to step (2).
 -
 -. The list forms consensus that the last round of your patch is
 -  good.  Send it to the maintainer and cc the list.
 -
 -. A topic branch is created with the patch and is merged to `next`,
 -  and cooked further and eventually graduates to `master`.
 -
 -In any time between the (2)-(3) cycle, the maintainer may pick it up
 -from the list and queue it to `seen`, in order to make it easier for
 -people to play with it without having to pick up and apply the patch to
 -their trees themselves.
 -
 -[[patch-status]]
 -== Know the status of your patch after submission
 -
 -* You can use Git itself to find out when your patch is merged in
 -  master. `git pull --rebase` will automatically skip already-applied
 -  patches, and will let you know. This works only if you rebase on top
 -  of the branch in which your patch has been merged (i.e. it will not
 -  tell you if your patch is merged in `seen` if you rebase on top of
 -  master).
 -
 -* Read the Git mailing list, the maintainer regularly posts messages
 -  entitled "What's cooking in git.git" giving
 -  the status of various proposed changes.
 -
+ - The "Git documentation translations" project, led by Jean-Noël
+   Avila, translates our documentation pages.  Their work products are
+   maintained separately from this project, not as part of our tree:
+ 
+       https://github.com/jnavila/git-manpages-l10n/
+ 
+ 
  == GitHub CI[[GHCI]]
  
  With an account at GitHub, you can use GitHub CI to test your changes