Story points

If they are to be used they are best gauged relatively, with experience, intuition and insight, by the Developers who will be doing the work. It's to help them get their arms around how much work they can take on in a Sprint. Forget about a calculation.

Historically, story points are a function of ideal time and a load factor. The load factor is related to the team and their context (such as the broader organization and the type of work). If you take this approach, you would have to determine what your team's or organization's load factor is. Without insight into how your organization works, we can't do much to help you.

Another approach would be to choose a typical piece of work, call that a size, and compare everything else to that. However, this can be difficult if the team composition changes or as the team's context evolves. It could require renormalization, which takes time and effort.

However, I'd suggest a third approach. Don't use story points. In fact, don't estimate at all. Decompose work into the smallest unit that is demonstrable or deliverable through the act of refinement. Once you have a ready backlog of these small units, order and deliver them. You don't have the overhead to explain the notion of "story points" to the team or stakeholders and can focus on the valuable work of designing and delivering your product.

I like to use the word 'size' instead of 'estimation'. The estimation has some connotation of the time value, while the size is more abstract.

When explaining the story points concept, I like to refer to story points as the Boxes of various sizes - 1,2,3,5,8

Then we take one or two average, comparable PBIs and decide that those fit into Box Size 3.

When we refine the Product Backlog Items, we compare the PBIs and put them into the appropriate Boxes. Sometimes we split the PBI into two or more PBIs and put them in smaller boxes.

The Sprint is some sort of Truck on which we load the boxes. The size of it is the team's velocity.

When we drive through the Spritn, it happens that some boxes fall out of the truck. Those boxes need to go back to the Product Backlog and be repackaged again. 

When working with the new team on the new product, the size of the truck is unknown.

Thus for a few Sprints, the Sprint Planning is very intensive, since we need to make a detailed plan for each PBI, who does what, when, and how long. 

After some time we learn what is the average realistic size of our Truck. The planning becomes faster and easier.

However, it may happen that after some time we get into some muddy area (like new technology or other uncertainties) and again we need to do more precise Sprint planning or spend more time on refining the PBIs to be able to put them into the Boxes.

Gentlemen, you're awesome.  I don't blow smoke, I mean it.  Even the order of your responses build upon themselves.  I appreciate you.

Would anyone tell me how they calculate story points

"They" all calculate story points differently.  As @Ian, @Thomas and @Jacek point out, Story Points are relative estimates/sizes or as I like to say guesses.  Based upon the information that is available "they" attempt to agree on a value that is relative to other work that they have done.  

The article that @Thomas linked to is great for you to obtain an understanding of the origins of Story Points.  However, today not everyone uses them the same way as they were originally intended.  That is why you are finding a lot of different information about them. 

Like @Thomas, I actually prefer to avoid them entirely.  They cause more confusion than they provide benefit. Your question here reflects that. People outside of the Scrum Team that is using them are more confused about them than you are.  When people see a number provided associated to a work item, they tend to think of metrics and an ability to compare across people and teams.  But doing that would be the same as ranking sports teams based upon how many points the players think they will score.  But as we know sports teams are ranked by how many matches they win.  The same should be with Scrum teams.  Don't try to determine how effective a Scrum Team is by the guesses that they make.  Use the value that is delivered to the stakeholders because that is how they "win". 

First thing to remember is that story points are NOT metrics. They don't represent any physical measure, time or space, or any other value.

They are not exact volumes, they are abstract and relative

In the nutshell story points are just hanches of developers about the size of tasks they anticipate in next Sprint

Only reason why story points are numerical is because some Scrum masters love to use burn down charts, and story points are giving better illustration at the vertical graph compared to "T shirt size" system of estimating size like S, M, L or XL

You can count on a story point based on complexity, not time. Compare tasks to previous ones, using past experiences as a reference. Regularly reassess and refine your approach. The goal is consistency, fostering accurate estimations for better planning. https://www.scrum.org/forum/scrum-forum/72590/story-points

Sometimes I write the story. Recently, I completed my salesforce training. What was the problem I faced during the training period? I counted the points of my training story by manually sequence.

I hope this will help you.

Los puntos de historia en mi caso los trato como complejidad no como tamaño.

Story points are calculated based on 3 things the amount of work, the complexity and the risk (uncertainties). Note that time / hours do not come into the picture here. Also what needs to be accessed about the work is how much of it is known vs how much is unknown. For example, for a certain task the amount of work is more but the team know exactly how to go about doing the work -so there are no unknowns so to speak but there may be tasks that teams are working on for the first time and hence the number of unknowns might be high. But here is the beauty of the whole thing once you accomplish the complex task it now moves to the known zone and if a similar task comes in you can estimate it better (with a lower point value may be) and that is how you organically improve your estimations.

Regarding conflicting opinions on story points well that happens because people try to do some stuff with story points like mapping story points to hours, standardizing story points across multiple teams etc. The best approach is to have a good reference against which you can estimate and try to improve the estimation organically as you move through different sprints.