DEV Community: Alexis Clarembeau

A new tool to manage your i18n locale files

Alexis Clarembeau — Fri, 29 Aug 2025 05:20:42 +0000

🌐 CLI18n: The Translation Management Tool Your JavaScript Project Needs

Managing internationalization (i18n) in JavaScript projects can be a real pain. Scattered translation keys, duplicate values, unused translations cluttering your locale files, and the constant back-and-forth between code and translation files. Sound familiar?

I've been working on CLI18n – a powerful CLI tool that tackles these exact problems and makes managing translations actually enjoyable.

What is CLI18n?

CLI18n is a comprehensive internationalization management tool that helps you extract, organize, and maintain translation keys in your JavaScript projects. Think of it as your i18n Swiss Army knife.

🚀 Key Features

🔍 Smart Key Extraction: Automatically scan your codebase and extract translation keys using customizable regex patterns
🔄 Duplicate Detection: Find duplicate translations across locale files to maintain consistency
🗑️ Cleanup Tools: Remove unused translations to keep your locale files clean
🌐 Web Interface: Beautiful, responsive web UI for managing translations
⚡ Real-time Editing: Edit translations with instant file updates
🎯 Smart Filtering: Focus on untranslated keys or search specific terms
📱 Mobile-Friendly: Works seamlessly on any device

Getting Started

Installation

# Global installation
npm install -g cli18n

# Or use locally
npm install --save-dev cli18n

# Or run without installing
npx cli18n extract

Quick Setup

Create a cli18n.json in your project root:

{
  "regex": "t\\('([^']*)'\\)",
  "outputDir": "locales/{{lang}}.json",
  "languages": ["en", "fr", "es", "de"]
}

💡 Real-World Usage

1. Extract Translation Keys

cli18n extract

This scans your entire codebase, finds patterns like t('welcome.message'), and automatically generates/updates your locale files while preserving existing translations.

2. Find Duplicate Translations

cli18n duplicates

Ever had the same translation value scattered across different keys? This command finds them all, helping you maintain consistency and reduce redundancy.

3. Clean Up Unused Keys

cli18n prune-unused

Over time, translation keys pile up. This command removes keys that are no longer referenced in your codebase, keeping your locale files lean and maintainable.

4. Visual Translation Management

cli18n serve

This launches a beautiful web interface where you can:

Browse all translation keys in a clean table
Edit translations inline with auto-save
Filter by language or search for specific keys
Focus on untranslated keys (highlighted in red)
Work on mobile or desktop

🎯 Perfect For These Scenarios

Migrating an existing project to i18n? CLI18n can scan your entire codebase and extract all the hardcoded strings you need to translate.

Working with a translation team? The web interface makes it easy for non-technical team members to contribute translations.

Maintaining a large multilingual app? The duplicate detection and cleanup tools keep your translations organized as your project grows.

Starting a new international project? Set up your i18n workflow from day one with automated extraction and management.

Example Project Structure

my-project/
├── cli18n.json
├── src/
│   ├── components/
│   │   └── Header.js       // t('nav.home'), t('nav.about')
│   └── pages/
│       └── Login.js        // t('login.title'), t('login.submit')
└── locales/
    ├── en.json             // Auto-generated
    ├── fr.json             // Auto-generated
    └── es.json             // Auto-generated

🛠️ Programmatic API

You can also integrate CLI18n into your build process:

const { extractTranslations, findDuplicateTranslations } = require('cli18n');

// In your build script
await extractTranslations();
await findDuplicateTranslations();

Why I Built This

After working on several international JavaScript projects, I kept running into the same issues:

Manual translation key management was error-prone
Finding unused translations was nearly impossible
Non-technical team members struggled with JSON files
Duplicate translations created inconsistent UX

CLI18n solves all these problems with a workflow that actually scales.

What's Next?

I'm actively working on CLI18n and have some exciting features planned:

Integration with popular translation services
VS Code extension for inline translation editing
Advanced analytics and translation progress tracking
Support for more file formats beyond JSON

Try It Today!

npx cli18n extract

That's it! CLI18n will guide you through the setup and start managing your translations immediately.

Links:

npm package

Have you tried CLI18n? What i18n challenges are you facing in your projects? Let me know in the comments!

How are responsive websites doing in 2024?

Alexis Clarembeau — Tue, 22 Oct 2024 19:33:38 +0000

Overview

By 2024, mobile devices will account for over half of all internet traffic. A laptop or desktop computer is no longer a necessary tool for many people, who are increasingly using smartphones and tablets to explore the web. The internet is now mobile-first, whether it's for productivity, social media, or e-commerce. Because of this change, responsive web design is essential to making sure that websites work and look good on a variety of screens and devices.

We know it can be costly and time-consuming to develop for numerous platforms, particularly when creating native mobile apps. It takes several codebases, specialized teams, and continuous platform maintenance to develop distinct apps for iOS, Android, and the web. Businesses incur much higher expenses as a result, and feature rollouts are slowed down. Complexity is increased by the difficulty developers still have maintaining platform-specific adaptations.

There are a number of ways to make multi-platform programming less complicated. Code reuse across platforms is made possible by hybrid frameworks such as Flutter, React Native, and Progressive Web Apps (PWAs). Nevertheless, these solutions frequently have drawbacks.

In today's post we'll talk about responsive websites as a potential solution for building multi-platform applications.

Responsive websites

A responsive website is one that is made to dynamically change its functionality, content, and layout according on the platform, screen size, and orientation of the user. Without requiring separate versions of the website, a responsive website guarantees that the material is designed for the optimal viewing experience on every device, whether a user is accessing it from a desktop, laptop, tablet, or smartphone.

When you use responsive web design, you only need to write and manage a single codebase that functions across desktop, tablet, and mobile devices. As opposed to creating distinct apps for iOS, Android, and the web, this lowers the complexity and development costs.

How to implement it?

To implement a responsive website, you need to use different css techniques such as flexible layouts (like grids), scalable images, and media queries in CSS to adjust the site's design based on the device's screen size. By defining breakpoints, you can change the layout and styling of elements as the screen gets smaller or larger. For example, you can switch from a multi-column desktop layout to a single-column mobile layout, ensuring a seamless user experience across all devices. Here's an example of using a media query to handle a mobile breakpoint:

/* Desktop styles */
.container {
  display: flex;
  padding: 20px;
}

/* Mobile breakpoint */
@media (max-width: 768px) {
  .container {
    display: block;
    padding: 10px;
  }
}

The layout in this example changes from a block layout on smaller devices to a flexbox layout on larger ones. This improves the content's mobile friendliness without requiring a complete redesign.

Bonus: CSS may not need drastic changes

It is frequently not necessary to dramatically alter the layout of a well-designed responsive website for mobile devices. You can easily make your website responsive to mobile screens by changing the layout to a one-column format and making minor adjustments to the sizes and paddings. Certain parts can be made mobile-friendly if needed, but the fundamental codebase stays the same, cutting down on redundancy.

Challenges

The evolution of responsive websites

With new capabilities like Grid, Flexbox, and advanced media queries being nearly fully supported by contemporary browsers, CSS has seen substantial development. Additionally, JavaScript support has improved significantly, acting consistently in the majority of browsers. To assist designers in managing mobile devices with dynamic screen heights (like those with notches or on-screen keyboards), new units like dvh (Dynamic Viewport Height) are being developed.

/* Example using dvh unit */
.header {
  height: 100dvh; /* Adjusts based on available viewport height */
}

Even with these developments, creating completely responsive, mobile-friendly websites remains difficult. Using Service Workers to develop offline-first web apps can be challenging and prone to mistakes. Furthermore, despite its improvements, Safari on iOS still lags behind other browsers in terms of consistency and support, and several issues are still being reported. Additionally, developers may need to address additional edge circumstances brought about by users on outdated devices or browsers.

Real-world example: Our application

As an example, we want to show our application: Touchlead, a marketing automation software.
To achieve mobile support, we built our web application using Tailwind CSS.
We created mobile-friendly layouts easily, using utility classes like md:flex-col to adjust for mobile breakpoints. For example, on desktop, we use a horizontal flex layout, and on mobile, we switch to a column layout, all with minimal code changes.

<div class="flex flex-col md:flex-row p-4">
  <div class="flex-1">Content 1</div>
  <div class="flex-1">Content 2</div>
</div>

This strategy has allowed us to keep our codebase consistent while guaranteeing a fantastic desktop and mobile user experience.

Conclusion

Let's tell us what you think about responsivity in website design in 2024.
Do you use it to build your sites and applications, or, do you consider the challenges are too high?
Your opinions and experiences about responsive web design would be greatly appreciated.
Have you encountered difficulties when creating content for many platforms?
Which remedies have you discovered to work best? Tell us what you think!

From idea to launch: Creating a multi-platform SaaS with a small development team

Alexis Clarembeau — Fri, 06 Sep 2024 05:21:10 +0000

Before we start, two small disclaimers:

This post tells our own experience of building a SAAS application. It doesn't say anything about what you should or should not do. There is no universal truth when it comes to building something. Our goal is to give you inspiration and ideas to build your application or project.

We also use AI-generated images from Bing image creator to illustrate the sections. If you don't like them, tell me, I can change it, if it causes issues in the reading.

Building a SaaS product is an exciting journey, filled with learning and challenges. In this post, I’ll walk you through how we created Touchlead—an all-in-one marketing solution for businesses—starting with just a small development team. While this isn’t about selling anything, we’ll share the steps we took from ideation to launch, hoping you find some useful takeaways. You can check out Touchlead at touchlead.app.

1. Before we start

Why We Created SaaS

The idea of building our own product had always been exciting. With SaaS, we could experiment quickly compared to hardware or on-premise software. The ability to iterate rapidly based on feedback and continuously improve was incredibly appealing.

We also had some past experience building SaaS applications, and starting this project on the side while maintaining our full-time jobs helped avoid the pressure of diving in too fast. It allowed us the freedom to test ideas without the risk of jumping into something prematurely.

Finding the Idea

One of the most important things when creating a product is picking a domain you understand and enjoy. In our case, sales and marketing are critical for many businesses, and it was something we were familiar with. This was our focus for Touchlead: building a solution to simplify marketing for small businesses, helping them generate more leads and close more deals.

Gathering a Team

You don’t need a big team to start. In fact, the more people you add, the harder it becomes to coordinate everything. Initially, I started this project solo, handling everything from coding to marketing. As the idea matured, I reached out to professionals from my network and friends to lend their expertise. If you're starting out, don’t hesitate to work solo—additional help can always come later.

Picking the Name

Choosing the right name for your product can feel daunting, but it doesn’t have to be perfect. The key is to find something easy to understand and relevant to your audience. For us, Touchlead made sense. It reflects our product’s mission: helping businesses get in touch with more leads. Don’t overthink it—many successful applications use simple and effective names.

Our Tech Stack

There’s no universal "best" tech stack. We decided to go with what we knew best: TypeScript, Node.js, Koa, React, and Vite. This is a common and well-supported stack that allowed us to build fast and efficiently. These technologies have large communities and plenty of resources, which made it easier to find solutions when we ran into problems.

However, the most important thing is to use technologies that you and your team are comfortable with, as long as they meet your product’s requirements. What matters most is being able to iterate quickly and stay adaptable as your project evolves.

Make Smart Choices for Multiplatform

From the very beginning, we knew we wanted Touchlead to be accessible on multiple platforms. This meant the technology stack we chose had to support cross-platform functionality without requiring us to rebuild the app multiple times for different devices or operating systems.

That’s why we opted for web technologies. By using a stack based on React for the frontend, we could easily build an interface that works on desktop, tablet, and mobile without needing separate codebases for each platform. With a responsive design, the same React code adapts to various screen sizes, ensuring seamless user experience on any device.

On the backend, Node.js allowed us to create a robust API that works equally well for any front-end client, whether it’s a web browser or a mobile app. This decision also opened the door for future possibilities like packaging the app as a Progressive Web App (PWA) or even using frameworks like React Native to create mobile applications without reworking everything from scratch.

This approach saved us countless hours in development time and ensured that as we expand, we can support multiple platforms with minimal friction. Whether on Windows, macOS, iOS, or Android, our users get the same consistent experience—all without having to build and maintain 10 different versions of the app.

In short, by choosing a web-first tech stack, we future-proofed our development efforts while keeping things flexible and efficient, ensuring Touchlead is accessible wherever users need it.

Hosting Provider

In the early stages, it’s easy to overthink hosting, but the truth is: keep it simple. When we first started, we ran everything locally while testing the application. This allowed us to develop and iterate without incurring any hosting costs.

As we prepared to go live and gain our first users, we opted to rent a single OVH VPS (Virtual Private Server) to host everything, including the app itself, the database, and any tools we needed. This approach kept our costs extremely low while giving us enough control and flexibility to scale as needed. Cloud providers like AWS or Google Cloud can offer great services, but they can quickly become expensive, especially in the early stages when you're trying to stay lean.

By using an OVH VPS, we were able to host our entire stack—from the front-end app to the backend API and database—on a single server. This setup worked well for our initial traffic and allowed us to have everything in one place, simplifying management. For most small projects, this is more than sufficient until you start getting significant traffic.

Managing Costs

Cost control is crucial when you’re a small team, especially when you don’t yet have paying users. With cloud providers, the temptation to spin up multiple services—load balancers, database instances, scaling groups—can quickly drive up your monthly expenses. Instead, by sticking to a single server, we were able to run efficiently without unnecessary overhead.

We chose OVH because it offered reliable service at an affordable price, but similar providers such as DigitalOcean, Linode, or Vultr would work just as well. For us, it was all about finding a balance between performance and affordability.

Scaling as You Grow

As your application grows and traffic starts to increase, you can look into more advanced solutions. One option is to offload certain components (like databases) to specialized cloud services or scale horizontally by adding more servers. Another route is using Docker as a service, which can simplify deployment and scaling by packaging your app into containers.

But there’s no need to rush into this. Early on, keeping your infrastructure simple and costs low allows you to focus more on building features and gathering user feedback. Once you start seeing consistent traffic and usage, then you can explore more sophisticated hosting options.

2. Let's get started

Start Coding

When you start coding, resist the urge to build too many features right away. Focus on the core functionality that solves your users' most immediate needs. It won’t be perfect, and that’s okay—your architecture can always be revised later. Write some tests, but don’t get bogged down in trying to make everything flawless at the start.

Launch and Get Feedback

The sooner you can get feedback, the better. Launching early helps you catch mistakes and fine-tune your product based on real-world usage. Engage with communities, forums, and blogs to gather insights. We used platforms like Touchlead’s feedback system to collect feedback, and it’s been invaluable. Take suggestions seriously, but keep your vision in mind. Ultimately, the only feedback that truly matters is from your real users.

Sales and Marketing

As a small team, you need to get creative with sales and marketing. We relied heavily on free, automated tools like Google Search Console, Google Analytics, and in-app logs. Don’t neglect your onboarding process or marketing website—it’s the front page of your product. Building a professional site can be expensive, but there are plenty of free resources out there (e.g., free themes or platforms like WordPress) to get you started.

3. Once it's live

Iteration

Iteration is the key to success. We keep a list of features and improvements we want to work on and are constantly iterating based on user feedback. You don’t need a complex structure to manage tasks—tools like Trello can be just as effective as more robust platforms like Jira. The goal is to stay flexible and continuously improve.

4. Conclusion

I hope this post provided some helpful insights into the journey of building a multi-platform SaaS with a small team. Feel free to share your thoughts or ask any questions—I'd love to hear your feedback!