Product teams
Deliver localized versions of your product faster by automating tedious localization steps.
Localization teams
Streamline your workflows and simplify collaboration with efficient localization management.
Developers teams
Add Transifex to your CI/CD pipeline to continuously deploy new translations.
Marketing teams
Quickly launch multilingual websites to accelerate international growth and conversions.
Translators
Deliver more accurate translations faster, leveraging advanced linguistic tools.
Software localization
Keep software continuously localized and in sync using automated CI/CD workflows.
Website localization
Automate and scale website localization to attract and convert international visitors.
Mobile App localization
Rapidly translate and launch apps globally, ensuring high-quality user experiences across markets.
Get a Personalized Demo Today
Precise, on-brand translations at scale. Language AI delivers context-rich content faster.
Get a personalized demo today
Request a personalized demo to learn how to integrate Transifex into your CI/CD
Product teams
Deliver localized versions of your product faster by automating tedious localization steps.
Localization teams
Streamline your workflows and simplify collaboration with efficient localization management.
Developers teams
Add Transifex to your CI/CD pipeline to continuously deploy new translations.
Marketing teams
Quickly launch multilingual websites to accelerate international growth and conversions.
Translators
Deliver more accurate translations faster, leveraging advanced linguistic tools.
Software localization
Keep software continuously localized and in sync using automated CI/CD workflows.
Website localization
Automate and scale website localization to attract and convert international visitors.
Mobile App localization
Rapidly translate and launch apps globally, ensuring high-quality user experiences across markets.
Get a Personalized Demo Today
Precise, on-brand translations at scale. Language AI delivers context-rich content faster.
Get a personalized demo today
Request a personalized demo to learn how to integrate Transifex into your CI/CD
Heads up! Version 3 of Transifex API is just around the corner! This is a blog post about the history of Transifex APIs, the reasoning behind the decision to proceed with a new version, and its design philosophy.
As you noticed, we call this API version 3. This means that it succeeds versions 1 and 2. Version 1 dates back to when Transifex was an open-source project; it was used to mainly help the localization of the Fedora Linux distribution and other open-source projects. Back then, it was a tool to help synchronize files between version control systems. We did not support parsing of different file formats, we did not extract the source strings and translations in our database, and we did not offer functionality similar to a web translation editor. Our data and business model evolved drastically since then, so API v1 was abandoned.
API v2 has been our most adopted API so far. It is what our transifex-client interacts with. It is based on a library called django-piston which was developed by Bitbucket and, back in the day, was the go-to library for building REST APIs with Django.
Despite its technical shortcomings, which we discuss later in this blog-post, it is a very powerful API. This is evident by the fact that it has been around for so long, even as our business model keeps evolving, and has managed to support countless integrations.
For reference, this is how you can upload a JSON file to Transifex using API v2, with a tool like curl:
curl -i -L --user <username>:<password> -X POST \
-H "Content-type: multipart/form-data" \
-F slug=<resource_slug> \
-F name=<resource_name> \
-F i18n_type=KEYVALUEJSON \
-F content=@/path/to/the/file.json \
https://www.transifex.com/api/2/project/<project>/resources/
When we started developing this API, we thought it would be THE API. It was developed using more modern technologies, namely Python 3 and Django-Rest-Framework, it tackled some of the incompatibilities between the previous API and our business model and managed to address some pressing needs of important users. Unfortunately, after its initial release and while in use, we realized that some of the design decisions would not allow us to scale to the level we wanted.
So, we decided to discontinue its development and give it the name "version 2.5" internally. It is still available under https://api.transifex.com/ and offers some functionality not in version 2, like screenshots.
While the lessons learned from version 2.5 were fresh, we decided to be extra thoughtful with the design of version 3: we wanted the next version to be even more stable, robust, scalable, offering a really good user experience. We formed a cross-team committee to define the problems, research, orchestrate, and write down the decisions, long before we started writing code for it. We were determined to get this right.
The increments to our previous implementations were always in response to the drastic evolution of our business model and users' requests. This meant that they lacked consistency. Here are a few examples:
These inconsistencies meant that it was hard for us to make decisions about how to evolve these APIs. Fixing the issues was also challenging since changes to an API always risk breaking backwards-compatibility.
Another important problem is that the technologies that version 2 is based on are aging: django-piston has been discontinued and was designed to work with older versions of Python and Django. We already had to fork it in order to introduce compatibility with the more recent versions that we use.
The most important decision was using {json:api} as a base for our specification. Here is a quote from {json:api}'s homepage:
If you’ve ever argued with your team about the way your JSON responses should be formatted, JSON:API can be your anti-bikeshedding tool.
Similarly, to upload a file, you will not be making a request to a URL like /project/<id>/resource/<id>/content, like you had to with version 2; instead, you will make a POST request to a URL like /uploads and create an "upload job".
Apart from making the URLs extremely predictable, this has the additional advantage of not having the dilemma of how to design our URLs. Also, it makes the specification more adaptable to changes to our business model. For example, you may have noticed that the root of most of the URLs of API version 2 is /project/.... This is because when version 2 was released, Transifex did not support organizations. With flat URLs, it will be easier for the API to adapt to changes to our business model.
Further to {json:api}, we decided and documented several design guidelines that the new Transifex API should always follow:
One of the most important decisions we took was to use OpenAPI (formerly Swagger) to write the specification of our API. Here is a quote from OpenAPI's homepage:
The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection.
An OpenAPI document is a JSON/YAML file that describes all the endpoints, authentication methods, content-types, URL parameters, request and response payloads, and others that an API expects and supports, in a structured manner. This had numerous advantages for us:
The API v3 journey was long but very rewarding! The benefits that our current users can enjoy are numerous. Furthermore, and because of the way it is designed, we are certain that it will appeal to engineering teams having yet to solve the mystery of automating localization in their apps. We are here to make the lives of everybody (devs, localization managers) much, much easier!
Want to see how awesome API v3 is? Check it out!