Product backlog

The short & quick answer is: you don’t.

===

The Product Backlog is a list of features, functions, requirement fixes etc.

Keep in mind that:
1) The PBI should be understandable and negotiable by both the users and the developer, so you don’t want documents that are only understandable by software engineers. (As in traditional requirement management)
2) Also requirement gathering is part of the development work in the sprint and not (as in waterfall) an upfront activity of an analyst
3) These are two reasons that a light weight specification like User Stories are used quite often in Scrum: it is even more high level as use cases & scenario’s and thus understandable by non-tech guys.

If requirements are identified before a sprint starts, sure document them anyway you see fit.

But try to make requirements elicitation a team effort, so that people that will do programming/testing are also involved.

- How do you gather requirements for the product backlog?
The Product Owner maintains the product backlog. They should capture what the team requires in order to include this in an increment of software.

- How do you transfer the knowledge you gathered for the product backlog to the rest of the Scrum-team and make sure they understand it correctly?
During refinement? The team need to understand the item before committing to providing this item. How the development team refine, document, develop & test the item into working software is down to the team. If you understand something, explain it to the team. You never know, there may be dragons!