I’ve worked on a few projects where I did not speak the language, and it was a bit difficult to adapt. You’re never very sure, even when you’re using translators. At times you’re working with people who are willing to communicate in your spoken language, but since I cannot have the final look at the project, it’s not something I always want to do. Most of the time, with no-code platforms, you’re looking at internal tools. Some of the traditional, off-the-shelf tools are already set up for different languages or are able to adapt to them. You’ll see that the field titles, the copy on the page, the buttons, the spacing, and everything else are adjustable and able to adapt to the user’s language.
This is also very important for teams that are working across different regions. You have your EMEA teams, so sometimes we’re going to interact with the Italian, Spanish, German, or French teams. Some of those teams are predominantly focused on their native languages, even though we have English as the central language. For teams like this, when it comes to providing a no-code solution, we tend to have separate pages. For a custom build, we tend to have two or three pages that are language-specified. For the tables, we’re trying to keep them in sync. We still have fields that represent the same thing, but we have the English version and then the other language. We also have the automations and the emails to consider.
For this, it’s going to require a more extensive process. It’s going to take almost double the time because you need someone who speaks the other language to come in and create the copy. I’ll essentially be doing two versions of everything. For the tables, you can have the English version alongside the translated version and then see how it works out, especially when you’re working across different regions. The setup needs to be very lean to accommodate this. You’re essentially syncing different information. If we just want to track information from one region, we’re going to have two versions of everything. If someone switches to another language, the copy has to be in that language. The tables, the fields, the pages, the automations, the emails, and the confirmation messages all have to be translated. These are all things that you have to consider with a custom tool.
For traditional, off-the-shelf tools, it’s not as much of an issue. You simply look for a tool that supports multiple languages. I know tools like Wrike and several others support different languages, so you don’t really have a problem in that area. The choice between custom and traditional becomes clearer when you factor in the language needs of your team. If you’re operating across regions with different native languages, the simplicity of a traditional tool that already handles translation can save you a significant amount of time and effort that would otherwise go into building and maintaining parallel versions of everything.