BeLazy is famed to have good, personalized, proactive support. However, the fact is that less than 10% of the connection-related errors that are reported get a bug fix.
Why is that? Bugs that can’t be fixed usually belong to two categories: errors within other systems where we have no say and errors we can’t understand.
I’ve written this article to explain the limits of our understanding when it comes to bug fixing and advise how you can report errors properly, to help us find a quick solution. If you’re not interested in our explanations, click below to jump into the suggestions right away.
Where can issues occur? - BeLazy is a complex system...
1- It mostly takes, but sometimes even generates jobs on the translation management system or vendor portal (customer system). This system can act up, be down, a project can be taken by someone else, etc.
2- It’s more complicated when we connect to these systems via the published APIs. For most vendor portals (except for Symfonie and Transline Transact) we use the internal APIs but for Memsource, or localization tools like Lokalise, Phrase, or Transifex we use the documented APIs.
This is generally great news, but not always for us.
it may lack functionality: In Symfonie, the API does not show everything that appears on the screen, while Phrase API does not tell us whether a job has an advanced or basic workflow. Resolutions to lacking functionalities are always workarounds that create prerequisites or the other party developing something.
it may have bugs: for example, the wrong price is returned.
it may happen that the system's user interface works but the APIs are down.
If we use the website-internal APIs or web scraping, we use the same interface you use. If we use published APIs, and there is an issue, all we can do is report it to our partner and wait for a quick fix.
3- Then we have BeLazy. We aren’t perfect either.
4- We also have “red flags”, BeLazy’s error handling feature. We throw a red flag whenever we find an issue. But sometimes we come across issues that we can’t handle, or red flags that provide an explanation that is different than the real issue. When we find something wrong on the source-side that can affect the user, we develop a new red flag.
5- Finally, there is the business management system: XTRF, Plunet, Protemos are all integrated with APIs. They can also be feature-limited or have bugs. For example, XTRF classic project APIs don’t allow file download whereas smart project workflows can’t be extended via the API. In Plunet, for example, certain settings such as the Admin-level “who is the project manager” override our setting up the project manager. Believe me when I say that we have done a lot of thinking to work around these limitations or unexpected results.
How is a bug fixed?
A well-documented bug report is a must for fixing bugs. It helps developers identify the source of the problem. Once we know what the problem is, fixing it is fairly easy in most cases.
Because our logging system is pretty sophisticated — every item has an identifier and a timestamp — digging up this information requires a developer, and may prompt us to go through many instances of messages. It can take between 30 minutes to several hours to dig up the history of one single project.
Thankfully, users know that we need context to solve problems, so most of the time we do receive screenshots. Sometimes, we even receive additional information such as the name of a project affected by a particular issue. Yet, there’s often not enough evidence for us to know where things went wrong.
The problem with a system like BeLazy is twofold:
1- First, fixing an issue is rather easy, nothing like exporting a 500-page Word document that you are stuck with and you need urgent help. If BeLazy did not generate the right analysis, a project manager can add it in 5 minutes, and we all know that PMs have always been great problem solvers. But it is exactly this which makes it very difficult for us to identify what BeLazy did and what a project manager did.
2- The second and more important aspect is that BeLazy’s activity is time-bound. Just because a system is throwing an error at 5:25:22am, it does not mean it will throw the same error if you retry the operation 5 minutes later. The system may have been down for a restart, or it was used by too many users and could not handle the request, etc.
Another important aspect is that configuration is everything. We need to know the incoming project information, your BeLazy mapping rules (especially the workflow configuration or the auto-approval rules) at the time of the issue (if you send me a screenshot now, you may already have edited it), and your relevant BMS configuration.
So, all in all, the more you can tell about the problem, the less we need to guess.
Narrated videos: The best way to report errors
A narrated video is the best way to report an issue and explain what you expected, why you expected that way, and what actually happened.
You can record a video with free tools like Loom, but if you are using Windows, simply press the Windows key + G and you’ll be able to record your browser. If you’re a MAC user instead, pressing Shift + Command + 5 opens up the screen grabber where you can record your video.
Loom will upload your recording directly to the cloud (but be careful with the length!), whereas if you’re using the other tools you will need to upload it yourself. You can use Google Drive or Wetransfer to do so.
What to pay attention to when recording a video?
Remember that we need to see the whole process dynamically, from beginning to end, so don’t be shy even if the video is longer than foreseen. You can help us by saying things like “now we wait” so that we don’t expect you to speak until something happens.
Besides the video, what we need is just the project or the opportunity ID from BeLazy. Just the way you can see on the screenshot below, open up the project from the list with the little arrow, and click on Copy BeLazy project/opportunity ID for support.