Product Backlog Items priority

Product Backlog Items do not necessarily have a priority. Product Backlog Items are ordered in the Product Backlog. Priority is one possible thing to consider when ordering the Product Backlog Items, but it's not necessarily the only thing to consider. Some of the other things to consider when ordering the Product Backlog Items include risk, dependencies, cost, real deadlines, and the value of the work.

When talking about priority, it's also important to ask who has that priority in mind. Different things are important to different stakeholders. Fortunately, Scrum offers the Product Owner as the person accountable for ordering the Product Backlog. If priority is a consideration, they are the ones who would determine what the overall priority of each Product Backlog Item is in relation to every other Product Backlog Item and how that priority influences the ordering of the Product Backlog.

I'd also say that priorities aren't something that are "set". Priorities can change over time, as stakeholder needs or market conditions change. What is high priority this week could be much lower priority next week, because some other concern is now a high priority.

The last thing that I'd add is that the client doesn't set the objective of the Sprint. The Product Owner, in discussions and negotiations with the Developers and perhaps facilitated by the Scrum Master, craft the Sprint Goal. The Developers, with discussion with the Product Owner, are responsible for selecting Product Backlog Items for the Sprint. The current Product Goal and the ordering of the Product Backlog influence the Sprint Goal and which Product Backlog Items are likely to be selected for the Sprint. The client isn't directly involved in their process, but their feedback does shape the Product Goal and the Product Backlog.

I second everything that @Thomas Owens says. Priority is only one of the attributes you use to determine the ordering of the backlog.  For example, consider that there is a new feature in the Product Backlog.  Your company has determined that this feature is needed by the end of your fiscal Q3 in order to obtain a revenue goal in fiscal Q4.  This would be a very high priority item. It has been estimated by the Developers that this feature work will take 8 weeks to complete.

But also consider that there is an item in your Product Backlog to fix an issue that is being faced by 75% of your customer base.  It is not impacting organizational revenue but it is making your customers do some additional work to use a feature.  This item has been estimated by the Developers to take about 2 days to correct. 

Given the goodwill that can be generated by taking 2 days to correct the issue, as a Product Owner I would order that issue above the new feature. It is lower priority to the organization but it provides more immediate value to the users and is less effort to produce. 

Another scenario.  Same new feature as before.  Same estimate on it of 8 weeks.  But there is a technical debt item in the backlog that has been estimated to take 2 weeks.  The Developers have told the Product Owner that if they were able to solve that technical debt item, they could complete the high priority new feature in 4 weeks.  

The technical debt is lower in priority to the business but it will allow the Developers to deliver high priority value in a shorter amount of time, thus as a Product Owner I would order the technical debt before the new feature request.

The ordering of the Product Backlog is an ongoing, constantly changing activity.  New ideas, new information are realized every day so management of the Product Backlog is an everyday activity.  

One last thing. Why would the client determine the Sprint objective?  Where in the Sprint Guide does it mention that?  The Sprint Backlog is created and managed by the Developers based upon information obtained from the Product Owner and stakeholders.  The Product Owner is responsible for ensuring that the work done by the Developers is delivering the appropriate value.  If you have a client setting the Sprint objective what is it that the Product Owner does?  It seems to me that the client is the actual Product Owner since they are being held responsible for focusing the Developers efforts.  

When do we set a priority for our Product Backlog?

As soon as the Product Owner recognizes something new about priorities, should they affect the ordering of work and the optimization of value.

I think it's before each sprint after the client sets the objective of the sprint I am right!

Remember that in Scrum the people doing the work make their own commitments. 

and the PBI has chosen they have the same priority or not !!

If that was the case, how would the team then negotiate work out of scope during the Sprint, if they needed to? Where would their contingency lie?