In Scrum, there are two kinds of backlogs. The Product Backlog is "an emergent, ordered list of what is needed to improve the product" and is maintained by the Product Owner, with input from various stakeholders (including the developers). The Sprint Backlog is "the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how)" and is maintained exclusively by the Developers.
I don't consider "training" to be something "needed to improve the product", so it doesn't make sense for it to be in the Product Backlog. You can include the creation or maintenance of training material (such as user guides or example videos on the use of the product) as part of the Definition of Done or as some form of acceptance criteria on individual Product Backlog Items. You could make an argument that training is part of the product and associated services and maintaining the training improves the product, but having it as separate items allows for this work to be ordered independently such that all new development efforts are ordered ahead of training updates, which probably doesn't make much sense.
The Sprint Backlog shows the work that the Developers are planning on doing over the course of the Sprint. If a Developer will be giving a training session or will be writing training content, then it may make sense to put this on the Sprint Backlog. This will help the team consider the impact of this effort during Sprint Planning and keep it visible throughout the Sprint. If the Product Owner will be giving the training, however, that wouldn't need to be on the Sprint Backlog, since the Sprint Backlog doesn't include the Product Owner's work nor does it include ongoing work like refinement, other meetings, and overhead activities.
I would lean more toward training material updates being included in the team's Definition of Done or as acceptance criteria on Product Backlog Items. Exactly how you do this depends on the Scrum Team's involvement. I would also discourage Developers from giving training, since it seems like a poor use of their time and skills, preferring to devote that to either the Product Owner (who is already working closely with stakeholders) or, preferably, to a support organization outside of product development.