The Story of Gleef: From Vision to Smooth Localization

When we launched Gleef, our vision was simple: simplify the management of localization from the early stages of product design. The observation was clear: too often, localization is treated as an isolated step, often pushed to the end of the development cycle. This creates friction and delays that can harm the product's quality and user experience.

Localization was integrated from the earliest discussions about our product. As soon as we began designing Gleef, translation management and localization files were part of the conversation, not just as a product feature but as a strategic issue at every stage of development. It was this proactive approach that allowed us to reduce human errors and ensure better visibility into the localization process. To better understand our vision, you can read our article Revolutionizing Localization: Our Journey, Challenges, and Ambitions

Integrating Localization from the Start: A Priority in the Product Roadmap

In our own product development journey, we quickly realized that localization should not be a secondary element or a last-minute addition. It needed to be an integral part of the product roadmap, starting from the design phase. Now, let's imagine we are working on a new feature or product with an international audience. Here's how we integrate it:

1. Localization in the Design Phase

Take the example of developing our plugin Gleef Localization Key Generator (which you can download right now). From the beginning, it was clear that our product needed to integrate a localization management system into the design workflow, directly within Figma. So, we developed a tool that allows automatic generation of localization keys from designs. But well before that, our designers were already thinking about how translation would affect the interface (text length, alignment, directional text). These considerations became key elements from the outset, not just last-minute adjustments.

We learned that integrating this thinking from the design stage helps prevent formatting or alignment issues from the start. For example, certain characters in languages like German can impact the space needed for text. By integrating this logic early in the design phase, we avoided costly modifications later in the process.

2. Synchronization with Content Management Tools

Once we progressed in development, the next question was: how do we effectively manage all this localized content as we move forward? In the case of Gleef, each translation key generated in our tools is directly synchronized with our platform, which ensures consistent management of localization files and avoids duplicating efforts. This has been crucial to reduce human errors, maintain good control over the source code, and improve the traceability of translations.

3. Contextual Visualization and Real-time Testing

At Gleef, we know that localization is not just about translation. It is also essential to visualize translations in context to ensure they are accurate, relevant, and well integrated into the user interface.

For us, this step has been crucial because it allows us to test translations in a real environment, with the design already in place. This not only helps verify the quality of translations but also quickly identifies inconsistencies or tone errors. This process allowed us to validate translations in real-time and adjust the design without waiting for the end of development.

4. Continuous Integration of Localization into the Product Cycle

The biggest lesson we learned from the development of Gleef is that localization must be a continuous process. Each update, new design, or feature modification must be considered for localization. At every stage of the product cycle, it is imperative that the evolutions of the product are directly synchronized with localization files.

Here’s an example we’ve frequently heard in discussions with companies that are properly using localization: “When we implemented this process, we observed a significant improvement in our teams' efficiency. For example, instead of having to go back to do translations at the end of a development cycle, we were able to anticipate localization needs as we went along, and reduce delivery timelines.” To better understand what benefits localization can bring, you can read our article The Real Impact of Software Localization: Beyond Basic Translation

5. When to Integrate Localization?

So, when should localization be integrated into the product roadmap? Here are the main steps:

• Design Phase: As soon as the product idea is sketched out, start thinking about how localization will affect the design and user interfaces. Generate translation keys from this phase.
• Development Phase: Integrate localization keys into the code as soon as they are created. Use tools like Inlang to centralize and manage translations alongside development.
• Testing and Validation Phase: Test translations in mockups with tools like Parrot to avoid errors and adjust translations as you go.
• Deployment and Iteration Phase: Even after launch, localization should be a continuous process that evolves with product updates.

Conclusion: Localize from the Start for a Better Experience

At Gleef, we firmly believe that thinking about localization from the beginning of product development is crucial for delivering a seamless user experience, avoiding errors, and saving time in the long run. By integrating localization into every phase of development, from design to implementation, we have created a more efficient and transparent process that helps not only development teams but also translators and language managers.

We encourage you to follow this approach from the beginning of your product projects. Localization is not a task at the end of the product cycle, it should be an integral part of the user experience and design from the start. By taking the time to plan it early, you ensure that your product will be ready to expand to the international market from the day it launches.

‍