inlang - Using Version Control to Solve i18n

All right, I'm Samuel, and after this talk, you're going to know what the real problem with internationalizing software is and how something called the Lake Exchange Control System is able to solve this gigantic problem that has existed for decades.

Let's start first things first. What again was E1N of software? It means that you're adapting your software product for different markets and demographics. That means design, messages, translations, payments, and currencies. Usually you do it because you want to expand to different markets, but it's not only expanding to different markets. It might be that you're a US company and you want to target the Spanish-speaking population in the US more effectively. To do so, you have to internationalize, change the design, implement translations, yada yada.

Now in both cases, whether that's global expansion or targeting a demographic in a specific market more effectively, it all comes down to money. Of course it does. Why? Well, if I can target people more effectively, more money. If I can expand to different countries, that means more customers, more money. So, I want to teach you how to solve internationalization of software, which means we got to agree what solving E1N means. And what it means for us, for all the people that are working at E1N, is that we want to enable any software company to go global in a day.

That's a bold statement. You're a German company, for example, and there is a tool out there that lets you adapt your piece of software to the American market, Brazil market, Indian market, Chinese market, all within a day. That's the goal, that's what we have to find a solution for, and that's what we've been working on for the last two years.

Now, why do we do this again? Well, we help you acquire more customers, bring your product out in the world, and ultimately help you make more money. That's a great business proposition.

Okay, what is the actual problem with internationalization? Why have we been working on it for over two years and the business proposition makes so much sense, so you would think that something out there exists already, right? The answer is no, because the problem is kind of hidden.

You see, everyone believes that internationalization is pretty simple. You do some translations, you accept a different currency, you maybe adjust the design. It's pretty simple, right? The answer is yes. If you look at it in isolation, that's not really complicated. What is complicated, though, is that it all needs to be coordinated. Internationalization of software is a coordination problem where you end up with a pipeline like this, where you suddenly realize you need to coordinate the internationalization efforts between developers, designers, translators, auditors, product managers, and everyone else who touches the product in a pipeline that can become extremely complex extremely fast.

So let's get through it as an example. Imagine you're a developer right now, and you're implementing a new login screen. What you as a developer think is, internationalization is simple, okay? I just need to implement some T functions, call them in my code, and what they do is they look up a message in a JSON file, and that's it. That's internationalization, right? Well, for the developer in this case, yes, that's actually most likely it. But then what happens next, right? The login screen is implemented. Where are the translations? Well, they're not existent at this point. So there needs to be someone that tells the translators, you've got to start working. This is already where it falls apart because who tells them that the translator needs to start working? It's a manual process.

All right, so for now, it's a manual process. Translators get to work, and what is this? They're working in a different application. I've never seen that before. So this is a CAT editor, computer-assisted translation editor, and it provides translators with a UI to create translations. It sounds simple, right? But how does the translations, how do the translations from the developer get to the translator and then back to the developer? There's a manual hand-off step which includes importing and exporting all the translations from all those two tools. So the E1N library and the CAT editor. You're already seeing that, oh, shit, yeah, we have a lot to coordinate. But of course, it doesn't end there because once the translators are done, what happens next, right? Most likely, the designers need to review it. The designers need to know whether the translations are now overflowing and they need to adjust the UIs. So the whole spiel begins again.

Now translators somehow need to inform designers and be compatible with the application that designers use. In this case, they want to see in their UI screen tool of choice directly whether the translations work for the UI. And in this case, okay, les et vos creations parlent tous les langues. Sorry, French people. They're deciding, yes, it works. So they're sending it back to the translators and so on and so forth.

We already see one major issue here. The major issue is, yes, we need to coordinate between all those people, but everyone has a different job. Developers have the job of an e1n library where they need to ensure that the translations are displayed. That's vastly different from the job of translators that, you know, have the job of creating and managing translations. Same goes for designers. They have a different job and their job is to make sure that the UI works in all the markets that the application or piece of software's active in. Same applies to auditors, product managers and everyone else. Everyone has an app of choice for their job.

The problem is that the current status quo is that, yes, there are good solutions for developers. And, yes, there are good solutions for designers and for translators. Auditors not at the moment and product managers also wacky. But for developers, designers and translators, good solutions exist. The problem is hundreds of integrations between them are required to get all of it done and any integration always means that there is a data loss. Right. This application says something that this application doesn't understand and the translator says something that the designers don't understand. Everything explodes. Remember, our goal is to help a company go global in a day. If we have this problem, hundreds of integrations, that will take more than a day. So this won't work. The second problem, though, is the pipeline. Right. It's nice if you have an app that works for everything, but you need to coordinate this pipeline. And this is something where we as software engineers and, you know, the audience is mostly developers at the moment. We already have a system like that.

It's called Version Control and CI CD pipelines. We exactly know when something is wrong in the code. Apply the same principles now to internationalization of software and you quickly realize that if you are implementing a log in screen, there should be a CI CD pipeline running that tells you, hey, listen, there is a missing translation. Translators need to create the translations. And once the translators are done, another pipeline runs that says, hey, the designers now need to review the design. And after the designers have approved the review, it goes to auditing. And only once auditing approves it, because you don't want to be legally on the hook in some regions. If your project becomes big, every text, everything that you're displaying to the user will be audited. Only when auditing says yes, so developers say yes, translators say yes, designers say yes and auditing says yes, then you deploy it to the user. That's CI CD in a nutshell. And we've had that for the last 10 years in software engineering.

OK, in conclusion, how can we get to the goal of getting a company global within one day? It needs two things. First, it needs an interoperable file format for applications. We need one file format where every application can work on top of. No more integrations or incompatibility between applications. Second, we need something like version control that software engineers have, but we now need it in the context of internationalizing software. And we call this system Lix, the change control system. Why we call it a change control system and not a version control system, I'll get to that in a second.

Let's look at interoperable file format for applications first. This is the solution that we're sketching with Inlang. It will be an open file format, and you can build applications on top of that for all the personas and teams that are involved in the internationalization pipeline. The big benefit is that all the apps that people use, they just open the same file. There's no import-export between all those applications, which removes the overhead tremendously and ensures that there's no data loss between the applications. Compared to the before and after, so there's the current status quo, good polling solutions for developers exist, maybe designers, maybe translators, but you really want one file format to just build all the apps on top of because then you get interoperability. Okay, that's beautiful.

As I mentioned, you need a second piece though, right? Solving the application piece is one thing. How do we solve the CICD problem? Well, our idea is that you will have this Inlang file format, and we're going to have this Lix change control system, and you will be able to drag and drop this Inlang file into the change control system, and what you get is change control. What that is change control, you will get a change graph for everything that happened in that Inlang file. So someone changed the translation, you know it. Auditing approved it, you know it. And with that change information, you can suddenly start to build collaboration based on files. This is very novel, never seen before, but also you can start to automate the heck out of that. What we as software engineers have with CICD, we're now bringing that to internationalization, localization, globalization, however you want to call it, off software via the Lix change control system. Why is it called change control and not version control? Because it runs in the web browser, which is one differentiator, but second, it also understands changes in all sorts of files. It doesn't only work for text files. The Inlang file is a binary file and the Lix change control system is able to understand what changed in this binary file and is able to do that for any other binary file that you can imagine via plugins. So we call it change control because it understands changes in files and it does not only version them. It understands that the translation in this binary file changed. Okay. That's pretty nice. There we go.

So to recap, what do you need to solve internationalization of software is first you need an interoperable file from it, which is open so that applications can build on top of it and an ecosystem emerges. An ecosystem of apps for translators, designers, auditors, and so on and so forth. And second, you need to be able to control all the changes and coordinate between all those different groups. And that's what we're building in the Lix change control system for.

Why is this beautiful? Because you get that change graph and so on and so forth. We've been at it for over two years and we have a prototype of the Inlang file from this, which some people already use. It is in the form of a directory, but I'm happy to announce that on December 16th, we're going to launch a public pre-release of the Lix change control system. As I mentioned, it will not only work for Inlang files, but for all sorts of files you can imagine and you will be able to build your own plugins and get change control for it. And then in Q1 2025, we will follow up with the .inlang file specification that our current users haven't seen yet. But for everyone else, this will be the final 1.0, so to say, of the Inlang ecosystem and file format.

So I hope you learned a bit out of the talk. If you take one thing out of it, internationalization of software is going to become really simple and the Lix change control system is not only beneficial for internationalization of software. So if you're interested, I recommend that you follow us on Twitter, either Inlang HQ for Inlang related information or Lix CCS, short for exchange control system, on Twitter if you want to stay up to date more with the Lix change control system. Thank you very much.