Add README.md for translation process

[yuhattor]

@spier
I have created a draft regarding the Translation Process. I may be missing some parts.

I'm a little confused, with the methodology you mentioned in #422, for example, when a Japanese community member sends a PR for a translation, should they send it to the book-jp branch? Or should they send PRs directly to main? From your description, it sounds like book-jp is just a place to put the artifacts.
It would be good to indicate here clearly which branch to send PRs to when others join the translation in the future.

When the process is somewhat finalized, I will create the Japanese version in translation/japanese/README.md as well.

[spier]

Thanks for putting this together! Looks great already.

I left some inline comments for you to consider.

Please make your own judgement calls about my inline comments, and then just merge whatever version of this doc you are comfortable with.

That also allows us to confirm that you indeed have WRITE permissions on the repo now :)

One cosmetic suggestion:
If you don't mind, could you use the code syntax with a single backtick, rather than 3 backticks? That's how we have done it elsewhere in this repo so far, so it would make it more consistent. (I am adding one inline suggestion about this to the doc but the comment applies to all code blocks).

Update:
Don't worry about the failing checks.
I have taken care of them already.

[spier]

I'm a little confused, with the methodology you mentioned in #422, for example, when a Japanese community member sends a PR for a translation, should they send it to the book-jp branch? Or should they send PRs directly to main? From your description, it sounds like book-jp is just a place to put the artifacts.
It would be good to indicate here clearly which branch to send PRs to when others join the translation in the future.

I can see how it can be confusing.

It will work like this from a contributor perspective:

• scenario A: contributor wants to make a larger contribution (like translating a new pattern or similar)

  • creates a PR with the changes against main
  • a trusted committer (TC) reviews the PR and eventually merges it (or rejects it, of course)
  • the PR is approved and merged
  • then the TC has to make sure that the changes on main are also added to book-jp so that they are visible in gitbook (this will happen manually in the beginning but we can automate it later)

• scenario B: a contributor clicks somewhere on the JP gitbook on the "Edit on GitHub" link

  • that will automatically create a PR agains the book-jp branch
  • the TC reviewing the PR then has to change the target branch to main, to make sure that the changes end up in the mainline, and the contributions are attributed to the contributor correctly ("making the GH profile green").
  • then the same flow as in scenario A

I don't know if this is the best way to do this but it is the solution that I was able to come up with :)

To explain this in simpler terms we could say:

All change should be created as PRs against the main branch

This is the default behavior in GitHub anyways.
The contributors coming from scenario B might not do this but should not be a big deal as the TC can do this for them.
Also at least for the EN book we did not have many people using the "Edit on GitHub" but who knows, maybe for the JP book it will be different :)

Does this help?

[yuhattor]

Thanks for your kind comments and onboarding:)
I have committed your suggestions and could verify that I had write permission

One cosmetic suggestion:
If you don't mind, could you use the code syntax with a single backtick, rather than 3 backticks? That's how we have done it elsewhere in this repo so far, so it (I am adding one inline suggestion about this to the doc but the comment applies to all code blocks).

Got it, I will adopt single backtick from now on.

Also I understand regarding the branch. We are currently translating Getting Started with InnerSource, and thankfully many people are participating regarding this one. The text will be more accurate as more people review it. We are trying to create a policy in the Japanese community to translate InnerSource accordingly to ensure an accurate understanding of InnerSource. The book is very short and easy to read and would be a very good book for beginners, and that would be the same for community members and early contributors.

Once we have decided on that translation policy, we would like to apply it to InnerSource Patterns as well to make it more accurate in the future. If that happens, I think InnerSource Patterns will have more contributors.

There will be more modifications to the branch strategy in the future, but I'll keep an eye on it and try to accurately onboard other members. As for the branch strategy, I'll make sure to properly onboard the other members:)