By Edouard on February 16, 2022
We have been updating our free language file converter tool to now serve pages using HTTPS.
For those of you converting files using its API the server should redirect you from HTTP to HTTPS. If your code doesn’t follow redirects, you should change the code to use HTTPS instead of HTTP 😬
With that, thanks for reading and happy converting!
Follow us on Facebook, Twitter and LinkedIn for instant updates.
By Edouard on February 14, 2022
Hey guys,
We’re excited to announce that we’ve updated our user interface! Our users on G2 felt that it was a bit dated and we agreed with that so we’ve made the design more modern and improved usability - and we’ll keep on improving it in the next few months, little by little, so that you can get accustomed to the changes.
You can see the previous version of the translation interface here.
We have also made our buttons and menus bigger and easier to read.
You can see the previous version of the filters and menu
One very new thing is the new search bar which now combines the buttons to perform a regex search and a case-sensitive search inside the search bar. It is also larger so you can see more when searching for longer strings of text. This make the interface look sleeker and frees up some space on the interface header.
If you want to do a case-sensitive search, just type the text to search and click on the Aa icon. Regex search works the same way.
The old search bar can be seen here
We hope you will like these changes. Thanks for using WebTranslateIt!
PS: If you use WebTranslateIt we’d like to see some honest reviews on the SaaS review platforms, like G2, SaaSHub and GetApp
Follow us on Facebook, Twitter and LinkedIn for instant updates.
By Edouard on November 15, 2021
Last week we released an important update to our queuing system. It makes updating your language files work faster and more consistently.
When a translation is made from the web interface, we don’t directly update the project’s language files. Updating files is a very resource intensive job (it requires thousands of SQL queries) and it would take too long to update the file directly when requesting to download the file. So instead files are pushed to a queue and then updated asynchronously.
We have this system in place since 2009 and it has served us very well. We now have a small army of workers (60 workers working off jobs about files and 20 workers working off jobs to fetch translation suggestions, etc.) and they have been working off over 400 million jobs since its inception. Not too bad!
In the past few months, this system has shown its limits under heavy load, so much that it became our first point of failure. Failure means that files were sometimes not being updated in a timely fashion. We’ve tried to add more workers but it wasn’t doing anything.
The problem was due to a handful of large projects hosting very large files (containing over 20.000 segments per file) being translated and generating hundreds of long running jobs each minute.
Updating files for such projects is slow because it involves pulling thousands of segments from the database and generating very large files. It can take over 3 minutes to update such files, compared to a few seconds on a 4.000 segments file. So things quickly go out of hand.
To put things into perspective, 1 translation and 1 proofread on one of these files create two 3-minutes-long jobs. Imagine a team of translators working these files and you have a backlog of tens of thousands of jobs in queue. And since they are working the same file these are actually duplicated jobs! As these large project get translated these jobs pile up and and all our workers are all busy working off the large jobs, and no workers are available to work off other project’s jobs, and they pile up as well. How can we fix that?
First, we focussed on making these jobs finish up quicker. We improved the code and these 3-minutes jobs now finish in about 45 seconds. Not a bad start. We deployed the changes and monitored the queue. We quickly noticed that while there was definitely an improvement, we were still experiencing the same issue of jobs piling up under heavy load. So, what else can we do to completely fix the issue?
We thought: “Could we rate-limit background jobs for these large projects? We could allow each file to be updated once per minute. Large projects wouldn’t even notice the difference and it would actually work better. And also: couldn’t we do it not only for large projects, but for everyone?”
So that’s the new Jobs architecture that we’re currently using. It works great so far. Whenever we need to update a file due to a translation or status change the system flags it as “to update” with an attribute on the File object. Then, each minute, a cron job runs, checks which files need to be updated and then pushes them to the queue. This way, a file is updated at most once per minute.
We immediately noticed that our jobs server load is now lower, the queue is almost always empty and there is never more than 1 minute of delays after a file update. This makes the system work more consistently for everyone.
This update brings another sweet new features to files. Since we now know when the file was last updated (by a translation or a status change) and we also know when the file was last generated, we can now tell if the file we’re currently serving is stale or not.
We’ve updated our Project API to show if the files that are ready to be served are stale or fresh.
And we also updated our synchronization tool wti to make use of that feature.
If at the time you request a wti pull files are fresh, then no problem: you can download them right away. If they are stale, then the system lets you know by displaying a tiny * right next to the language file name. And now you should never have to wait longer than 1 minute with this new system.
We’ll continue to refine this system further and have other updates planned to our wti gem. With that, thanks for reading!
By Edouard on November 9, 2021
In order to maintain WebTranslateIt in good shape we will have to take the service down for a hardware maintenance and reorganization.
Our servers will have to be moved to a different rack in our datacenter.
In order to do this upgrade we will need to be unavailable on Saturday, November 13th 2021, 19:00 CEST (Paris Time) as the servers are being moved. We expect the downtime to not exceed 2 hours. The website will be unavailable from Saturday, November 13th 2021, 19:00 CEST to Saturday, November 13th 2021, 21:00 CEST.
I would like to sincerely apologize for this second planned downtime this year. We already had another planned downtime for maintenance last month and we strive to keep our service up as much as possible. Our hosting provider had a very bad planning and overbooked the rack we’re currently in, which requires us to physically move the servers to a different location in the datacenter in order to maintain our network performance.
Note that this hardware move will require us to change our IP addresses, but this shouldn’t change anything on your end.
As always, we’ll keep you updated on this blog post and we’ll also post live updates on @webtranslateit on Twitter.
By Edouard on October 22, 2021
In order to maintain WebTranslateIt’s service we will have to take the service down for a hardware maintenance.
One of our database memory module is defective and needs to be replaced.
In order to do this upgrade we will need to be unavailable on Sunday, October 24th 2021, 19:00 CEST (Paris Time) as the server is being repaired. We expect the downtime to not exceed 2 hours. The website will be unavailable from Sunday, October 24th 2021, 19:00 CEST to Sunday, October 25th 2021, 21:00 CEST.
As always, we’ll keep you updated on this blog post and we’ll also post live updates on @webtranslateit on Twitter.
We apologize for this planned downtime and for announcing it at such a short notice, but this is due to an unexpected hardware failure.
Edit 23/10/2021 at 15:08: On top of swapping the memory module, we will perform a full hardware check, which will increase the maintenance window to 30 minutes more. So the website will be down from Sunday, October 24th 2021, 19:00 CEST to Sunday, October 25th 2021, 21:30 CEST.
Edit 24/10/2021 at 20:46: We’re now back online. The faulty RAM module has been successfully changed. Network engineers still need to investigate a network issue which seems to be situated at switch level. Since the issue isn’t urgent and doesn’t require any downtime it will be investigated tomorrow during business hours.
