Learn the basics of Lokalise API in this video. From creating projects and uploading files to adding contributors and creating tasks – I’ve done it all.
But I didn’t stop there. I put Lokalise to a small test with 100 iterations run in Postman to really see what it’s made of. Performance? You’ll just have to watch to find out.
Hi, in this video, I’m going to show you the basics of using the API from Lokalise and how you can get started. And also what is the performance of the little test that I created. Now why are we starting the series with localized is because localize makes it super easy for everyone to test out the API. Even if you have just signed up for the free trial, which is for 14 days, you can fully use all the features of the API. And I don’t think there are actually any restrictions. So that’s why we have API from localize in this very first video. Now, I’m not that super experienced with using API’s and coding in general. But when I searched for localized API, I came across these two articles that you can see right here from localize, which pretty much guide you through the basics of creating projects, uploading translation, house, creating project tasks, and so on. And that’s pretty much what you’re going to see in my test in postman that I’m going to explain to you shortly and of course, the backbone of using any API is the actual documentation, which for localized are found to be very, very useful. It’s very clear here are where you have all the different endpoints that you can be using, you can see all the operations that prove operations that you can do. And what I found super helpful is you can just type in some values here, and it’s generating for you the requests that you can then just copy and paste into whatever you’re using. And if you want, you can even try it out here by simply pasting your API token. Speaking of API token, it’s very easy, like I mentioned before, to get it, even if you have a free trial, you basically go to your profile, and under API tokens, you can generate a new one. So this is the token that I have been using. And as you can see, it has the read and write access, obviously, so that we can create stuff. Now here we are in postman, which is where you can see all the requests that I set up for this video for this test. And let’s continue with the authorization which we just mentioned. So the API key, you simply add it as a header into all of your requests and use the X API token key, and then you just put the value. And that’s pretty much what you have to use with every request. So let’s look at what we have in our collection. First thing that the collection does is course it creates a project. And these are some of the parameters that you need to put in, of course, need to name your project. Here, we are also using this special variable called collection runs, which is pretty much a counter which in the end, as you will see later, We’ll name our projects differently, because we are going to be running this whole collection 100 times so that then in the actual app, we can see all different projects with different numbers. And then you set your base language. In this case, I’m using the English United States. And then you add all the languages that you need for the project. One other thing that I had to learn using postman, if you want to run a collection, and you want to use some of the values that you get in the response, in the next request, you do it through the tests. So in this one, we are basically going through the response and getting the project ID and saving it as a collection variable so that then we can use it in the later requests. So once our project is created, we are going to upload a file. And here you can see the project ID variable is already used in the request. And the way that the File Upload works with localized is that you don’t actually upload the binary data, but you have to encode your file in the base 64 encoding, again, something new that I haven’t used before in my experience, but a very simple google search led me to this page, base 64 dot guru where you simply upload your actual file, and it’s going to encode it to base 64, which is the string, the long string that you can see here, and actually this string represents this file. So this is the test file that we’re using order requests. It has a 100 keys, the first 24 keys are coming from the previous season of TMS UX that I was doing. And then for the remaining 76 keys, I just generated some dummy string. So it’s pretty much just one word per key. So nothing special. This is really just a sample file. So that covers the data parameter for our upload file. What else do you need, you just need to give it a file name and determine which language it’s uploaded in. Now the way that the File Upload works with localized is that the response you’re going to get is going to give you the process ID because the File Upload is a cute process. Again, this is something that’s explained in the documentation. So instead of you waiting for the request to finish the upload and then get our spawns, you get a process ID, which then you need to check for the status of the upload. And that is pretty much what we are doing in the next 30 requests. Here, you can see that our URL is using still the project ID that we got from the first request. And now it’s using also the process ID that we get from the second request. And when it comes to the body, there’s no body. So you basically just do a git on this URL. The interesting part is the script that I have here that is run after the request has been completed. And or I got this with the help of GPT. And this is basically appalling sort of mechanism. So when you send a request to check for the process, sometimes the process may not be finished yet, right? It can be still processing depending on how big the file is. So what this basically does is it’s trying to run this script this this request 10 times, and if it has the status of finished, it’s going to continue to the next request. And if it’s not finished yet, and it’s less than 10 attempts, it’s going to run it again after 10 milliseconds. And if by chance it already run it 10 times, it means that something went wrong, or it’s just taking too long. So it’s going to stop the execution of the collection, in my experience, it usually two, three runs of this request until we got finish. And then we could continue with the next request. So next request that I have is to add contributors to the project. That’s how it works for each project. So contributors don’t necessarily have to be users in your let’s say, Team account. This could be simply just freelancers that you enter their email, maybe give them a name and tell localize and the project, what is the language that they’re handling. And this is writable parameter basically means what they can work on that language, can they actually add to translations. So as usually, I have my three favorite people, we have Krisztian, I and Honza. For the three different languages German, Japanese, and Czech after we add the contributors, the next thing that we need to do if we want to create tasks, so task will basically assign certain keys to the contributors that we have in the project. So in order to assign those keys, we first need to get the keys for the project. And in this case, the URL is very simple. You just again, in the project ID that we have the first request, there’s no need for a body, what our test does here. So basically, this is a script, it creates an array of all the IDs that we have in the project. And so then we can use that in the final request, which is to create tasks. And basically, we’re creating one task called translation, we’re using the key IDs that we got from the previous request. And then we’re doing the assignments here. So for German, we are assigning it to this user with this ID, which is the user that I edit in this request. Now that you understand all the requests that I have in the collection, let’s finally get to some testing and run this to see what it does. So I’m going to use the run collection feature of postman and we’re going to run through all of these requests. And we’re going to do it actually 100 times and we can save the responses. And let’s go the
whole collection run has been finished successfully 400 iterations. So if we go to the first iteration number one, you can see how it goes through the each individual request. And this is also where you can see how the polling mechanism works. So the first time that it did, the status was running a second time it was still running. The third one was post processing. And finally the fourth, Paul gave us the finished status. So it means that after that the execution could go to the next quest. As you can see, the total duration of the 100 iterations was seven minutes, 15 seconds. So seven minutes, 15 seconds, that is 435 seconds. If we divided by 100 iterations, we get or point 35 Second, or execution. Now, is this a good time or not a good one? I don’t know we’re going to see later on. But we’re going to use this time as sort of a benchmark. And we’re going to compare the other API’s against this number. Now, finally, so that you can see that the API actually did something practical that you can see for yourself in the actual UI in the app on App localized at comm is you can see the products right here, right here we have test project number one from postman number two, number three, and it goes all the way up to 100. You can see here we have the base language, which is English United States and then we have our three target language. You can see the word count 236 Words per language and 100. For each one, you can also see that our team consists of four people. So I am the one person, the owner of the project. And then we have our three contributors that we added through the API. So at this moment, pretty much the contributors start working on their tasks that we also edit to each project and complete the translation. And then maybe at some time, you would do something like download the translated files or do some any other post processing you need to do. And that’s it for the first episode of our new series, which looks into the API’s of TMS platforms, what you can do with them, how well they’re documented, and how well they perform. If you liked this video, and you want to see more from the series, make sure you let me know below in the comments, or just give it a like and consider subscribing. And I’ll see you in the next video where we have a look at another API from a popular TMS platform.