Following my previous article on general Korean localization rules, this piece focuses specifically on the complexity of UX and software localization. I'm gonna introduce you to four points you'd want to check in your UX localization journey with some concrete examples, coming from your local guide (me, haha).

But before diving into the details, let's first understand the core cultural context that drives this digital behavior: 빨리 빨리 (Pali-pali).

⚡ Korea’s "hustle and bustle" culture, aka 빨리 빨리 (Pali-pali) 🔗

Approximately half of Korea's population resides in Su-do-gwon (the Seoul, Incheon, and Gyeonggi area), as shown in the chart below:

And this unique density creates a “hustle and bustle” culture, also known as Pali-pali ("quickly, hurry, hurry").

Now, you might ask yourself what drives this unique concentration of population. The answer is quite simple: the capital area offers the bulk of high-paying jobs. In fact, housing prices in non-capital regions dropped for 55 consecutive weeks in 2025, while the complete opposite happened for Seoul and its surroundings. Since everyone is gathered around the same area, there are always lots of people wherever you go. During rush hour in particular, you need to fight your way through the crowd, unless you are working fully remote and don't need to commute. There's even a word for it:  지옥철 (ji-ok-chul, or hellish subway).

The fast-paced nature of Korean culture means one thing for your product: clear CTAs, concise copy, and a seamless user flow are non-negotiable for Korean users. It's also worth noting that Korean applications often integrate multiple features, as users prefer a one-stop solution. While maintaining your core business focus is vital, expanding beyond a single function will set you apart from those that don’t.

With this context in mind, let’s dive in.

📖 Point 1: Get your style guide ready 🔗

For those familiar with the localization process, you may already know that style guides and glossaries are very important. These are even more essential for Korean localization because it creates a foundation for consistent tone.

But what specific points should you consider for Korean style guides and glossaries?

When building your glossary, there are three decisions you need to make for every term:

• 1️⃣ Does it get translated into Korean?
• 2️⃣ Does it get transliterated? (e.g: ice cream → 아이스크림, agile → 애자일)
• 3️⃣ Does it stay in English? (e.g: CTAs)

Then comes the harder question: what do you do with your brand-related terms? Translate, transliterate, or keep them in English? There is no right or wrong answer there. Any of the three can work. You just need to stick with the approach you pick. 

But at least for the first three, there is a simple way to confirm whether you are right or wrong: by using Google or Naver.

A note about Naver 🔗

If you are not familiar with Naver, think of it as Korea's internet in one place: search, blogs, shopping, and fintech (Naver Pay) all in one platform. If you are serious about winning users in the Korean market, you need to understand how it works.

An example: let’s say you want to know how "agile methodology" is written in Korean. Simply type the term into a search engine like Google or Naver. For Google, add "in Korean." at the end. For Naver, you can simply type the English word. Your results will then look similar to the example shown below, and this will help you make a decision.

As you work on a glossary, you also cannot forget to work on a good style guide, since Korean is a language deeply rooted in context.

But what are the essential elements of an effective Korean language style guide?

• 🎯 Purpose of the app and intended user persona
• 🔵 How to handle bullet points
• 📅 Date, time, and numbers
• 🔄 Transcreation rules
• 📐 Measurement units
• 🙇 Level of honorifics
• ✍️ Punctuation rules
• 🎨 Tone and manner
• ✨ Brand voice
• 🗣️ Dialect
• 👆 CTAs

For example, the Korean rewards application Rock to You intentionally uses the Chungcheong dialect, notable for the characteristic "-어유" ending (e.g., "적립속도 올려유" - "increase your reward building speed"). I previously discussed this stylistic choice with the CEO, who explained his aim was to give the application a warm, neighborly feel.

In business, as with anything, there is no "perfect first draft." Your glossary and style guide will need revisiting as your goals and circumstances change. But an imperfect one that exists will always do more for your team than a perfect one that never gets written.

✂️ Point 2: Is your copy clear enough? 🔗

Concise and clear text is a must for good user experience. One of the mistakes that I see too often in Korean UX localization is direct translation.

Let’s say that you have to translate a CTA for your SaaS dashboard meant to encourage a user to upgrade:

The source: "Upgrade now to keep your files."
The literal translation of the source: "파일을 유지하려면 지금 업그레이드하십시오."

The suffix “하십시오.” indicates “order”, which is what most UX writers intend for CTAs. While users will likely understand the intended action, this phrasing feels stiff and unnatural to native Korean users.

After word choice, another mistake I still spot occasionally in Korean UX localization is overlooking readability. Returning to the same CTA example, this is a pattern I see from time to time:

In the Korean version, the text fills the entire button with little to no padding. While English CTAs often allow comfortable spacing between text and other elements, the longer Korean copy leaves no visual breathing room, making the UI cluttered and less appealing.

In reality, adjusting visual assets specifically for the Korean locale is not always feasible. It will be ideal if different locales can have different spacing, but mostly that is not the case.

So, how should this CTA be localized?

In most cases, CTA copy should be as short and action-focused as possible. A more effective translation for this one would be “지금 업그레이드” or “지금 업그레이드하기”, both meaning “Upgrade now.”

While skipping “keep your files” may raise concerns about altering the original meaning, Korean users will naturally assume file retention during an upgrade. For localizing CTAs in Korean, conveying the intended action clearly is more important than preserving every detail of the source text.

📘 Related read: 12 principles of UX writing (with examples)

👋 Point 3: Leave a good first impression 🔗

What good is good microcopy if the user experience itself is subpar? Clear copy only gets you so far. The overall user experience has to hold up too. And user experience starts when a customer opens your service and signs up. That's where first impressions are made.

Conventional email and password registration is a given, but incorporating sign-up options through global platforms like Google, Apple, and Facebook is always beneficial. Notably, these platforms are commonly used for both sign-up and login purposes in Korea as well.

Beyond the established global services, which local platforms should be your priority?

• Kakaotalk, an “all-in-one” messenger app.
• Naver, an “all-in-one” website with different features, including search, blogs, payments, etc.
• Toss, a fintech app whose service ranges from payment, banking and verification, all the way to investing.

Let’s take a look at the sign-up/login page of Rock to You. This reward application, known for its friendly, neighbourly feel, offers users several sign-up options, including KakaoTalk, Google, and Apple.

Now, let's explore other categories. Outstanding, a Korean online news outlet that focuses on startup and tech industry trends, also offers several log-in options: the traditional email and password method, as well as integration with Google, Facebook, and Kakao platforms.

One last example before we move on. This time, let’s explore e-commerce. A-bly is a Korean fashion platform that is widely used by young women. While it initially focused on selling fashion items and perfumes, it has gradually broadened its product range to include categories that appeal to women, such as food and various lifestyle items. Similar to the previous examples, it has integrated multiple sign-in options like Kakao, Apple, Naver, and Facebook, as shown below.

Integrating every platform simultaneously might not be feasible. As the examples show, different companies use different ones and that’s completely fine. The key point here is to offer multiple login options.

💳 Point 4: Favor local payment systems 🔗

Your primary goals are revenue and profit. But users must be able to easily spend money on your product or service for you to succeed. Especially for B2C platforms, a robust local payment system is non-negotiable if you really want users to complete their journeys.

Many international companies might ask: “Wouldn’t PayPal work? What about N26, Revolut, or Stripe?”

The answer is, unfortunately, no. While PayPal might occasionally be used for international transactions, it is generally not an option if you are selling products to Korean users. There are many reasons behind it, such as complex regulatory requirements about financial services, but the main reason is that certain international platforms might not be available in Korea or favored by its users.

These are the most widely used domestic payment methods you should consider:

• Naver Pay
• Kakao Pay
• Toss
• Mobile carrier billing through platforms like NHN KCP

If your brand is B2B, payment and tax obligations work a bit differently. If you have a legally registered office in Korea, you should be able to issue a legally required electronic tax invoice called 세금계산서 (se-geum-gye-san-seo) for VAT deductions. If you do not have a local office, your client will have to issue the necessary documentation for tax purposes. However, due to the complexity of corporate tax law, I recommend checking with your Korean legal or accounting counterpart for definitive guidance.

Above all, if you are trying to sell some sort of service online, there is a registration that you have to do called “통신판매업신고”, which can be translated as “Mail-Order Business Registration Certificate” or “Online Sales Certificate”. You can look up the process online; it’s quite simple.

🔍 3 brand examples in practice 🔗

Let's see how these four principles play out in practice across different industries.

Fintech: Concise CTAs win 🔗

Let’s have a look at the UX of two of the fintech platforms we've mentioned above: Toss and KakaoPay. If you check their CTA buttons, you'll notice the text is very concise. A common variation involves adding -하기 (e.g., 방문하기 - "to visit") to the verb, while other CTAs simply use the base verb (e.g., 송금 - "to send"). Feel free to use either style, as long as you ensure the resulting text fits the design constraints.

Travel: Functionality & convenience 🔗

Airbnb is an app that is well-known, especially for those who are not fond of hotels! In my experience, it is also one of the best-localized apps for the Korean market, both in copy and in functional design. Take a look at the pink button on the activity page and the rooms page:

The CTAs are, again, super concise: 예약 가능 여부 보기 (‘Check availability’ in English) and 날짜 표시 (‘Show dates’ in English). As previously noted, the most effective practice for these CTAs is to conclude with a verb or the Korean grammatical forms -하기 / -기, a pattern which Airbnb's CTA strings effectively follow.

The Korean travel app NOL (Yanolja's travel booking platform) is another super app that offers extensive services like flights, hotels, and tours for both domestic and international travelers. The app's payment screen is highly convenient, offering more options than competitors like Airbnb, and including local platforms as Naver, Kakao, and Toss.

All these case studies prove that offering familiar services in one centralized platform incentivizes Korean users to stay. Given that most Koreans find speed and convenience important, this is your product's competitive advantage over other international platforms that fail to do so.

✔️ A tool that rises to the occasion 🔗

If you have made it this far, you already know Korea is not a market you can wing. It requires real commitment to localization, and tools that work for you. Concise copy respects how Korean users actually read and interact with their apps, a smooth sign-up flow with familiar local options signals that you understand the market, and local payment methods tell users you are here for real, not just testing the waters. You'll also need a glossary and style guide to help your team sound natural and stay on-brand.

Localazy offers you all the features to comply with the high standards of Korean users: from a Style Guide that you can apply across all your projects (whether you use AI, human translation or a mix of both) to a Glossary to keep your copy tight, an easy-to-use UI to onboard your team, and Automations to update and sync your Korean workflow cleanly. Try it out for free today or drop the team a line if you need assistance to set up your project.

That moment taught me something that would shape my entire career: knowing Arabic isn't the same as knowing which Arabic dialect to use. Twenty years later, as a program manager for clinical outcomes localization at Lionbridge, I spend my days preventing companies from making million-dollar versions of my shepherd mistake.

🪖 My path from military intelligence to clinical trials 🔗

The US Marine Corps sent me to the Defense Language Institute after I graduated high school in 2000. The training was intensive: 64 weeks total, with the first month focused entirely on sounds and the writing system. When I got deployed, my work centered on intelligence collection, transcription, and translation in Arabic. I spent five years reviewing information and catching things that other linguists usually missed because they didn't understand cultural context.

After the military, I studied linguistics as a science, focusing on sociolinguistics, where language and culture intersect. That foundation helped me understand not just how to translate Arabic, but why different approaches work for different contexts.

Today, I manage the localization of clinical outcomes assessments. In plain language, this means I work on questionnaires used to collect data in clinical studies. All of it requires precision because mistranslations of this type of sensitive information can invalidate years of research and throw millions of dollars in drug development down the drain.

⚠️ Four industries, four mistakes 🔗

Design & signage: A broken RTL layout 🔗

My first encounter with corporate Arabic failures came in a welcome box. I'd just started at GLOBO, an over-the-phone interpreting company. They sent me marketing materials in multiple languages. I looked at the Arabic translation of “welcome” and immediately saw there was a problem, but they'd already paid for professional translation and distributed these materials to partners, clients, and hospitals across their network. Their answer to my feedback was depressingly simple. The translation had been correct originally, but then they put it in InDesign without configuring the right-to-left settings properly, and chaos ensued. The Arabic script was reversed, text direction was wrong... One misplaced dot had changed entire words.

Years later, working on hospital signage for the same company, I warned them multiple times that some materials would be problematic when they went through design. I needed to check the final output before they printed anything. The design team declined my review, printed thousands of signs, and distributed them to hospitals. Months passed before a patient finally noticed. The Arabic was backwards and meaningless. There were similar errors in other languages, too. Our name was all over those signs, so you can imagine the impact on our reputation.

Ahmed Megahed, a localization program director who spent years in sales and account management, confirms this pattern repeats across the industry:

“When I used to work in sales and tried to explain why Arabic needs special technical handling, clients would think I was trying to oversell.”

The technical reality is just straightforward: Arabic isn't compatible with standard Western design workflows without explicit configuration. The Arabic script, where letters connect and change shape based on position, simply breaks when formatting isn't set correctly. Visual verification by native speakers is a non-negotiable because (as you can see), a single mistranslated hospital sign error tells every patient that you didn't care enough to check.

Intelligence: When my expertise wasn't enough 🔗

Most Western brands start from complete ignorance about Arabic dialects. My first job after leaving the Marines illustrated this perfectly. I worked for a company contracted with the Bureau of Prisons, transcribing phone conversations between inmates and their families. They assigned recordings based on my military intelligence experience. I listened for about an hour, then went back to management explaining that I couldn't understand a single word. My specialty was Iraqi Arabic and this was a Yemeni dialect.

One of the managers questioned whether I actually spoke Arabic. Another manager, a native Spanish speaker, finally made them understand. She explained it like someone from Argentina trying to understand someone from Colombia. No amount of intensive Arabic training prepares you for every dialect. To me, Egyptian, Iraqi, and Lebanese are really separate languages.

As an Egyptian Arabic speaker, Ahmed reinforces this reality from the vendor side:

“I cannot understand Moroccan people when they speak to each other. It's not one size fits all.”

Health: Dialects can work against you 🔗

But there's the other side of the coin. Once clients understand dialects exist, they often swing too far in the opposite direction. They demand specific dialects when Modern Standard would actually work better.

My Tunisia project exemplifies this. The client specifically requested Tunisian Arabic and French for a clinician-reported outcome assessment. This was a highly technical medical document that doctors would complete. The clinician would be highly educated and understand the standard terminology, which is the most commonly used in these instances. Nothing in the content would require specific adjustments for Tunisian culture.

Modern Standard Arabic would let the client deploy the same assessment across every Arabic-speaking country. Insisting on Tunisian Arabic limits them to Tunisia and requires creating new translations for every new market they enter.

For health, law and technical industries, Modern Standard Arabic is usually a better choice than a dialect when it comes to reports and documentation

I spend an enormous amount of time convincing some clients that dialects matter. When I then tell other clients that Modern Standard is the right choice, it feels like I'm contradicting myself. But the context determines everything:

• Marketing to recruit for clinical studies needs dialect-specific content because you're trying to reach hearts
• Reports where patients describe their daily experiences need cultural and linguistic specificity
• For clinician-reported outcomes, legal documents, or technical specifications, it's safe to say that Modern Standard is enough, because it reaches everyone without limiting your geographic scope

In summary: the dialect decision requires context and expertise, not assumptions about what "premium" localization looks like. Ahmed points to Netflix and Amazon as success stories, noting that Netflix's localization manager came from Iraq and understood the nuances: “She really understood how to act and when to localize to which locale.”

Marketing content: Safe only in theory 🔗

"Marketing content is low-risk". This was the assumption behind a massive localization project for a large pharmaceutical company. The materials were documents explaining what the clinical trial involved and the source English was packed with idioms. One phrase in particular stood out: “Out of the blue”.

When reviewing the back-translations, I noticed something odd. Every single language returned the phrase translated word-for-word. That shouldn't happen: when content is well-localized, back-translations show how translators interpreted and adapted the meaning. I checked the Arabic directly. It literally said “out of the blue”. Four English words dropped into the Arabic text and were completely meaningless to Arabic speakers. We had already delivered this whole project with materials that would mean nothing to the patient population we wanted to address.

In the end, we needed two extra weeks to go back and redo everything. After investing millions of dollars and months of work, the company was risking getting participants for their clinical trials because the recruitment materials didn't make sense. We simply couldn't accept this alternative.

In my current work with clinical outcomes assessments, the stakes are even higher: invalid translations mean invalid data collection. This leads to regulatory agencies rejecting your submission and, ultimately, the drugs that could help patients never reach the market.

In this instance, the solution starts before translation begins with source content that is localization-ready. You need to remove idioms, eliminate culturally-specific references that won't transfer across languages, budget for back-translation validation on critical content... It's painful, but the cost is negligible compared to the cost of failure.

☝️Context matters more than budget 🔗

I've spent 25 years building expertise. I understand dialectical variations, cultural context, and industry regulations, yet clients regularly doubt my recommendations.

I believe this resistance is just psychological. I sometimes spend too much time convincing people that dialects are important, but then I have to rework my previous argument when Modern Standard is the right choice. Clients, however, just perceive this as an inconsistency. The resistance also comes from sponsors who make geographic decisions without understanding linguistic implications, as I mentioned earlier regarding the pharmaceutical company in Tunisia.

In all of these cases, what I actually want as a localization manager isn't more money or longer timelines. I want complete project context. What's your content? What's the goal? I want to know all of that so I can give you the best solution.

Ultimately, successful Arabic localization comes from companies that don't treat it as a commodity. They understand they have to be strategic to reach their final audience and provide complete project context. They also trust expert recommendations, even when those recommendations seem counterintuitive, because localization teams have seen projects fail and know what works. Give them the information they need and trust their judgment.

👂 No need to be an expert: just listen to one 🔗

That Bedouin shepherd walked away with his flock, and I (somehow?) completed my mission. What I learned was that language competency means nothing without cultural understanding and contextual judgment.

25 years later, the same lessons from companies making these "shepherd mistakes" come up over and over:

1. Technical preparation matters, because Arabic breaks standard Western design workflows. This is why I recommend budgeting for technical QA, not just linguistic review.
2. Dialect decisions require context. Technical, medical, and legal content works with Modern Standard Arabic. Marketing, entertainment, and patient-facing content needs dialect-specific localization. Geographic specificity isn't always better.
3. Source content quality determines translation quality. You can't localize idioms that don't transfer across cultures. Remove culturally-specific references before translation begins.
4. Expert judgment beats assumptions. Your localization team has encountered patterns you haven't seen and will work infinitely better if you give them complete project context.

The Arabic localization landscape confuses Western brands because it demands something counterintuitive: sometimes more specificity is wrong. Sometimes the premium option creates limitations. Sometimes standardization reaches more people than hyper-localization.

Companies that understand this get their hospital signs right and end up collecting valid data through their localized clinical trials. The good news is: you don't need to become an Arabic linguistics expert. You just need to work with people who are experts and actually listen to them.

Since then, the AI models have improved significantly, new players have emerged, some have lost their popularity, and some have gained a bit more. But the number of users and output quality are not the only metrics that shifted.

The way people interact with LLMs has fundamentally changed: from single prompts fired into a chat window to structured workflows built around context, consistency, and control.

In 2025, you picked a model and prompted it. In 2026, you create translation workflows built around context, consistency, and quality control. This includes AI in-context tools in Translation Management Systems that refine QA, style, and terminology consistency, and vibe-coded solutions with an LLM layer designed to meet the burning business needs.

The popularity of context-infusing features such as AI Projects or custom assistants offered by some LLMs has grown, too, which is reflected in OpenAI's State of Enterprise AI report, published in December 2025. It indicates that usage of structured workflows such as Projects and Custom GPTs increased 19× year-to-date, now accounting for 20% of all enterprise messages.

In 2025, you picked a model and prompted it. In 2026, you create translation workflows built around context, consistency, and quality control

Databricks’ 2026 State of AI Agents report paints a similar picture: enterprises are moving from single chatbots to multi-agent workflows, which grew 327% in less than four months. This shows a rapid shift toward more complex agentic systems rather than single-turn chat use.

Add to it easy set-up for connection with external apps, quick access to tools covering your most common tasks (e.g., with Claude Agent Skills), and options to work with files on your desktop (e.g., with Claude Cowork), and you’ll gain endless possibilities of customization and context enhancement, leading to better quality. And this quality is sometimes as good as human translation.

But don’t take my word for it.

👀 Well configured model > "best" model 🔗

The findings of the WMT25 General Machine Translation Shared Task run across 30 language pairs on challenging texts from six different domains and three source languages indicate that Gemini 2.5 Pro deserves the highest place on the podium. It was the top performer for 14 language pairs, and the translation quality generated by this model was equal to or better than human translation in 10 of those pairs.

What’s more, human translations, often considered the “gold standard,” ended up in the top cluster for only six of the 15 language pairs. These results could reflect the stylistic or lexical preferences of annotators, but one thing is sure: when properly set up and equipped with the right context, AI models can now deliver surprisingly accurate output.

The best-performing models now are the best configured, the most context-aware, and the most consistent ones

Similar observations can be found in the State of Translation Automation 2025 Industry Report by Intento. Its data shows that tailored solutions consistently beat generic engines. What’s more, human reviewers frequently couldn't tell AI output apart from human translation and often preferred the text created by AI. Instead of naming a single best-performing model, the report indicates that the best scenario is to use a multi-agent workflow. With separate agents for translation, review, and post-editing, this solution produced the highest average performance, earning the top ratings in 9 of 11 language pairs.

The results vary per language pair (e.g., Claude Opus 4 and Sonnet 3.7 ranked the best for German, Japanese, Korean, and Italian, while Gemini 2.5 Pro and Flash were the best for Chinese, Ukrainian, and French), but the key message to take home is: the model choice matters less than how you configure it. This confirms the prevailing assumption that once fueled by the right context, your AI model can be unstoppable.

🤺 The battle rules explained 🔗

Considering how fast things are changing, a follow-up to the Great LLM Translation War seems like a must. So, I’ve risen to the challenge and divided the world into two parts again: East and West, and assigned three models to each side.

The East Side is represented by Kimi K2, DeepSeek, and Qwen, whereas the West Side is all about ChatGPT, Claude, and Gemini.

Why these models? 🔗

The battle participants were partially selected by popularity scores (the West Side models), partially by curiosity (Kimi K2, the newest of them all), and partially to allow for handy comparison with the first battle, where DeepSeek and Qwen gained surprisingly good results.

What are we testing? 🔗

📄 The full text provided for each model is more complex than in battle no. 1; it’s also longer, comprising 450 words of marketing copy about a fictional AI-powered sleep-tracking ring. The source is English and requires strict adherence to reference materials to be rendered correctly. That’s why every model will receive not only the source, but also the relevant context.

💬 Where possible, all these assets will be fed into a project built inside the model – no integrations with TMS or other platforms, just a standard setup on the LLM website with reference files attached to the prompt. This makes the battle fair for everyone (not all tested LLMs can be integrated with localization platforms), and you, my dear reader, can easily replicate the results without worrying about any missing technology or connections.

For a better taste of the source, here’s a sample of our imaginary product:

What about assessment? 🔗

To allow for a direct comparison, the scoring criteria will remain the same. Output from every model will be assessed by professional translators based on:

1️⃣ Consistency with translation memories
2️⃣ Coherence across paragraphs
3️⃣ Consistency with the style guide (e.g., gender neutral, engaging)
4️⃣ Contextual appropriateness (e.g., does it fit the marketing context? Is it right for the target users?)
5️⃣ Accuracy (how closely the translated text matches the meaning of the source text)
6️⃣ Fluency (whether the translated text reads naturally in the target language)

All these indicators will be assessed on a scale from 1 to 5 for two language pairs covered in the Battle no. 1: 🇵🇱 English-Polish, a medium-source language, and 🇭🇷 English-Croatian, a low-resource language. A note on the last indicator: it replaces the “Correct rendering of mobile app strings” from the previous test, since now the translated content will differ.

✍️ This time, the source text won’t contain mobile app strings, but something more challenging: marketing copy for a technical product. Packed with brand voice, technical terms, and references to other campaigns. Something where literal translation is a big no-no, style guide matters, and consistency with previously released content is crucial.

📓 Each LLM will be asked to provide a context-specific translation, based on a detailed style guide (including, e.g., friendly, approachable style, gender-neutral language, correct terminology, non-translatable terms), glossary (10 terms in English with Polish and Croatian translations), and translation memory uploaded as an XLSX file (30 segments of varied match rate, from 100% to 50%). The instructions will also contain information about the type of results we’re looking for, such as natural, engaging translation consistent with the uploaded documents.

🧠 For each LLM, we’ll choose the currently newest version, preferably with the thinking capability, since analyzing so many references requires a deeper understanding.

💬 Finally, each model will be presented with the same prompt:

Disclaimer: The translation quality assessments and comparisons presented in this article are based on a limited set of tests performed by language professionals and should not be considered exhaustive or definitive. Due to constraints such as access to full model capabilities, proprietary algorithms, and the broad range of potential test conditions, our benchmarking efforts may not fully capture the capabilities of each model. We encourage readers to consult additional research and papers that offer more extensive benchmarking analyses. Bear in mind also that models used in these tests are updated and change all the time. Our benchmarking criteria might be limited.

⚔️ The great LLM battle no. 2 🔗

Below you can see the result of our great translation battle, categorized by models. First come the three Western LLMs, followed by the Eastern group.

ChatGPT, version GPT-5.5, standard thinking 🔗

For this and the following model, translations were set up as Projects. In Polish, all glossary terms landed correctly, and the style guide was applied. On the TM side, the model tried to make an effort, but it was quite selective. For 95% matches, it often reached for its own phrasing instead, for example, it translated “while you rest” as "gdy odpoczywasz" rather than "podczas odpoczynku" available in the TM.

It made similar blunders for "dane z czujników" instead of "dane czujnikowe" (“sensor data”) or "metryki próżności" instead of "wskaźniki próżności" (“vanity metrics”) that were expected based on the TM. Most 85% matches were missed entirely. There were three 100% matches available; the model applied two of them and rewrote the third from scratch. And that was the opening sentence – so not something hidden in the middle that could be difficult to recognize.

It seems ChatGPT trusted itself more than the abundant TM. The translation was accurate, but not entirely fluent, with many awkward or slightly literal phrases.

In Croatian, this model provided the most balanced output overall. It ranked high in every single category, and the output required only minor post-editing, mainly for a few slightly literal formulations.

Claude Opus 4.7 🔗

Claude turned out to be the most fluent of the six for the Polish translation. The model applied all TM matches and missed only one 75% entry, rendering "Wskaźnik stresu autonomicznego" instead of the TM's "Autonomiczny wskaźnik stresu". Short source sentences came out less clumsy than in any other model, with fewer word-for-word calques. One headline tripped it up: "Zbudowany na trzech latach Ciebie” for “Built on three years of you” was too literal.

Terminology and style guide were both applied correctly, hence the overall high rating.

In Croatian, the model provided strong results but struggled with style-guide compliance. The key issue was the Croatian diacritics and incorrect SpO2 formatting instead of SpO₂. Overall, the output for this model can be deemed usable for both languages; however, only after careful review.

Gemini 3 Thinking 🔗

Since no project feature was available here, the files and instructions were uploaded together with the prompt. In Polish, the model showed a couple of accuracy issues. "Have been interpreting" came out as "interpretowała" – a verb rendered in past tense, where "interpretuje" (present tense) would have been more appropriate in this context. A grammar slip appeared in one string, and the TM also took some hits. The model failed to replicate a few phrases from the memory, missing similar entries to ChatGPT. Terminology and style guide were otherwise applied correctly.

In Croatian, the model ranked high for fluency but ignored the style guide on several occasions. For example, the phrase “fotopletizmografija (PPG) senzor” wasn’t rendered correctly. A more idiomatic option would be “senzor za fotopletizmografiju (PPG)” or “senzor fotopletizmografije (PPG)”.  The term “SpO₂” wasn’t formatted as per the style guide, some phrases included agreement problems (e.g., in “Dostupno sada u bojama Midnight, Chalk i Sand.”), and a few technical terms came out with awkward phrasing.

DeepSeek R1 (DeepThink/Expert) 🔗

There is no project feature here either, so files and instructions were uploaded together with the prompt. For both translation tasks, the model took the longest time to think. Croatian translation appeared after approximately 6 minutes, while for other models, the thinking time never exceeded 3 minutes. Before displaying the Polish translation, the model thought for 211 seconds. This time was not spent recklessly, though. Deepseek turns out to be the most thorough on TM entries in both languages.

For example, in Polish, all matches were applied correctly, including the low ones and the tricky entry with "autonomiczny wskaźnik stresu" (“autonomic stress index“) that tripped up most other models.

In Croatian, the model applied the TM, style guide, and glossary with surgical precision, delivering the second-best translation.

It was not all roses, though, and both languages included minor blunders. In Croatian, some phrases were slightly less natural from the marketing perspective. One good example of this issue can be found in “na temelju vaše akumulacije duga spavanja u stvarnom vremenu”. The phrase was translated accurately, but sounds nothing like the approachable technical language prescribed in the style guide. A lighter Croatian marketing version would be “na temelju vašeg stvarnog nakupljanja duga spavanja”.

In Polish, there were minor grammar mistakes, literal phrasing, and a few clumsy constructions. Gender neutrality was missed for "pracowników" (“workers”), but other requirements of the style guide and terminology were applied correctly.

It seems that what DeepSeek gained in precision, it lost in fluency.

Qwen 3.6-Plus 🔗

This model offers a Project feature, so reference files were uploaded as project files. It also took longer to analyze the file, compared to the Western group models. In Polish, the TM compliance was solid with only one low-match entry missed ("Autonomiczny wskaźnik stresu"). The problem was fluency. Clumsy compounds like "mikro-wybudzenia", awkward phrase order in "faza lekkiego snu" for “light sleep transitions”, and constructions like "kontekst do działania" (“Actionable context”) and "stres późnonocny" (“late-night stress “) made the text feel unpolished. Passive voice appeared where it wasn't needed. The model translated accurately, but not as a professional native translator would.

Things didn’t look up for the Croatian translation either. Overall, Qwen provided the weakest output for this language pair. Grammar hiccups, case-related conflict, and missing context were the key issues behind the lowest ranking. One example of issues in this category is the phrase “na temelju vašeg dug spavanja u stvarnom vremenu”, which is not grammatically correct. After “vašeg”, the noun phrase must agree in case, so the correct form would be “vašeg duga spavanja” or, more naturally in this context, “vašeg stvarnog nakupljanja duga spavanja”.

Kimi K2.6 Thinking 🔗

Like DeepSeek, this model spent a lot of time on thinking (nearly 9 minutes), and all instructions plus files had to be fed as a simple prompt because of the missing Projects feature. In the case of the Polish translation, the thinking time was rewarded with probably the most creative translation in the set. It was less literal than ChatGPT or Gemini, with noticeably better flow. On TM, Kimi missed only one low-match entry ("wskaźniki stresu autonomicznego"). Two issues pulled the score down. The first one was the gendered forms for "podróżników" and "pracowników", although the style guide required neutral phrasing. Another one was a fluency glitch in the final two sentences, both of which contained the same word ("już"), a repetition that a quick read-through would have caught. Or one that a professional translator wouldn’t have made at all.

For the Croatian translation, the model generated natural and marketing-friendly text, doing its best to apply all the provided resources. The TM and glossary compliance were strong, but it struggled with fluency. There were linguistic and structural issues, including case/agreement problems and changes to line breaks.

📋 What’s the LLM leaderboard? 🔗

This is how each LLM scored for each indicator and language combination:

History repeats itself. battle no. 1 ended with no clear winner, and so does battle no. 2. All tested LLMs turned out to be extremely powerful and capable of rendering correct translations in Polish and Croatian, based on the provided context. No matter the setup (whether it was a project or a simple prompt with all files attached), the models accessed style guides, glossaries, and translation memories, spent some time analyzing the context, followed the prompt accurately, and created content that was not only linguistically correct, but also, in most cases, in line with the brand rules.

ChatGPT was the least accurate when it comes to reusing entries from the Translation Memory, while DeepSeek was the most precise in this aspect, applying all matches, even those below 80%. Glossary and style guide enforcement (excluding the rule on gender neutrality) was handled correctly by most models in both languages.

This time, all tested LLMs were extremely powerful and capable of rendering correct translations in both Polish and Croatian when given the context. Guides, glossaries and TMs were used, and the content created based on them was mostly in line with brand rules

Of course, this doesn't mean that the translations were perfect. While there were no big issues in terms of accuracy, fluency varied, leaving room for improvement. Literal phrases and grammatically awkward constructions appeared in nearly every output to a different extent. Although the texts could have been infused with more creativity and personality, they were mostly on brand and aligned with the provided context.

🆚 East or West: what’s the best? 🔗

When it comes to the Western vs. Eastern divide, our test shows that DeepSeek, Qwen, and Kimi generate results comparable with the frontier models, at least for the languages and content selected for our experiment.

There is no clear winner in this group. The interesting part, however, is that for Polish translation, the Eastern models slightly outperformed ChatGPT and Gemini, while Claude led the overall leaderboard. For Croatian, it was ChatGPT that took the spot no. 1, followed by DeepSeek and Claude.

Simply put, the East retains its strong position thanks to DeepSeek, and the West shines through strong results from ChatGPT (for Croatian) and from Claude (for Polish). These results may, of course, vary depending on the language pairs, content type, and the quality of the provided context.

🏆 And the winner is… 🔗

What does it all mean for your content? Which LLM should you choose for your translations?

There’s no universal solution, but one thing is sure: the future is integrated. No one will spend time and tokens to manually run multiple prompts for multiple language pairs in several LLMs, and with several reference documents attached to the prompt. For the best result, you need a system that lets you easily choose the model that delivers the best result for your language and content type, upload context that stays in the system and is reusable, when necessary, plus provide instruction that can be applied to other projects. That’s exactly what an orchestrated, agentic system offers.

One such solution is Localazy: you upload your glossary, add TM and a style guide, and run pre-translation using their proprietary model, Localazy AI, which has been fine-tuned to provide the best for localization use cases. The same context materials can be used for translation into several languages, so there’s no need to create a separate project per language or copy-paste your prompt in the LLM’s interface several times. Everything is connected, easy to use, and transparent when it comes to token use.

If that sounds too good to be true, have a look at the test I’ve performed recently to find out if Localazy AI can handle the context correctly.

💬 FAQs 🔗

Have Chinese LLMs improved since 2025? 🔗

According to research from OpenRouter and Andreessen Horowitz, Chinese open-source models went from roughly 1.2% of global AI usage in late 2024 to nearly 30% by the end of 2025. Their performance has improved significantly. For example, DeepSeek’s V3.2-Speciale model won gold medals in the International Mathematical Olympiad and the International Olympiad in Informatics.

According to BenchLM.ai, the gap between the Chinese model and the global frontier is shrinking. Number one Chinese LLM is DeepSeek V4 Pro (Max), followed by DeepSeek V4 Pro (High) and Kimi K2.6. CAISI Evaluation assessed that DeepSeek V4’s capabilities lag behind the frontier models by about 8 months. This assessment also confirms that DeepSeek V4 is more cost-efficient than other models of similar capability.

Are Chinese AI models as good as Western models for translation? 🔗

Our tests prove that the top Chinese models (especially DeepSeek) are comparable to the Western models when it comes to translation. With the relevant context and precise instructions, these models are able to generate decent results.

Which LLM is best for localizing a mobile app? 🔗

There’s no one-size-fits-all solution. The results will vary depending on the language. According to the findings of the WMT25 General Machine Translation Shared Task, the best system overall was Gemini 2.5 Pro (it ended up in the top cluster in 14 language pairs). Our experiments from the Translation War no. 1 focused on mobile apps showed that DeepSeek is the top model for localizing mobile apps into Polish, and Claude for Croatian.

The Intento report highlights that it’s the multi-agent workflow that delivers the best results. Bear in mind that top models constantly get new updates, and their results change. What’s the best varies depending on whether you prioritize translation accuracy, brand voice, terminology consistency, creativity, or privacy constraints. Whatever you choose, don’t forget about the human review, as studies show tone, nuance, and cultural fit still need careful oversight.

So buckle up, because this might be the longest Release Update ever. 😅

⌨️ New CLI features 🔗

The CLI has picked up some new capabilities that were previously only available in the UI. Now your CI/CD or coding agents can simply call Localazy commands to translate on the fly and developers don't have to leave their terminal.

Update to version 2.0.11 to use the new commands.

AI translations 🔗

The localazy translate command provides on-demand, real-time AI translation directly from the command line. Unlike the batch operations, it does not modify any strings stored in your project. It just returns translations synchronously so you can use them in scripts, build pipelines, or one-off tasks.

Translate a literal string and print the result:

localazy translate --from en --to cs --text "Hello, world!"

Translate a batch from a file and store the result as JSON:

localazy translate --from en --to de --input src.json --compact > de.json

Batch operations 🔗

Batch translation operations are now accessible via the CLI as well, giving you the same control over multi-language jobs you'd have in the product. They are processed asynchronously on the server and the CLI starts the operation, polls for progress, and reports the final result once it finishes.

There are three subcommands:

• localazy batch translate generates translations for selected target languages
• localazy batch approve approves waiting versions of translations for a target language
• localazy batch tm applies translation memory from connected projects

All three new commands have various parameters and features that you can use to optimize your workflow.

📬 Localazy API updates 🔗

Two notable additions to the Localazy API:

• You can now translate strings directly without the need to upload them into a Localazy project.
• You can manage source key tags and priority programmatically.

AI Translation endpoint 🔗

You can now get Localazy AI translations directly via the API, without uploading anything into the project. Send any text and get on-brand translations that follow your glossary and style guide.

[POST] /projects/{projectId}/ai

The endpoint above accepts requests with texts in any language and translates those texts into the target language via Localazy AI using the context of the project defined by {projectId}.

Read all the details in the docs.

Source key tags and priority 🔗

Tags and priority on source keys are now exposed through the API, so you can work with them programmatically as part of your workflow.

Read more about the source key endpoints in the docs.

🔑 New API tokens and CLI keys management 🔗

We've redesigned how API tokens and CLI keys work to give you finer-grained control.

CLI keys are still scoped per project and user. Each new key can now be configured to allow or restrict access to branches, format conversions, and other project-level command-line operations.

API tokens follow a similar model. Tokens now come in three permission levels: Read Only, Read/Write, and Translate Only. Translate Only is particularly useful for giving an automated integration just enough access to use the AI translate endpoint without being able to touch anything else.

This makes it easier to follow the principle of least privilege when connecting third-party tools, CI pipelines, or team members who only need partial access.

🛸 Localazy AI suggestions 🔗

Localazy AI now offers its own translation suggestions directly in the editor.

When you open a phrase for translation, you can load a Localazy AI suggestion alongside the other machine translation provider options with a click.

The suggestions are context-aware and use your project's style guide, glossary, notes, comments, and translation memory to stay consistent with the rest of your content.

You can enable or disable the feature per project in your project settings under machine translation options, separately from the rest of the suggestions.

📖 Glossary management revamp 🔗

The glossary has been around for a while, and it was showing its age. We've added an option to import glossary in a CSV or Excel files and rebuilt the management interface from the ground up, because a glossary that's annoying to maintain doesn't get maintained. And inconsistent terminology is one of those translation problems that often goes unnoticed.

The glossary is available when translating strings or reviewing translations in the UI. Matched terms are highlighted and validated for every translation.

Glossary terms are used as context when generating translations with Localazy AI and other machine translation providers that support it.

You can also share glossaries across projects with the Connected Projects feature.

New glossary import option 🔗

You can now import glossary terms in bulk, so you're not stuck entering them one by one if you're migrating from another system or have an existing term list.

Your file will be analyzed and if it’s prepared correctly, no manual column and value mapping will be necessary, but you can always tweak things before you import it into your project.

New table design 🔗

The table view now allows you to see the term in all or just some languages, show or hide attributes, and of course, filter the displayed terms based on your rules.

New glossary term edit screen 🔗

The biggest difference is in how glossary languages and the terms themselves are managed. You don't have to add each translation for each term separately or click between tabs like crazy anymore: it's all neatly organized in one single screen where you can edit whatever you want.

🧳 Improved batch translation 🔗

A few targeted improvements to the batch translation flow.

When you're setting up a batch translation job, the configuration screen now clearly shows in what extent are glossaries and style guides supported by each provider.

You can also select a different language as the source for translation. Previously, batch jobs always translated from your project's default source language. If your favorite provider performs better from English than from your source language, you can now set that up directly instead of working around it.

🌚 Dark mode 🔗

Dark mode is now fully rolled out across the product. It follows your system preference by default, so if your OS sets to dark automatically at dusk, Localazy will match it too. You can also set it manually in your profile menu. Perfect for those late-night sessions when the deadline is getting dangerously close!

Author's note: As you can see, the Localazy website is not yet available in dark mode, so if you love to read our blog during the night, put on some sunglasses! 😎

🔀 Language mapping in integrations 🔗

All Localazy-side integrations now include a language mapping option.

Above is an example of language mapping in a Webflow localization project in Localazy.

Different platforms we integrate with sometimes use inconsistent language codes. Script variants often get dropped, and what Localazy calls zh_CN#Hans might arrive as zh-CN on the other end. Previously there was no clean way to handle this and it was not possible to use some languages in some integrations. Now you are in full control.

💜 Strapi plugin improvements 🔗

Four additions to the Localazy Strapi plugin:

• Incremental translation updates
• Excluding upload of individual items
• Activity logs & troubleshooting bundle for easier debugging

Download only translations with changes 🔗

This was the biggest complaint of some Strapi users with thousands of translations synced between Localazy and their Strapi instance.

The plugin now tracks which translations have been successfully downloaded per language and per key. On subsequent downloads, only keys with newer translations than the last time are processed.

📩 Learn more about how Strapi plugin translation sync works in the docs.

Exclude individual entries 🔗

You can now mark specific entries to be excluded from uploads to Localazy. If you have content that shouldn't go through the translation workflow at all (draft entries, internal notes, or anything not ready for translation) you can exclude it at the entry level rather than having to restructure your content model.

🎬 Learn how to exclude entries from uploading to Localazy.

Activity logs 🔗

The plugin now also has a dedicated Activity Logs section that shows a history of all upload, download, and webhook events. This gives you a clear record of what the plugin has done, makes it easier to track down automation issues, and helps when something behaves unexpectedly.

Troubleshooting bundle 🔗

When a session fails or behaves in an unexpected way, the plugin can now generate a troubleshooting bundle. It's a single zip file that captures everything needed to reproduce the issue. You can share it directly with Localazy support to help us help you.

🗃️ Improvements & fixes 🔗

A few more things worth noting:

• MT service stability: We improved how the machine translation service handles provider-side connection issues, retries, and unexpected responses. Jobs that would previously fail or get stuck are now handled more gracefully.
• Credit transaction sources: The credit transaction overview now identifies more sources, including API usage and AI suggestions.
• Credit reset display: The billing section now shows the amount of credits that will reset alongside the reset date, so you know exactly what's coming back at the start of the next cycle.
• File upload format mismatch detection: When uploading a file in a different format than your source, the upload UI now shows an inline warning rather than failing silently. You can also intentionally upload translations in a different format if your workflow requires it.
• Grouped select menus: Select menus across the product can now display options in grouped sections, making longer dropdowns easier to scan and navigate.
• Trial account credits: Trial accounts now get 2 credits upfront (with the option to purchase more during the trial), rather than being subject to a hard limit for machine translation.
• Language overview refresh: Opening the languages overview now triggers a refresh of project data, so key counts stay in sync with recent uploads and changes.
• Searchable country select: The country field in account settings now uses a searchable dropdown, replacing the native browser select.
• Password requirements: The change password page now shows updated password requirements inline.
• Unsaved changes prompts restored: Browser prompts warning about unsaved changes were missing on certain pages (settings, review screens). These now appear correctly again.
• Translation warning isolation fix: Ignoring a translation warning for one key could incorrectly suppress warnings on other keys until the page was refreshed. Fixed.
• Source key rendering fix: Placeholders and markup-like text inside key names were being highlighted incorrectly. They're now only highlighted when they match an active search.
• Keyboard shortcuts overlay fix: The overlay failed to open when the side menu was collapsed. Fixed.
• Screenshot upload warning fix: An incorrect warning was appearing after screenshots were uploaded. Fixed.
• Copy translations automation setup improvement: To reduce the risk of misconfigured automations, Copy Translations now requires you to pick a source language in the first step of the setup flow, before any other options are configured.
• Various performance and interface improvements across the platform.

🎁 Wrapping up 🔗

That's a lot of ground covered. What update or improvement is your favorite?

As always, if you run into anything unexpected or have feedback, reach out via the in-app chat or drop me a message at petr@localazy.com.

And at first, it worked really well. A few strings go in, translated text comes out, and the natural conclusion is: "We just need to build a simple dashboard to track this, and we're done. Claude can do this overnight!" No new subscription, no procurement, no platform to learn.

Anyone who's spent time with AI coding agents knows how fast you can ship now. It's genuinely possible to build seemingly complex internal tools in an afternoon.

So the question that follows is rational: Why pay for a localization platform when we can build something ourselves? Heck, why pay for any third-party software at all?

👷‍♂️ The appeal of creating your own stuff 🔗

I am not a developer. But I've always liked creating stuff. It all started with me learning Photoshop in the 6th grade of elementary school. Then I started building my first websites in Microsoft FrontPage (IYKYK). Then I learned HTML and CSS (by reading actual books!).

Afterward, I reached the golden age of Bootstrap, and then I finally decided to use WordPress for my clients (still not sure if that was a good idea, but most of the sites still work today). I was using all of these things other people have built to make my life easier, enabling me to create more cool stuff with less time spent on boilerplates.

And so I build things with Claude myself today as part of my work — pricing calculators, API connectors and automations, HTML prototypes to visualize ideas... Things that would require a dev ticket a few years ago, I can now ship myself. But I've always been deliberate about where I stop.

I'd never want to be the one building internal tools available to others in the company, because then I'd have to maintain them based on someone else's needs. I don't want to run another product for end users on top of my actual job.

Most teams starting a DIY localization setup don't have a clear idea of what they are getting themselves into when they build their own tools instead of looking for solutions built and maintained by others.

Yeah, I know, some reports suggest that 35% of US companies have replaced SaaS tools with custom solutions, and 78% expect to build more of their own tools in 2026.

And every time we look for a new tool, I hear colleagues claim: "We can build our own in an afternoon!" Yeah, I know we can, but should we? It was always possible to build our own tools. And the coding agents give us all the power to build more and faster.

So, where is the line between build vs. buy in the age of AI?

🔩 Why the DIY route feels solved today 🔗

The first version is always a breeze. You export some strings, run them through an AI, and the output looks good enough. The casino paid out.

That's not a metaphor I'm using loosely. Working with AI tools has a distinct emotional rhythm — the buildup while it processes, the anticipation before you see the result, the spike when it works. It's engaging precisely because you don't always know if the output will be exactly right, or subtly wrong in a way that won't surface until later. At the prototype stage, it works. You ship it.

What usually happens after the proof of concept is much simpler than a deliberate architecture decision. You need an interface that lets your team edit the strings if the AI does a bad job, so you build it. And now you have a translation tool for your apps. Now marketing wants to localize the website, so you add an integration. Boom, done.

The output gets reviewed by someone on the team and imported back into the product and website. It works, so the conclusion becomes, "we don't need a full localization system." Or, more confidently, "we can just build it ourselves as we go."

Our colleagues spoke with many people at Digifest who were doing exactly that. Excel plus DeepL was common. ChatGPT for translation was common. Custom wrappers, too. Most of them hadn't noticed yet that they were rebuilding localization infrastructure that other companies had spent years stabilizing... just without the reliable parts.

⚠️ Where the prototype stops working 🔗

The first cracks tend to be technical. First, placeholders get corrupted.

Then, plural rules that work fine for English break in Czech, then break differently in Polish, and Arabic is another world entirely.

But the deeper issue isn't technical edge cases. It's quality, context, and consistency.

A word like "Save" seems harmless until it appears dozens of times across your product in different contexts. Without duplicate resolution and terminology control, you end up translating the same thing multiple times: inconsistently, expensively, and incorrectly.

A fluent translation that ignores context looks fine until it's in front of a user who actually speaks that language. AI output can look polished and still be wrong in domain-specific or contextual situations: fluency is not the same thing as accuracy, and in localization, one without the other causes real damage.

By the time the problem surfaces, it doesn't look like a translation problem. The CEO sees revenue dropping in a specific market. Marketing notices conversions are down, and bounce rates are rising. Support gets more tickets from those users. Nobody immediately connects it to a string that got mistranslated two months ago. Each layer of the company sees a different symptom, and the cause stays hidden until someone traces it back. By then, it's already spread.

AI output can look polished and still be wrong in domain-specific or contextual situations. By the time quality and consistency problems surface, the damage is already done

And when it comes to "AI can translate this, we just make an API call, and it's done!" How do you know what to put in the prompt? You are optimizing prompts, burning tokens, and building additional features. ChatGPT doesn't remember how you translated a term last week. So you start building a terminology base for your prompts. Then you need to verify the AI actually used those terms. Then you need someone to check that. "Oh yeah, just one more iteration, boss! We are close to solving it."

Context in localization isn't optional. It includes screenshots, glossary terms, style guides, character limits, tone rules, and previously approved translations.

"Yes, I am on it, I can do this!" Yes, you can. But once you need all of those consistently, you're not solving a translation problem anymore. You're building infrastructure.

And before you know it, one afternoon turns into months of development and then years of upkeep. You've built a context management workflow, a review workflow, and a validation workflow on top of your translation and i18n workflows. All from scratch. And the thing that seemed simple now has layers you didn't plan for.

So you just lost weeks reinventing the wheel. And it's your wheel: every time it breaks, you or your developers have to stop what they're doing and fix it.

🧐 What it actually costs 🔗

We all know context is the king of localization. But there is also another type of context. That one lives in your team's heads, and switching context frequently will kill your productivity. You are going to spend more and more time on building internal tools instead of focusing on what matters. That precious time should be spent solving problems and improving the experience for your customers.

In the end, the tooling might work well enough that nobody replaces it, but it creates constant friction. Every new market means rediscovering which edge cases your setup doesn't handle. Every new team member needs to learn how the system works, so now you are writing documentation as well. And the time is ticking. And the context keeps switching. 🤷

That's easy to overlook when you're weighing the options. But engineering time alone adds up fast. An engineer spending five hours a week on internal tooling at €75–100 per hour is already €1,000–2,000 a month before you count bugs and delays. And I am being optimistic here.

In the end, you might save some money on the license fees. But you give yourself and your developers extra work. And remember, the work is never just “the work”. There are things you cannot even estimate for, and they grow into another project you have to manage. Dave Stewart put it in a pretty fitting infographic. And while it is mostly about agency type of work, it holds true for pretty much any kind of project:

So the developer who tells you they can "prompt it in an afternoon" is wrong. It will eat their time and your budget. Of course, if you are paying hundreds of thousands of dollars a year for a tool that one developer could maintain with AI agents writing the code, go ahead and kill the subscription and devote your own resources to solving it. But I don't think this is true for 99% of the subscriptions you (or we) pay for.

So, are you actually going to save money?

➡️ What you're actually buying when buying software 🔗

With some solutions (and I dare to say, with Localazy especially), you are not buying "Software as a Service" but "Software AND a Service." So when I argue against self-built solutions, I don't lead with features. Everyone can build features.

What I tell people is that buying software means gaining access to the accumulated knowledge of how this problem works. When you arrive at an edge case you didn't anticipate, we've probably already built something to handle it. You don't know what you don't know.

We've helped hundreds of teams work through these exact issues over the years we've been in this business. We also have a team of native speakers just a button away to review your strings, whether they were translated by AI or not.

So you are not buying a fancy UI; you are buying access to someone who already knows where localization tends to break and who devotes all their working hours to solving their customers' localization needs more efficiently than they can themselves. It's really not just about building a tool that moves strings around.

It's the expertise gap you can close only by hitting walls you didn't know existed. The plural rules, the placeholder edge cases, the terminology drift, the review workflow... You rediscover each one in production, usually under pressure. A proper TMS comes with that knowledge built in, at a fraction of the price.

Most companies that reach out to us aren't looking to replace a localization department. They don't have one. They're a product team that started shipping to new markets and realized pretty quickly there's more to it than running strings through an AI. They didn't want to become localization experts. They just wanted their product to work in other languages, and work well enough that users in those markets actually stick around.

There's a type of expertise you only acquire by hitting walls you didn't know existed. A TMS comes with that knowledge built in. If you build your own solution, you have to account with that and the engineering time you'll invest in it

But this whole discourse isn't localization-specific at all. Sanity wrote about the same pattern in the CMS world after a high-profile customer migrated off their platform to markdown files and custom tooling.

Their take: "You can delete the CMS, but you can't delete the need to manage assets, control who can publish what, track changes, and structure your content." Give it six months, and the bespoke tooling grows. Edge cases multiply. Someone needs a feature that wasn't in scope. Same story in a different category.

💬 Ego-prompting is bad for you 🔗

There's another version of this conversation, which, to be fair, we've had more often than we'd like lately. It's with teams already using Localazy who are wondering whether to replace it with something they built themselves now that AI makes that feel more viable.

If that's you, you already know what localization involves. You've already configured your workflows, built up translation memory, and set up your integrations.

The question isn't whether AI makes translation easier. It does. We spend a lot of time on research to get it right as we continue improving Localazy AI (in fact, our dev David has been writing extensively about it). When it comes to AI localization, you will have to write a prompt. But how are you supposed to know exactly what to write in the prompt? Spoiler: "Translate X to Y language" won't work. At Localazy, we are optimizing this all the time, and our AI isn’t just a single prompt: it’s a multi-step reasoning process of which the translation itself is only a small part.

So, it might be worth thinking about what you'd actually be replacing: everything you've already figured out the hard way, every new edge case your custom setup would introduce, and every improvement you won't get because you're no longer subscribed to a product whose entire purpose is to stay ahead of this problem for you.

Going the DIY route doesn't make the problem go away. It just puts you back in the position of having to solve it yourself. That's exactly the point: our team's energy belongs to the product we build for you. We are not vibe-coding a new CRM now just because we can. We are making Localazy better for our clients. So my advice is to kill your ego. You don't have to prove to anyone that you can solve it in a few prompts to save a few hundred dollars per month.

Going DIY doesn't eliminate the localization problem. It just puts you in the position of solving the problem yourself. You have to choose if putting your energy there is worth it

You can build it. Building it is the easy part. Being the person responsible for maintaining it at scale, while the product keeps changing and the edge cases keep accumulating, is a different commitment entirely.

The human species has evolved over thousands of years and has naturally discovered the miracle of the division of labor. Why go against the evolution now by doing everything yourself?

✔️ Conclusion 🔗

Over the past few months, I have had conversations about build vs. buy more often than I would like. Marta from our marketing team kept asking me about this article every two weeks and even hired a writer to help me kick things off.

It turned from an interview into an essay. Then it was rewritten about four times, because each time I talked about it with someone else, I had a new perspective on the problem.

So please, let me know what you think about this in the comments. I am genuinely curious about others' opinions. Only time will tell if I was right.

In Part 1, we set up the foundation for the React multilingual app. Now we move from configuration to a real-world workflow: uploading translations to Localazy, pulling them back into the app, testing the localized UI, and using pseudo-locales for visual QA.

1️⃣ Step 1: Upload translations to Localazy 🔗

To manage translations centrally, we’ll connect our React project to Localazy. This lets us upload our English source file, translate it through the dashboard, and later pull updated language files back into the app.

Log in and get your keys 🔗

Log into Localazy and create a new project:

Give it a name and service details, then click on Create new project:

After creation, Localazy asks how you want to integrate. Select React from the list of integrations:

Localazy will generate setup instructions along with your project keys:

Create a tiny keys file you do not commit:

localazy.keys.json (root)

{ 
	"writeKey": "YOUR_WRITE_KEY", 
	"readKey": "YOUR_READ_KEY"
}

Add to .gitignore:

localazy.keys.json

You’ll use Write Key for uploads and Read Key for downloads.

Upload the English source file 🔗

Run:

npx localazy upload -k localazy.keys.json

Localazy will process en.json and push its contents to your project.

After the upload finishes, open your Localazy dashboard and you should see the keys from your React localization setup complete with the ICU plural message we included earlier.

Add your target languages 🔗

Once your English source has been uploaded, add a target language (for example, French).

Chose a translation engine. Remember that you can fill translations manually or pre-fill them using MT or Localazy AI.

Now, begin your translation:

Localazy handles ICU plural messages natively, so translators see structured plural forms, no raw syntax.

Once translations are ready, we’ll pull them back into the src/i18n folder and React will treat them just like the English file.

2️⃣ Step 2: Download translations back into the project 🔗

With your English source strings uploaded, Localazy will generate translations for every enabled language. Instead of manually creating files like fr.json, we'll simply pull them down using the CLI.

Run the download command:

npx localazy download -k localazy.keys.json

When it finishes, open your src/i18n folder. You should now see fresh language files, something like:

src/i18n/en.json
src/i18n/fr.json // Localazy added this
src/i18n/index.js

React reads these just like the English file, so as soon as translations exist, the language switcher will show real changes in the UI.

Downloading fr.json isn't enough: React must know about it. Update your i18n config to import and register the language:

// src/i18n/index.js
import i18n from "i18next";
import { initReactI18next } from "react-i18next";
import en from "./en.json";
import fr from "./fr.json"; // new file from Localazy

i18n.use(initReactI18next)  
		.init({
		  resources: {
		    en: { translation: en },
		    fr: { translation: fr } // add the language here
		  },
		  lng: "en",
		  fallbackLng: "en",
		});
export default i18n;

If you add more languages later (e.g., Spanish, German, Arabic), import and register them the same way after running localazy download.

3️⃣ Step 3: Test the localized React app 🔗

With English and French files in place, it’s time to verify everything behaves like a real multilingual interface rather than a static demo.

Start the dev server if it's not running:

yarn dev

The app should load in English by default. Click on the language switcher:

<button
  onClick={() => {
    i18n.changeLanguage(i18n.language === "en" ? "fr" : "en");
  }}
>
  {t("language")}
</button>

When you switch to French, the heading, button label, and any other localized UI elements should update immediately with no page refresh as in the fr.json.

Test ICU plurals in the real UI 🔗

Now that our React localization setup switches languages correctly, let’s verify that plural rules work as expected. We already defined the ICU plural message in both languages:

en.json

"items": "{count, plural, one {# item} other {# items}}"

fr.json

"items": "{count, plural, one {# élément} other {# éléments}}"

To test it, we need a dynamic number. For now, we’ll simulate that with a temporary component state.

Add this to App.jsx:

import { useState } from "react";

Then inside the component:

const [count, setCount] = useState(1);

Render the plural message:

<p className="mt-4 text-gray-700">
  {t("items", { count })}
</p>

Add simple buttons to change the count:

 <div className="flex gap-3 mt-3 justify-center">
     <button onClick={() => setCount((c) => Math.max(0, c - 1))} className="text-blue-950">-</button>
     <button onClick={() => setCount((c) => c + 1)} className="text-blue-950">+</button>
 </div>

When you test it, you will see something like this:

This is because right now i18next is treating that whole ICU string as plain text. We never told i18next “this is ICU syntax, please parse it,” so it just prints the raw message. By default, i18next does not understand ICU format. It has its own pluralization system and to use ICU, you need an extra plugin.

There are two ways to handle this:

1. The first method is to use i18next’s default plural handling instead of ICU (so no need of a plugin):

src/i18n/en.json

{
  "items_zero": "No items",
  "items_one": "1 item",
  "items_other": "{{count}} items"
}

src/i18n/fr.json

{
  "items_zero": "Aucun élément",
  "items_one": "1 élément",
  "items_other": "{{count}} éléments"
}

Then in React, call:

{t("items", { count })}

i18next will automatically map:

• count = 0 → items_zero
• count = 1 → items_one
• count > 1 → items_other

2. The second method is to keep the ICU and teach i18next to understand it. This guide uses the second method. First you need to install i18next-icu and intl-messageformat:

yarn add i18next-icu intl-messageformat

i18next-icu teaches i18next how to interpret ICU messages. It hooks into i18n processing and says:

"Instead of treating this as plain text, handle it as an ICU-formatted translation."

intl-messageformat library is the actual ICU parser. It looks at the ICU expression and decides which branch to output. Localazy supports ICU messages when "features": ["plural_icu"] is enabled, which we did ealier. Installing these packages ensures the app behaves the same way Localazy interprets translations, so translators don’t see one format in Localazy and another in the UI.

Next, we'll update the i18n initialization so ICU handling is part of the pipeline.

Open src/i18n/index.js and make sure it looks like this:

import ICU from "i18next-icu";

...

i18n
  .use(ICU) // enable ICU message formatting
  .use(initReactI18next)
  .init({
    // same config…
  });

The order matters: ICU() has to run before initReactI18next, so messages are parsed correctly before they reach React.

Now restart your application and test both the English and French ICU messages, along with the counter, to make sure everything behaves exactly as described.

4️⃣ Step 4: Enable pseudo-locale for visual QA 🔗

A pseudo-locale works like a visual stress test for your UI. It takes your English strings and transforms them.

For example:

Welcome to the React localized app becomes:

Ŵēłćōṁē ţō ţĥē Ŕēąçţ ļōćąłįżēđ ąpp

You can still kind of read the text if you squint, but everything looks a bit off. Some words get weirdly stretched out, random accents show up everywhere, and the whole shape of each sentence changes.

When you render your app with that locale, you can immediately spot buttons where text is cut off or suddenly cropped, labels that overflow their containers, texts or layout that only works well in English, and places where you accidentally concatenated strings instead of using proper keys.

It’s a very handy tool in a React localization workflow before real translators even touch the strings.

Create a pseudo-locale in Localazy 🔗

Open your Localazy project > Click on Add New Language.

Instead of choosing a real language, scroll to Custom Locales and create one manually.

Once the language is created, we need to map it to the code used in our app. In Localazy, then add a language alias so xxd corresponds to our internal pseudo-locale code (qps):

{
  "upload": {
    ...
  },
  "download": {
    "files": [
      {
        "output": "${path}/${lang}.json"
      }
    "langAliases": { "xxd": "qps" }
    ]
  }
}

xxd is the custom locale code created in Localazy and qps is the pseudo-locale code used inside React. This tells Localazy: "Whenever you download xxd, output the file under the name qps.json."

Note that Localazy does not automatically generate pseudo-localized text. It does support pseudo-locales as a testing concept (a locale that applies visual changes like accenting characters and expanding text). We'll add the pseudo-localized strings manually. For example, we translate English by adding accented characters like this: Ĕńĝłįšĥ.

We'll do this for the rest of the strings to translate.

Download pseudo-locale into your project 🔗

Run:

npx localazy download -k localazy.keys.json

Now check your translation directory:

src/i18n/
 ├─ en.json
 ├─ fr.json
 └─ qps.json    // pseudo-locale for visual testing

Register the pseudo-locale in your React i18n config 🔗

Add it like any other language:

import qps from "./qps.json";

i18n.init({
  resources: {
    en: { translation: en },
    fr: { translation: fr },
    qps: { translation: qps } // add this line
  },
  lng: "en",
  fallbackLng: "en"
});

Update the tour button tag to select tag:

<select
  value={i18n.language}
  onChange={(e) => i18n.changeLanguage(e.target.value)}
  className="mt-4 bg-amber-600 p-3 rounded-md text-white"
>
  <option value="en">{t("lang.en")}</option>
  <option value="fr">{t("lang.fr")}</option>
  <option value="qps">{t("lang.qps")}</option>
</select>

Then test.

Note: The pseudo-locale is meant only for development, not production. It helps you visually catch layout issues early by exaggerating text length, accents, and spacing, but it isn’t a real language and shouldn’t be shipped to end users or exposed in production builds

5️⃣ Step 5: Sync translations as the app evolves 🔗

Once localization is set up, you’ll repeat the same workflow whenever you add or change text in the app. Localazy keeps your translations aligned with your source language instead of making you track changes manually.

Update your source language 🔗

Make changes in src/i18n/en.json. Example:

"invoice_total": "Total amount"

Upload changes to Localazy 🔗

npx localazy upload -k localazy.keys.json

Localazy marks new or changed keys automatically so translators know what to update.

Translate in Localazy 🔗

Open the dashboard and fill in translations for other languages (fr, qps). ICU messages stay structured, so plural rules are handled cleanly.

Download updated translations 🔗

npx localazy download -k localazy.keys.json

This refreshes the files:

src/i18n/fr.json
src/i18n/qps.json

Test changes in the UI 🔗

Restart if needed:

yarn dev

Switch languages and verify that the translations render correctly.

Workflow summary 🔗

Update en.json → Upload → Translate → Download → Test

🔍 Quick recap 🔗

In this guide, we enabled ICU plural rules, uploaded and synced translations with Localazy, and introduced a pseudo-locale for visual QA. Finally, we prepared the setup for production, including fallback languages, safe handling of pseudo-locales, and caching considerations. You can work through the full code of this guide in this Git repository.

🏁 Best practices to consider for production 🔗

Now that your app supports multiple languages, make sure it behaves correctly when deployed. The goal here is to make your localization setup stable, predictable, and production-safe.

1. Keep the pseudo-locale in development only 🔗

Pseudo-locales are helpful for visual QA, but they’re not real languages, so they shouldn’t be exposed to end users. You can simply hide the option in production:

{process.env.NODE_ENV !== "production" && (
  <option value="qps">Pseudo</option>
)}

This keeps the testing locale available during development without affecting real users.

2. Use a fallback language 🔗

Missing translations shouldn’t leave blank UI elements. A fallback ensures the app always displays meaningful text when a key isn’t available in another locale:

fallbackLng: "en"

This is standard practice with i18next and prevents unexpected gaps during incremental localization.

3. Bundle translations locally vs. dynamic delivery 🔗

For this guide, translations are bundled as static JSON:

src/i18n/en.json
src/i18n/fr.json

This is ideal for static hosting, offline mode, and fast load times. Localazy also supports more dynamic delivery patterns (for example, integrating downloads into CI/CD or backend workflows) if you need more frequent translation updates later.

4. Handle caching appropriately 🔗

If you're hosting translation files on a CDN or static host, you may enable caching for faster loads. Just remember: long-lived caching improves performance, but you should clear caches when translations change. This avoids outdated text appearing in production.

Final launch checklist 🔗

Before shipping:

• ☑️ Make sure language switching updates the UI instantly, with no page reload
• ☑️ Confirm all visible UI strings have French translations
• ☑️ Hide the pseudo-locale option in production builds
• ☑️ Test that plurals and ICU rules behave correctly in both languages
• ☑️ Verify the fallback language catches any missing keys gracefully

🚀 Go build something multilingual 🔗

You now have i18next parsing translations at runtime, Localazy keeping your locales in sync, ICU plurals handling the edge cases, and a pseudo-locale catching layout issues before real translators ever see your strings. Moving forward, you can add a new locale, push a key update, automate the sync in CI... It all fits into the same cycle you've already built.

With that, you're ready to ship!

It's the same thing I keep seeing everywhere right now.

Everyone is sprinting toward "more and faster" with AI. Content teams are shipping at a pace that would have been unthinkable two years ago. And the output looks... fine. It's polished, and grammatically correct, and uses all the right UX patterns.

Minor issue, though. It doesn’t do what it’s supposed to. It doesn't move users forward, reduce confusion, or build the kind of trust that makes someone feel safe entering their credit card number. It just... exists. Filling space. Looking professional.

And I kept thinking: "I’ve been here before." I recognize that tree. I've been watching it for years, actually. Just in a different industry. It’s what happens when you scale content faster than you scale judgment.

🫢 Spoiler: It’s localization 🔗

Localization teams have been dealing with this exact problem (scaling content without losing quality) for a very long time. They've been working with machine translation, managing thousands of strings across dozens of languages, and building systems to make sure nothing breaks when you're shipping at scale.

They've figured out, through years of painful trial and error, how to move fast without causing chaos. To use machines for production while keeping humans in the loop for judgment, and define "quality" in a way that's actually measurable.

UX writing teams are going through the exact same growing pains right now. Not identical (the details are different), but the pattern is the same. We’re pressured to produce more, faster, with automation involved, while somehow maintaining quality.

With AI, UX teams are experiencing the exact same growing pains that localization teams had to deal with for years. They're pressured to produce more content faster without losing quality

So I started pulling the thread. What can UX writers actually learn from the localization playbook💭

Turns out: quite a bit.

💭 What’s your Why? 🔗

This is the question missing from most workflows. Whenever I work with teams that are frustrated with their AI output, the conversation usually goes something like this:

"The AI keeps generating generic copy."

"What did you ask for?"

"...We told it to write a confirmation screen."

Right. And that's the problem. "Write a confirmation screen" is a task, not a goal. The AI did exactly what you asked: it wrote a confirmation screen. It doesn't know why that screen exists or what it's meant to achieve.

Localization teams learned this lesson early, because when you're sending a string to be translated into 30 languages, "just make it sound good" doesn't cut it. You have to specify: What is this string doing? What action should the user take after reading it? What's the emotional register? What are the constraints? Because without that context, you get 30 technically correct translations that are functionally useless.  

So before we talk about frameworks or QA checklists, here's the foundational question:

What is your content meant to do? 🔗

✔️ Maybe the job is to get the user to the next step as fast as possible —minimal friction, maximum clarity. That's your checkout flow, your setup wizard, your "You're almost done" screen.

⚠️ Or reduce risk — payments, security, privacy, anything regulated. Here, accuracy and honesty outweigh friendliness every time.

🤝 But perhaps it’s to build trust — set expectations, explain why you're asking for something, reassure without overpromising.

👩🏻‍🏫 It could also be to teach — help a user understand a complex system they've never used before.

🛟 Possibly, it's to reduce support load — prevent the confusion that generates tickets.

🎁 Or (and this is valid too) the job is to create a pleasant experience. Delight. Warmth. Personality.

Pick one. Then everything else gets easier.

You do have to start with something. Otherwise, you end up with generic copy that does nothing. The AI is happy to write you a friendly, trustworthy, actionable, educational, delightful confirmation message

Turning the goal into something you can actually check 🔗

Once you know the job, something interesting happens: "quality" stops being a vibe and starts being something you can measure.

This sounds obvious, but think about how content review usually works in practice. Someone reads it. They go, "Hmm, I don't love the tone." Someone else says, "I think it's fine." A third person suggests making it "more human." Everyone has a slightly different definition of "good," and the conversation goes in circles until the most senior person in the room wins.

Localization teams can't afford this. When you're reviewing translations at scale, "I don't love the tone" doesn't help the translator in Japan or the reviewer in Brazil. You need specific, checkable criteria. So they define quality signals upfront:

• If the goal is fast action, the signals are: clarity, brevity, a strong next-step cue, no fluff. You can check each one. Did the user understand what to do? Was there anything unnecessary? Was the next step obvious?
• If we’re trying to grow trust, the signals are: accuracy, honesty, no overpromising, a calm and respectful tone, and clear boundaries. Again, checkable. Did the copy promise something the product can't deliver? Did it sound like a robot trying to be reassuring?
• If it’s delight we’re after, the signals are: personality, warmth, lightness (but still no ambiguity, because funny copy shouldn’t confuse people.)

See the pattern? The goal defines what "good" means. Without a goal, you're just arguing about taste. And taste doesn't scale.

Use the goal to guide AI — don't just review after the fact 🔗

In localization, we learned from experience that you need to provide context and information before the work happens. Screenshots, so the translator can see where the text appears. Character limits, so they don't write something that breaks the layout. A glossary, so they use the right terms. Tone guidelines, so they match the brand. Notes about the user's emotional state at this point in the flow.

All of this doesn’t exist because loc teams are type A (even though, you know… We are ?). But because they’ve learned, over years of expensive mistakes, that you can't review quality into a process. You have to build it in from the start.

Same principle applies to AI. If you want AI to produce content that actually works, the goal has to be part of the input:

• What is this content supposed to achieve?
• Where does the user see it? What's the screen, what's the state, what just happened?
• What terminology is required? What's forbidden?
• What claims are we allowed to make? What's off-limits?
• What does success look like?

The more context you provide upfront, the less you have to fix after. Localization teams have known this for decades. UX writing teams are just discovering it now.

🤔 Why now? 🔗

Let's zoom out a bit. Why are UX writing teams suddenly struggling with quality at scale?

Because the ground shifted. And it shifted in ways that localization teams will find very, very familiar.

(P.S. There are also solutions coming up, promise!)

Shift 1: Scale forces you to build content ops 🔗

There was a time, not that long ago, when UX copy was a handful of carefully crafted strings, written by one person, who maybe got it reviewed and maybe didn't.

That time is over. In any product of meaningful complexity, content is now a system. You have hundreds or thousands of strings, multiple surfaces, multiple user states, and multiple teams writing copy at the same time, sometimes for the same flow. You need organization, versioning, ownership, and some way to find "that error message we wrote for the billing screen six months ago."

Localization teams have lived in this world forever. Every release is many strings, multiplied by many languages, multiplied by many contexts. They had to build content management systems because without structure, nothing wouldn't ship correctly. UX writing is hitting the same wall, and the teams that don't build ops will drown in inconsistency.

Shift 2: You don't fully control production anymore 🔗

This is the big one. Localization has worked alongside machine translation for decades. Not happily, not always smoothly, but they've done it. They learned to accept partial automation and shift their effort toward guidance, review, and risk management. The machine does the heavy lifting. The human does the judgment.

UX writers are learning this lesson now, but for creating content. AI is now writing the original strings, and that means you are no longer the person who makes every sentence by hand.

It’s a fundamental shift in where your expertise matters. You're moving from craftsperson to editor, architect, quality controller... but your value is still in knowing which words are right.

Shift 3: Content has to fit into automated workflows 🔗

Localization was historically the bottleneck. "We can't ship until the translations are done." So loc teams did something smart: they built themselves into the pipeline. Strings are treated as artifacts, managed the same way you manage code.

This happened, obviously, because manual handoffs don’t scale. "Hey, can you review this doc? It's in the shared folder somewhere" — that doesn’t work when things need to happen so quickly.

UX writing is being pulled into this same reality. Content can't be the last-minute manual step that happens after design is "done." It needs to be part of the system: versioned, tracked, automated where possible, reviewed where necessary.

Automation, growing complexity, and a considerable shift in production agency are forcing UX writers to design QA-tracking systems that scale

Shift 4: Automation makes context and QA non-negotiable 🔗

When a human writes every sentence, you can rely (to some extent) on their judgment. They've seen the screen, know the product, and can make reasonable assumptions.

When a machine writes sentences, or when content moves through automated pipelines, none of those assumptions hold. The machine doesn't have judgment (not really).  So you need to make the context explicit, and put the guardrails in place before production. You also need QA gates that catch problems systematically.

Localization teams have long implemented these: from pseudo-localization to QA steps, glossary enforcement, automated style checks, and more. All of it exists because "we'll review it later" doesn't work when you're shipping in 30 languages at once, and it doesn't work when AI is generating content for 30 screens at once, either.

✍️ The practices worth stealing 🔗

Okay. So the problems are similar. What about the solutions?

Here's what I'd take from the localization playbook and apply directly to UX content in the AI era.

Treat copy like a product asset 🔗

Localization teams assume every string will have to be reused, referenced, versioned, and audited, because it will be. UX copy should get the same treatment. If you can't find the copy you wrote six months ago, if you don't know which version is live, if there's no source of truth, you have a problem that will only get worse with AI in the mix.

Separate fluency from correctness 🔗

This is maybe the most important one. AI is fluent. That's what it's good at. It produces text that reads smoothly, sounds professional, and uses appropriate vocabulary, but fluency is not the same as correctness. A sentence can be perfectly fluent and completely wrong. It can sound confident while making a promise the product can't keep.

And the reverse is true too: something can be technically correct but still not fluent (awkward, stilted, or just not how people actually speak). That “correct-but-unnatural” copy can be just as damaging, because users have to work harder to parse it and that ends up eroding trust.

Make quality operational 🔗

This means: define the checks. Assign owners. Build gates. "Quality" can't live in one person's head or depend on whoever happens to review the PR. It needs to be a process that works even when your best writer is on vacation.

This also means you'll have to...

Build guardrails that scale 🔗

Just like localization teams maintain extensive glossaries and style guides per language, per market, and per brand, UX teams should maintain them per product, per flow and screen and state.

Design feedback loops 🔗

When a localization error makes it to production, a good loc team figures out why the system let it through and update the guidelines, the glossary, the review process, or the QA checks so it doesn't happen again. When AI-generated content fails in production, the same approach applies. You want to ask yourself: what's missing from the prompt, the guidelines, or the review process that allowed this🤓

🤓 Five checks before anything ships 🔗

Check 1: Is the meaning correct? 🔗

What to look for:

• Intent drift — did the AI "polish" away a crucial detail?
• False confidence - does the copy state something as fact that's actually uncertain?
• Hallucinated specifics - did the AI add numbers, timeframes, or promises that weren't in the brief?

In a fintech flow I wrote recently, the users could request money from a group of people, but a tiny AI “fluency” tweak almost broke things. The intended instruction was for people to be able to choose the sum that’ll be requested of each group member (so 10 people means $500 total). But the rewrite “Charge $50 from everyone” was too vague, and sounded like the $50 was the total number. People would have, naturally, gotten confused.

Check 2: Does it drive the right next step? 🔗

What to look for:

• Is the next action obvious? Can the user tell what to do without thinking?
• Is there ambiguity? Could "Submit" mean two different things in this context?
• Is there a dead end?

Look at the two versions of this travel app empty state. The version on the left is poetic, sure, but the user is left floating. The version on the right is clear, inviting, and the button says exactly what to do.

Check 3: Does it build trust (or at least not damage it)? 🔗

What to look for:

• Overpromising
• Robotic reassurance — "We apologize for the inconvenience" (nobody feels better reading this)
• Patronizing tone — "Don't worry!" (I wasn't worried until you told me not to worry)
• Missing accountability — something went wrong and the copy doesn't acknowledge it

Look how the version on the left tries to soothe with generic reassurance, but it feels corporate and bland. While the one on the right candidly states what happened in plain language, sets expectations for what is next, and gives the user a clear, doable action.

Check 4: Does it fit the context? 🔗

Users don't read copy in a vacuum. They read it mid-task, mid-frustration, mid-decision... The screen, the user's state, what just happened, what's about to happen: all of that shapes whether copy lands or falls flat.

What to look for:

• Screen mismatch — the tone is wrong or the wording isn’t specific enough
• State blindness — the copy assumes things about the user that aren’t correct
• Cultural assumptions — the copy uses idioms, date formats, or references that don't travel

Notice how the screen on the left could be plonked literally anywhere, but the one on the right is fully immersed in the flow (and it helps users place themselves within that context).

Check 5: Does the user understand why they should care? 🔗

AI defaults to company-facing language because that's what most of its training data looks like. It usually feeds from marketing pages, press releases, and feature announcements, so it produces copy that talks about the product instead of talking to the user.

Look at these two screens for an EV charging app. On the left, it’s the company admiring itself in the mirror. Not a single word answers the user's actual question: "Where can I charge my car?" But on the right, every line is about what the user gets.

👩🏻‍💻 How to actually do this (starting tomorrow morning) 🔗

I'm not going to pretend this is a weekend project. Building a real quality system takes time. But to start seeing results, you just need a few things in place, and you need to be willing to iterate.

Here's the minimum viable version:

1. Write down the goal for each screen 🔗

Yes, just add a line in the spec doc: "The checkout confirmation screen's job is to reassure the user that payment went through and tell them what happens next." That's the brief.

2. Create a short do/don't list 🔗

What your content should always do (always name the next step, never promise specific timelines unless confirmed). What it should never do (no exclamation marks in error messages, no "we" in legal contexts, no superlatives without proof). Keep it short so you can manage it.

3. Set up a glossary 🔗

In the same way that it's used in localization, it should contain your core terms that have to stay consistent across every screen, every language, and every AI-generated variation.

4. Add one QA step 🔗

Before any AI-generated copy ships, one person runs the five checks.

5. Start a failure log 🔗

When something makes it to production that shouldn't have, write down what broke. Was the goal unclear? Perhaps a glossary term was missing? Did the prompt lack context? Update the guidelines, the glossary, or the prompt accordingly.

That's the starter kit. And I promise you: it’s going to be the first step in an extremely valuable journey.

🧱 What you'll build in this tutorial 🔗

We’ll combine i18next (the translation engine) with react-i18next (the React bindings) to handle text in the UI. Then plug in Localazy to manage your translation files, upload new keys, and download translated JSON back into your project. This guide is split into two parts:

• 🏗️ Part 1: Foundations. Set up your React project, configure i18next, handle missing translations, and wire up a language switcher.
• 🌎 Part 2: Full translation workflow. Integrate Localazy, manage the translation workflow, add pseudo-locales for testing, and use ICU pluralization for dynamic content.

You’ll build a small, focused example: a React app with text rendered via react i18n using i18next, a simple language switcher (English and French). We will also have a basic ICU-style plural message (“1 item” vs “5 items”). And finally, a repeatable React localization workflow using Localazy’s upload/download commands. The goal is not a fancy UI, but a solid, realistic foundation you can reuse in your own projects.

🧑‍💻 Who this guide is for 🔗

This guide is for developers who want to translate a React app without manually copying JSON files around, and for developers who want to use React internationalization patterns that scale. It is also handy fo anyone who wants to integrate Localazy with React as part of their build and deployment process.

You don’t need prior i18n experience, but you should be comfortable with basic React (components, props, hooks), Node.js and yarn, npm or pnpm, and running commands in your terminal.

📋 Requirements 🔗

Before you start, make sure you have:

• Node.js and a package manager (npm, pnpm, or Yarn) installed.
• A recent React toolchain (we’ll use Vite in this guide).
• A free Localazy account with access to your project’s write/read keys.

The steps below walk you through setting up a complete Localazy translation workflow in your React application. Follow along carefully to make sure each piece connects correctly before moving to the next.

⚡ But first: choose a build tool 🔗

React can be initialized in different ways depending on your stack: Create React App (CRA), Next.js, Remix, Vite, and others. For this guide, we'll use Vite — it boots faster than CRA (which is now deprecated), has a simpler config, works well with modern ES modules, and keeps the setup minimal so we can focus on localization rather than boilerplate.

👉 If you'd like to explore a different i18n library, we also have a guide using LinguiJS and Localazy

1️⃣ Step 1: Create the project 🔗

Let’s scaffold a new React project using Vite. Run this command in your terminal:

yarn create vite react-localized --template react

This generates a minimal React project in a folder named react-localized with React + JSX enabled. No extra dependencies, dev server ready.

After creation, move into the folder and install packages:

cd react-localized
yarn install

Now you can start the dev server:

yarn dev

You should see Vite’s default React starter running at http://localhost:5173.

Project structure overview 🔗

This is the complete structure. We will build it progressively throughout the guide.

react-localized/
├─ public/
├─ src/
│  ├─ assets/
│  │  └─ i18n/
│  │     ├─ en.json
│  │     ├─ fr.json
│  │     ├─ qps.json
│  │     └─ index.js
│  ├─ App.jsx
│  ├─ App.css
│  ├─ main.jsx
│  └─ index.css
├─ .gitignore
├─ eslint.config.js
├─ index.html
├─ localazy.json
├─ localazy.keys.json
├─ package.json
├─ tailwind.config.js
├─ vite.config.js
└─ yarn.lock

The most important directory here is src/assets/i18n/. This is where all translation files live (en.json, fr.json, qps.json) along with the index.js file that initializes i18next. Everything related to localization stays in this folder so translations are easy to manage and version.

At the root, localazy.json defines how translations are uploaded and downloaded, while localazy.keys.json contains your API keys (excluded from version control). The vite.config.js and tailwind.config.js files ensure the build pipeline and styling work correctly. Finally, main.jsx initializes React and imports the i18n config so translations load automatically at startup.

Before adding translations, we’ll create a dedicated folder for localization files.

Create the i18n folder 🔗

Inside the src directory, create a new folder named i18n:

src/i18n/

This folder will hold en.json (your source language, which you'll later upload to Localazy), any additional language files downloaded from Localazy, and the index.js file where we'll write the i18next config. Nothing goes inside it yet. This step just defines where all localization-related files will live.

2️⃣ Step 2: Install dependencies 🔗

Install i18next and react-i18next 🔗

You need two translation libraries: i18next, the translation engine that handles all the i18n heavy lifting, and react-i18next, which hooks it into React via the useTranslation() hook. Install both with:

yarn add i18next react-i18next

Install Localazy CLI 🔗

Localazy will manage the upload and download workflow for your JSON translation files. Install it as a development dependency so you can run it through npx during the build process:

npx localazy upload
npx localazy download

You will set up the configuration file later, after we create the base translation files.

3️⃣ Step 3: Configure Localazy 🔗

Localazy needs a config file at the root of your project to understand the structure, what to upload, where to place translated files, and which features to enable.

Create the localazy.json file 🔗

Localazy needs a config file sitting right in the root of the project — otherwise it has no idea what to upload, where to dump the translated files, or which options you actually want turned on (like ICU features).

Create a new file at the project root:

localazy.json

Start with a minimal structure:

{
  "upload": {
    "type": "json",
    "files": [{}]
  },
  "download": {
    "files": [{}]
  }
}

You will configure upload and download paths in the next steps.

Add upload settings 🔗

Since English is our base language and we're storing language files in src/i18n, we'll point Localazy to en.json. Update the upload section like this:

{
  "upload": {
    "type": "json",
    "files": [
      {
        "pattern": "src/i18n/en.json",
        "lang": "en",
        "path": "src/i18n"
      }
    ]
  },
  "download": {
    "files": [{}]
  }
}

This means that, when you run npx localazy upload, Localazy will push en.json as the source translation file.

Add download settings 🔗

Now we need to tell Localazy where to place downloaded translations. Since new locales should appear alongside en.json, we'll map each language to a file named after its code (fr.json, es.json).

Update the download section like this:

{
  "upload": {
    "type": "json",
    "files": [
      {
        "pattern": "src/i18n/en.json",
        "lang": "en",
        "path": "src/i18n"
      }
    ]
  },
  "download": {
    "files": [
      {
        "output": "${path}/${lang}.json"
      }
    ]
  }
}

Enable ICU plural parsing 🔗

If your translation files include ICU-style plural messages like:

"{count, plural, one {# item} other {# items}}"

Localazy needs to know this so it can parse the message correctly and present plural fields properly to translators. Add this to your localazy.json:

{
  "upload": {
    "type": "json",
    "features": ["plural_icu"], // Add this
    "files": [
      {
        "pattern": "src/i18n/en.json",
        "lang": "en",
        "path": "src/i18n"
      }
    ]
  },
  "download": {
    "files": [
      {
        "output": "${path}/${lang}.json"
      }
    ]
  }
}

Without this, Localazy treats the plural string as plain text and translators see a raw ICU string instead of structured plural forms, which leads to formatting errors down the line. We'll create our first ICU plural example in the next step when we add keys to en.json.

Now that the integration part is ready, we will create the actual translation file that the React app and i18next will use.

4️⃣ Step 4: Add base translation files 🔗

As we mentioned earlier, English will be our base language and you will later pull additional languages from Localazy rather than creating them manually.

Create the English source file 🔗

Create the first translation file:

src/i18n/en.json

Inside, add a few keys to test basic React i18n behavior:

{
  "welcome": "Welcome to the React localized app",
  "language": "Langue",
  "items": "{count, plural, one {# item} other {# items}}"
}

This gives us enough content to verify that translations load correctly in React, that ICU plural formatting works with i18next, and that Localazy parses plural messages correctly after upload.

We're not creating any translated files yet. Localazy will generate them automatically once we upload this English file, add translations in the dashboard, and pull them back into the project. When that happens, you'll see new files appear alongside en.json, such as fr.json for French or qps.json for pseudo-localization.

5️⃣ Step 5: Initialize i18next in React 🔗

With the translation files in place, it's time to wire up i18next and connect it to React.

Create the i18n configuration file 🔗

Before React can read translations from en.json, we need to configure i18next and connect it to React through react-i18next. Create a dedicated file inside the i18n folder:

src/i18n/index.js

Add the initial configuration:

import i18n from "i18next";
import { initReactI18next } from "react-i18next";
import en from "./en.json";

i18n
  .use(initReactI18next)
  .init({
    resources: {
      en: { translation: en }
    },
    lng: "en",
    fallbackLng: "en",
    interpolation: {
      escapeValue: false
    }
  });

export default i18n;

This file loads the English translations, registers the React bindings, and sets English as the default and fallback language. We’ll add more languages here once Localazy downloads additional JSON files.

Import the i18n config in the React entry file 🔗

Now that the i18n configuration exists, we need to make sure it loads before any components render. Open:

src/main.jsx

Add this in the import section:

import "./i18n";

You don’t need to call anything explicitly, since just importing the file initializes i18next and attaches the React bindings so that components can use translations.

At this point, the app has a working translation system, even though we’re only loading English. Nothing will change visually yet because we haven't replaced any hard-coded text with translation calls, but the foundation is set.

Use translations inside components 🔗

Now that the i18n setup is loaded globally, we can start replacing hardcoded strings in components with real localized text. The react-i18next library provides a useTranslation() hook that gives access to the t() function, which retrieves values from en.json.

Open src/App.jsx and update it like this:

import { useTranslation } from "react-i18next";

function App() {
  const { t } = useTranslation();

  return (
    <div className="p-6">
      <h1>{t("welcome")}</h1>
    </div>
  );
}

export default App;

The text is now coming from the translation file instead of being typed manually. As you continue adding UI, you’ll replace normal strings with calls like t("language") or t("items", { count }) once pluralization comes into play.

This verifies that our React localization setup is actually working before we move on to language switching and syncing translations with Localazy.

Add a simple language switcher 🔗

To make the app multilingual rather than locked to English, we need a way to switch languages at runtime. i18next exposes a changeLanguage() method, which we can call from any React component.

For now, we’ll create a very simple toggle just to verify that switching works once additional language files are available.

Add this to src/App.jsx, below the useTranslation() hook:

<button
  onClick={() => i18n.changeLanguage("fr")}
  className="mt-4 bg-amber-600 p-3 rounded-md"
>
  {t("languange")}
</button>

Make sure to import i18n at the top:

import i18n from "./i18n";

Right now, switching to "fr" won’t change anything yet because the French file hasn’t been generated. Localazy will handle that later. But wiring the switcher now helps us immediately verify translations once they download.

As the UI grows, you'll replace this button with a select, but this minimal setup is enough to confirm the React localization workflow is working.

➡️ What's next? 🔗

You've just laid the foundation of your React localization setup: i18next is wired up, English translations are loading, and a language switcher is ready to go. That's the hard part done.

In Part 2, we'll bring Localazy fully into the picture. You'll upload your English strings, manage translations in the Localazy dashboard, pull translated JSON files back into the project, add a pseudo-locale for visual QA, and handle ICU plurals for dynamic content. See you there! 👋

For your app UI, web copy, or help articles (content that changes over time, needs version tracking, and benefits from a translator or reviewer taking a careful look) that process exists for good reason. String management gives you control, history, and accountability.

But not all content needs that. An e-commerce catalog with tens of thousands of products, user reviews coming in from around the world, push notifications that need to go out in every market at once... For this kind of content, the overhead of a managed workflow is unnecessary. One-and-done translations don't always need to come through a TMS.

The Localazy AI Translation API is built for exactly this situation. And within your implementation, you don't really have to lose human control either. Read on to learn what the new Translation API can do and how to use it.

🧐 What is it? 🔗

It's a single API endpoint that lets you translate your content programmatically within the context of your Localazy project using Localazy AI.

You send a POST request with your source content, specify the source and target language, and get back translations in the response — no file uploads, no project sync, no waiting.

curl --request POST \
  --url https://api.localazy.com/projects/{projectId}/ai \
  --header 'Authorization: Bearer {{token}}' \
  --header 'Content-Type: application/json' \
  --data '{
    "from": "en",
    "to": "cs",
    "items": [
      {
        "key": "btn_submit",
        "source": "Submit",
        "comment": "Button label for form submission"
      },
      {
        "key": "welcome_message",
        "source": "Welcome back, %s!",
        "lengthLimit": 50
      }
    ]
  }'

In the background, the Localazy AI uses your project's glossary, style guide, and other context cues to keep the output consistent with the rest of your translations managed on the platform.

Some technical details:

• Localazy Translation API handles up to 32 items per request (including plural forms).
• It accepts per-string comments to help the AI engine understand what it's translating.
• If Localazy AI is unavailable for any reason, you can also configure a fallback to translate content using Google Translate or DeepL at the request level.

🧩 What does it change for you? 🔗

The Translation API allows you to implement Localazy AI translations as part of your application logic, without requiring the content to go through the TMS first.

With a standard localization workflow, strings need to exist in a source file, be uploaded, translated, reviewed, and pulled back before they can go anywhere. For content that benefits from that cycle, it's the right approach. But for content that's generated continuously, published in bulk, or time-sensitive, building a round trip through a TMS into your pipeline creates friction that serves no one.

Generic machine translation APIs give you a translation. The Localazy AI Translation API gives you a translation that understands your project. It has access to your glossary, so the terminology stays consistent across all requests. It also applies your style guide, so the output matches the register and tone of the rest of your content and communications. For teams that have already done the work of setting up a Localazy project, that context comes along for free.

And the additional note or comment you can pass with each request shapes the output in ways that a traditional machine translation can't match.

🕹️ How does it work? 🔗

The API uses Localazy AI as the primary translation engine in the same way you use it to power automated translations across your projects. What makes it more than a generic AI translation call is the context it draws on. When you make a request, the engine has access to your project's glossary and style guide.

Say you're translating a push notification about a flash sale. If your style guide specifies an informal register, that carries through. If "Premium" is a term for a product tier that shouldn't be localized, your glossary handles it. And the content gets translated consistently with your product, without anyone managing it as a string.

Each request requires a key (the identifier for the content item). It doesn't need to be semantic, but a descriptive key (like flash_sale_push_nov), which gives Localazy AI a signal about what it's working with. You can also pass a comment (a short plain-text note explaining the string's context or placement) which makes a meaningful difference for short or ambiguous content.

🧭 Use cases 🔗

Let's explore three example use cases that benefit the most from using the Translation API.

E-commerce: new catalog content 🛍️ 🔗

For large e-commerce operations, the challenge is usually the sheer amount of product descriptions that need to be dealt with. A new product line might arrive as a structured feed of hundreds of SKUs, each with a title, short description, long description, and a set of attribute labels. Getting all of that through a managed translation workflow before launch takes time that the business doesn't always have.

The API fits naturally into your e-commerce product publishing pipeline. When new product content comes in, your backend calls the API, translations come back, and the content goes live in all target languages. The winter jacket description will likely stay the same in March as it was in January. Once it's translated, it's done and doesn't have to take space in a TMS.

During the process, your glossary keeps category names, brand terms, and product-specific vocabulary consistent across the catalog. And for short strings (for instance, a spec label like "Water-resistant up to 30m"), the comment field is worth using. Something like "Product specification, shown in a grid on the product detail page" gives the model enough context to handle the ambiguous phrasing.

In addition, the lengthLimit parameter is useful for constrained placements, like product card subtitles, meta descriptions, or anything that gets truncated in the UI if it runs too long.

User-generated content: reviews and community posts 💬 🔗

Translating user-generated content close to real time is practical with the API in a way it isn't with a TMS workflow. A new review gets submitted on your site → your backend sends it to the API → you store the translation alongside the original → the reader sees it in their language.

User-generated content tends to be informal, which can trip up engines that default to a formal register. Using the comment field to note that a string is user-generated — along with relevant context like product category or discussion topic — helps keep the output from feeling stiff. Your style guide can also set register expectations that carry through automatically.

Multilingual publishing: push notifications 📲 🔗

Push notifications are one of the cleaner cases for the Translation API because the constraints are so well-defined: short strings, all languages at once, and a hard deadline. Notifications can't wait for translation cycles to complete: they need to go out now. 😀

Most teams handle this in one of two ways: either they maintain separate notification content for each language (high effort, easy to let drift out of sync), or they send everything in English and accept that a chunk of their audience gets a worse experience. The Translation API opens a third path that requires little additional infrastructure.

To show how this works in practice, here's a proof of concept I coded with Claude: a simple push notification center for a fictional mobile game, "Monkey Mayhem: Jungle Chaos," that I use as an example project in Localazy demo calls.

The interface of my push notification center lets you write your notification in the selected source language, translate it into 9 predefined languages with Localazy AI, make any last-minute corrections, and send it.

Under the hood, it calls the Localazy Translation API for all target locales, collects the responses, and prepares the localized versions for dispatch.

Each language goes to the API as a separate request. The responses come back with translations for each, keyed to the original string.

The whole flow (write, translate, review, send) takes about as long as it takes you to write the notification in the first place. There's no handoff to a translator, no waiting, and no reimporting. 🎉

For short strings like notification copy, the comment field could also be added to refine the output quality further. Something like "Push notification for reactivating mobile game players, shown on mobile lock screen" can give the resulting translations some flair.

And as stated above, if Localazy AI is unavailable for any reason, you can set a fallback to "deepl" or "google" in the request, which creates a safety net for time-sensitive use cases like this.

✅ Wrapping up 🔗

The Translation API doesn't replace a managed localization workflow, but it's a terribly useful tool to extend the possibilities when you're delivering a multilingual experience to your users.

For content that benefits from translator review, version history, and string-level control, Localazy's standard workflow remains the right approach. In contrast, the API handles what that workflow was never designed for: high volumes, short turnarounds, and content with short expiration dates.

If this fits your use case, it's easy to get started:

1. Create a Localazy project (or use an existing one).
2. Generate a translation token scoped to this endpoint.
3. Make your first POST request to /projects/{projectId}/ai.

Remember that translation requests consume Localazy credits, so make sure to check your account balance before going to production. We hope you find this feature useful and, for any questions or feedback, leave a comment on the discussion forum or contact us directly.

The articles are in English. Sakura isn't a techie, and while her conversational English is okay, technical jargon makes her head spin. She clicks the browser's "Translate to Japanese" feature. The resulting word salad confuses her even more. Frustrated, she calls support.

The agent on the other end is polite, knowledgeable, and speaks perfect English. Sakura does not. After five minutes of struggling to explain that the "merge" button doesn't match the instructions she read, she says, "Ah, okay, I understand. Thank you."

She hangs up. She didn't understand. Sakura churns silently and moves to a local competitor with worse features but documentation in Japanese she can actually read.

You know this is happening. According to Zendesk, more than 50% of consumers will quietly switch to a competitor after only one bad experience instead of providing feedback.

You feel the revenue slipping through the cracks. A multilingual support team would solve the problem, but you can’t hire an agent for each language. Localize your help center docs? Well, you dread the memory of the last time you tried traditional E2E localization: the email threads, the spreadsheets, the copy-pasting. 🤦‍♂️

Naturally, you look for a solution that bypasses that chaos. You consider using ChatGPT for customer support. A chatbot can read your English resources, translate incoming tickets in the background, and automatically guide users in Spanish, German, or Japanese. All without adding a heavy operational burden.

Both options (the automated bot and the localized help center) have their pros and cons. To see which one actually fits your situation, let's take a closer look.

🤖 The AI support agent: No toilet pauses, but no mother tongue 🔗

AI support agents detect language automatically and respond natively using AI translation and natural language processing. On the surface, they appear to solve the multilingual problem elegantly.

Let’s start with the AI support agent. It detects customer language in real time. It responds natively using AI translation and NLP. Adding an automated multilingual chat operator to your support flow feels like the logical next step.

Where multilingual chatbots shine 🔗

• It’s a polyglot: The bot speaks everything, from French to Tagalog, without you lifting a finger.
• It’s cheap: Token costs are tiny compared to hiring humans.
• No spreadsheet hell: You feed it your existing English docs and rely on AI translation for ticket conversations. No export/import nightmares.
• Brand voice tuning: You can prompt the bot to sound like a pirate or a professional, aligning with your brand's tone of voice.
• Knowledge sponge: You can train the bot on past tickets, Slack threads, and Confluence pages.
• Internal use: If you end up hiring agents, you can use the bot to support them to talk in countless languages without human translation delays.

So, an AI chatbot platform that supports multiple languages sounds perfect. Is there a catch? Let’s see.

The hidden cost of the AI support bot 🔗

• 👨‍💻 The developer time sink

You might think the cost is just the subscription. But developer time dwarfs the price of monthly subscriptions or API tokens. To set this up, your developers need to integrate the API, configure the webhooks, and ensure security compliance. Then comes maintenance. APIs change, tokens expire, and connections break. Every hour your lead dev spends fixing the chatbot is an hour they aren't shipping features for your core product.

It's true that some support platforms offer solutions out of the box so your devs don't get interrupted, but that also comes at a cost: they charge for it and tend to add a nice margin on top of the raw token usage.

• 👩🏻‍💼 Project management and quality assurance time

Neither DIY agents nor top multilingual chatbot platforms run themselves. Someone has to create relevant prompts, test responses, and monitor hallucinations. That someone is usually you. You end up continuously optimizing AI translation for customer support.

• 🎨 The UI inconsistency bug

This is the big one. The silent killer of customer satisfaction.

Let’s go back to Sakura. Or let’s say you have a French user. Your multi-language support bot reads your English documentation where the "Submit" button is mentioned. It translates this on the fly for the French user and tells them to click "Soumettre."

But your app interface? Maybe it was localized by a different team, or maybe it’s hard-coded. In your app, the button says "Valider." The user looks for "Soumettre." They don't find it. They see "Valider," but they aren't sure if that does the same thing. Confusing UI patterns generate tickets faster than the AI-powered bot can resolve them.

• 🛠️ The commitment

When you build your multilingual customer support strategy around a specific bot, you are building on leased land instead of acquiring equity. Your glossary, your fine-tuning, your specific "fixes" for its bad habits... they all live inside that specific tool.

Want to switch from Intercom to Zendesk? Or from one AI provider to another? You have to start over. All that configuring, testing, and prompting happens again. You’re locked in by the sheer effort of leaving.

🧭 Localized help center: Your single source of truth 🔗

Now, let’s look at the "old school" approach, where you eliminate SaaS support tickets by localizing your help center to other languages.

How multilingual documentation bridges the gap 🔗

• 📖 The glossary fix

Remember the "Soumettre" vs. "Valider" mess? A localized help center fixes this permanently. You define your terms once in a glossary or AI style guide. "Submit" always equals "Valider." The documentation matches the interface. The user reads "Click Valider," sees a button named "Valider," and clicks it. Problem solved. No ticket created.

• ✍️ Consistent style

You want your brand to sound the same in Berlin as it does in Boston. With a localized help center, you can set up a style guide to ensure your tone and customer experience are culturally adapted. You configure tone of voice, industry, and register per language, feed context details, and forget about it for years.

• 🧱 The foundation effect

This is the part most people miss. Think of a localized help center as a data source rather than a destination for users. Once you have clean, verified content, you can feed that to any new tool that comes along next year. All properly localized AI agents for multilingual customer service need a single source of truth like that.

Think of it: ChatGPT’s very own help center is available in 19 languages.

Things to consider when translating your self-service help resources 🔗

Even top AI virtual assistants require setup and fine-tuning, but so does localized content. Let’s see how much effort it takes to configure your help center to support multiple languages.

1. Native-speaking translators

Keep reading if you already employ language experts. But even if you don’t, here’s a little hack: use Localazy. ✨ In addition to a centralized localization management system, you get access to vetted professionals on demand. You pay for the work when you need it.

2. Ongoing updates

You might picture re-uploading entire Word documents every time you change a comma. Today’s tech is different. Here’s how Localazy simplifies things: you change one sentence in an English article – the system flags only that sentence for translation. Instead of re-doing the whole doc, you simply patch the update. That's what continuous localization is about.

3. System integration

You’ll need to connect your help center (like Intercom or Zendesk) to a localization system. With Localazy, that’s a matter of 30 minutes. You set it up once to let content flow out, get translated, and flow back with a simple trigger.

4. Translation management

A solid workflow for localizing your help center in multiple languages is non-negotiable. But if you use Localazy, you forget about the chaotic email threads and get everything in one dashboard. No new tool to manage. You can also invite team members and contributors, set up your own style guide for automated first draft translation using MT or AI and automate workflows for recurring tasks.

5. Time

Want to localize your help center fast? Use AI for 95% of the heavy lifting and then have a human review the output for accuracy. Localazy comes with AI-driven translation built-in, paired with sleek context and collaboration tools. Anyway, plan ahead because the human in the loop has to eat and sleep.

💰 What are the costs of each path 🔗

Let’s try to figure out a price tag for each option. We love numbers, right?

Path 1: The bot-only strategy 🔗

Let's take the Total Cost of Ownership (TCO) for the first year into account:

‌The visible costs include subscription fees and token usage. The less visible cost (and this is the scary part) is the number of support tickets generated by UI inconsistencies and unclear documentation, which is an unknown variable that scales with your user base. The more users you have, the more "Soumettre” vs. “Valider" confusion you create, and the higher your costs climb. At scale, even a small increase in ticket volume offsets any token savings.

Let’s see how this works in practice if you use an Intercom AI agent. You might start with the Essential subscription ($29/seat), but you’ll have to upgrade to Advanced ($85/seat) because the lower tier doesn’t include multi-language support. Just two seats will cost you $2,040 per year for the subscription alone.

Say you're aiming for three languages. Developers will need to spend around 35 hours ($60/hr) on setup and knowledge base integration. Next, your team will spend 20 hours ($45/hr) creating and testing multilingual prompts. Finally, occasional UI tickets (for issues like text overflow and locale bugs) take approximately four hours per ticket to resolve. Just four tickets like that per year add another $960.

You end up paying around $6,000 for your first year.

That’s how much AI support agents cost in 2026.

Path 2: The foundation-first strategy 🔗

Now let's focus on content localization with a platform like Localazy:

A structured localization setup involves:

• Platform subscription costs
• Initial integration time (typically a few hours of developer work)
• One-time translation investment for your existing help center
• Ongoing incremental updates (you only pay for changed content)

Notice what’s missing? The ticket cost variable. By eliminating the confusion at the source, you remove the operational drag on your support team. Let’s just agree that the best way to automate customer support tickets is to eliminate them.

As a small SaaS company using Localazy, you would pay around $2,868 for the first year. This includes eight developer hours ($60/hr) and human translation (16,000 words × $0.12/word).

The total cost drops to just $1,188 if you use AI paired with machine translation (16,000 words × ~$0.015/word). Updates are just a few dollars on top.

💡 Naturally, these calculations are estimates and depend on a few variables, but you get the idea. If you want a personalized breakdown, just contact Localazy for a quote

Multilingual self-help resources boost your ticket deflection rate, saving you time and money. But one localization advantage plays a special role in the cost-benefit breakdown:

📈 Your multilingual help center drives sales 🔗

Let's zoom out. "Support" is often treated as a cost center. But let's look at it through the lens of revenue, as it is more of a conversion lever.

The free-trial conversion 🔗

High-intent users (the ones most likely to buy) read your support articles and FAQs. They want to see if your tool can actually solve their specific problem.

Let’s say a potential customer in France explores your self-service help resources and encounters the UI inconsistency bug we talked about earlier. Do you think they’ll file a support ticket? Not really. They will probably assume your product is buggy or difficult and close the tab.

A localized help center is a conversion optimization tool as it reduces cognitive friction at the exact moment purchase intent peaks.

The silent sales team 🔗

In B2B especially, the person testing your product isn't always the person signing the check.

If you are selling to a Japanese company, your English UI might be fine for the engineers. But Compliance officers, legal reviewers, or procurement leaders would prefer reading the security documentation and compliance overview in Japanese. If they can't, they might veto the purchase. Localized docs remove this friction. They silently sell your product as reliable and professional while you sleep.

In markets like France or Japan, this is the difference between being a vendor and a partner. Hardly just a "nice to have." The ROI of translating your help center is higher than meets the eye.

🎯 Quick wins or a change-ready system? 🔗

So, which path makes sense for you?

Use the AI chatbot for quick wins if you have free time and a developer who has no better things to do than configuring the bot. But be aware: you might be planting landmines that eventually explode in a silent chain reaction of confused users and support tickets.

A localized help center will require some work, too. However, it builds a foundation. It ensures that when you do deploy a bot, it stands on solid ground. Your support docs become a single Source of Truth that drives sales, prevents churn, and allows you to adapt as technology develops.

The ultimate tip: localize your help center first. Then plug in an AI support chatbot. Get ready to build a foundation and make every other tool you use more effective. Try Localazy and see how easy it is to automate your help center localization.

I learned this firsthand working on Tiimo, a Danish planning app built specifically for people with ADHD. But my connection to this project started a decade earlier, through a friend in a new mom online group.

She's a lawyer in China and our sons are the same age. Six years ago, she started posting about ADHD publicly after her son was diagnosed. At the time, most people in China didn't understand it well. Information was limited and practical tools were hard to find. Through her daily posts, she shared research, answered questions from other parents, and connected people going through the same thing. The more she shared, the more I understood. And when I came across Tiimo three years ago, the concept immediately made sense.

📱Bringing Tiimo to the Chinese market 🔗

When the Tiimo team reached out to me for help with their Chinese localization, I knew I wanted to work on the project. An app like this had the potential of making  life genuinely easier for the community my friend had been advocating for.

Clémence Rigal, Tiimo's Head of Growth, put it clearly:

"Because our product is built for a neurodivergent audience, we need language that is both affirming and universally understandable. We think about accessibility in the user experience of the app itself, and in the wording we use"

That's a tall order for localization. English has a growing vocabulary around neurodiversity. Chinese doesn't (not yet). So, more than converting English to Chinese, we were helping an entire community put their experience into words.

This kind of work required a good translator, but also the right tools. Tiimo's previous setup was fragmented across multiple platforms. Now, they needed something that could be integrated with their CMS while giving translators the necessary context to make good decisions.

That's where Localazy came in. From my perspective as the Chinese localizer, what mattered most was how the platform handled the collaboration:

• ❓Could I get quick answers to questions?
• ❓Could I maintain consistency across thousands of strings?
• ❓Could I override the system when Chinese grammar demanded it?

The answer to all three was yes. Let me show you how.

💻 First impressions: the Localazy UI 🔗

Getting started was surprisingly simple. If you have a Google account, you don't even need to register separately. Just log in and you're in. For Tiimo, all 22 language pairs live in one place, which meant I could see the project scope immediately.

When I clicked into Chinese (Simplified), the interface was clean. Every string waiting to be translated appeared in a neat list. Source language on the left, target language on the right. Intuitive enough that I didn't need a tutorial. Underneath each string, I could see tabs for the main features:

• Suggestions (machine translation options)
• Similar (translation memory for consistency)
• Versions (edit history and rollback)
• Languages (how other translators handled this string)
• Screenshots (visual context from the app)
• Comments (direct communication with the dev team)

Everything I needed to make informed translation decisions was right there on the translation interface. This was very helpful for me since I didn't need to switch between tools, use separate spreadsheets, or hunt for context in email threads.

🔍 The "30 minutes" string 🔗

Let me walk you through one string that demonstrates Localazy's entire workflow, from initial doubt to final resolution.

30 minutes each, or in total? 🔗

One afternoon, I was working through new strings for Tiimo Learn, the community-based online lessons feature. One string caught my attention:

"7 Lessons · 30 Mins"

At first glance, it seemed straightforward. I translated it quickly:

"7节课 · 每节课30分钟" (7 lessons · 30 minutes each lesson)

But as I moved on to the next string, something nagged at me. Wait. Did that English actually mean "30 minutes each"? Or did it mean "30 minutes total"?

I went back to look at the source text again. The English was concise, maybe too concise. There was nothing that explicitly said "per lesson" or "in total".

In Chinese, I couldn't be ambiguous. The grammar forces you to be explicit. If I said "每节课30分钟" (30 minutes each lesson), users would expect 3.5 hours of content. If the actual total was 30 minutes, I'd just wasted hours of their time. For people using Tiimo to manage ADHD and plan their days carefully, that's was unhelpful. I needed to know for sure.

Asking the team directly on comments 🔗

This is where Localazy's Comments feature saved me from the email ping-pong I've endured on other projects. Instead of opening my inbox, drafting a query, waiting for a response, and losing context in the meantime, I clicked directly on the string in Localazy and typed into the Comments box:

I hit save and went back to work on other strings. No point sitting there waiting. Two hours later, I got a reply in the same thread: "Hi Jenny, 30 minutes would be the total duration for all 7 lessons".

Ah. So my initial translation was wrong. Good thing I asked.

Three messages, one clear answer, context preserved. No "sorry, which string were you asking about again?" and no back-and-forth screenshot exchanges. Instead, the entire exchange is still visible in that string's comment thread today. If another localizer working on Korean or Japanese has the same question, they can see the answer immediately.

This is better than the traditional spreadsheet approach. Here, the conversation lives with the string itself. And it allows you to nail the translation from the start, saving you hours of fixes and user confusion later.

The final revised translation 🔗

Now that I knew it was 30 minutes total, I needed to revise. I clicked back on the string and updated my translation:

"7节课 · 共30分钟"

The key changes:

1. 🟢 I kept the measure word 节 (jié) after the number 7 to indicate "lessons/sessions"
2. 🟢 I replaced 每节课 (each lesson) with 共 (gòng — meaning "total" or "in total") before "30 minutes"

This made it crystal clear for Chinese users: all seven lessons would take 30 minutes of their time.

Checking for terminology consistency 🔗

Before I hit save on the revision, I clicked on the "Similar" tab. This is Localazy's consistency checker, and it's become muscle memory for me.

If you've worked with CAT tools, this functions like a Translation Memory (TM), but it's more contextual. Instead of just exact matches, it scans the entire project for strings with matching keywords or sentence structures, then shows me how I translated those elements before.

For this string, it pulled up other instances where I'd used "lessons" and "minutes" within the Tiimo app:

• "5节课 · 共20分钟" (5 lessons · total 20 mins) ✓
• "3节课 · 共10分钟" (3 lessons · total 10 mins) ✓

This tab has saved me from embarrassing inconsistencies more times than I can count. My revised format was now consistent with how I'd handled similar strings.

An exception and the need for overrides 🔗

I clicked on "Save Translation."

Immediately, a pink error message appeared at the bottom of my screen:

⚠️ Unmatched numeric values: 30

I smiled. This happens frequently with Chinese localization, and it's actually a feature, not a bug. What happened is that Localazy's validation system is designed to catch errors. If the English source has "30 mins" and my Chinese translation suddenly says "40 minutes," that's probably a mistake worth flagging. The system counts numbers in both strings and checks if they match.

But Chinese grammar doesn't always play by those rules. By adding the measure word 节 (jié) and the character 共 (gòng) around the number 7, I had technically introduced "extra" characters that the system interpreted as potential number mismatches. The validation algorithm was doing its job, being rigid enough to catch real errors.

The difference from traditional QA checks is that Localazy's validation happens in real-time, string by string, rather than as a batch process at the end. And the platform gets it right by giving you an override.

If the flagged issue doesn't make sense, you can always click on the dropdown arrow next to the error message and select "Ignore validation issue". That's what I did here. The pink warning faded to gray, and the status changed to "All issues are ignored". The string was saved, with my override decision documented.

This is the sweet spot in localization technology: systems that catch mistakes but trust the human expert to make the final call.

The Versions tab tracked every edit 🔗

The Versions tab now tells the complete story of this string. Click on it and you'll see:

• 🟢 Current version: "7节课 · 共30分钟" (7 lessons · total 30 minutes) — revised after clarification
• ⚪️ Previous version: "7节课 · 每节课30分钟" (7 lessons · 30 minutes each lesson) — initial translation

The tab shows exactly when I made each change, what I changed from, and what I changed to. For developers, version history provides transparency. They can see exactly what changed and when, which helps them understand if UI issues are related to recent translation updates.

For me, it's a reference point. I can check if I updated related strings consistently and learn from earlier choices. If I ever need to explain why I translated something a certain way, the evidence is right there. More importantly, it shows that asking questions isn't a sign of incompetence. It's part of good localization work. My initial translation was an educated guess. The comment thread got me the information I needed. The version history shows I corrected it.

Notice that I didn't just accept the machine translation suggestion and move on. For Tiimo, that would have been a mistake. Next, I have more relevant examples to show you why.

🤖 MT couldn't match Tiimo's playful tone 🔗

Localazy includes machine translation and AI suggestions into the workflow. For each string, I can see what various translation engines suggest: Google Translate, DeepL, Amazon Translate, and others (plus Localazy AI). If I'm happy with a suggestion, keyboard shortcuts let me accept it instantly.

This can speed things up for straightforward strings, like simple UI labels like "Cancel" or "Settings" that don't need much human intervention. But professional translators always take MT suggestions with a grain of salt. Sometimes you're doing MTPE (Machine Translation Post-Editing), cleaning up what the engine gave you. Other times, you're translating from scratch because the suggestion is so far off that it's faster to start over.

Even advanced machine translation cannot understand cultural nuances, language sensitivity, or the warmth and humanity that good writing requires. MT engines typically revert to the most common, convenient option. For something like Tiimo, where tone and approachability matter deeply to the neurodivergent community, that approach fell short. Let's see some examples.

Case 1: The "Chill Dog" disaster 🔗

One of Tiimo's daily routine options includes this string:

"Downward-Facing Chill Dog: Stretch it out and pretend you're a dog sniffing out relaxation 🐶"

The English is clever. It's a playful twist on the yoga pose "Downward-Facing Dog", making it accessible and fun. Anyone who's done yoga gets the reference immediately.

I checked the MT suggestions out of curiosity:

• Amazon Translate: "朝下的 Chill Dog" (Downward Chill Dog) — kept "Chill Dog" in English, which means nothing to Chinese readers.
• DeepL: "下犬式：伸展身体，假装你是一只嗅出放松的狗" (Downward Dog: Stretch your body, pretend you're a dog sniffing out relaxation) — awkward and unnatural
• Google Translate: "面朝下的冷狗" (Downward-facing cold dog) — almost funny enough to keep

That last one deserves an explanation. "冷狗" ("cold dog" or "freezing dog") isn't a phrase that exists in Chinese. Worse, it carries negative connotations. In some contexts, it echoes "死狗" ("dead dog"), which is a derogatory insult. Not exactly the warm, playful tone Tiimo was going for. 😅

The MT engines all made the same mistake: they translated literally without understanding the cultural reference or the playful tone.

My final translation was quite different:

"下犬式放松版：尽情伸展，假装自己是在伸懒腰的狗狗 🐶" ("Downward Dog Relaxation Version: Stretch freely, pretend you're a dog having a nice leisurely stretch")

This maintains the playful tone, makes the yoga reference clear for those who know it, and stays approachable for those who don't. It adds "伸懒腰", a warm, relatable phrase Chinese speakers use for that satisfying morning stretch feeling ("having a leisurely stretch"), and includes "狗狗" (the affectionate diminutive for dog), keeping a cute and friendly voice. MT couldn't make these choices. It doesn't understand that "伸懒腰" carries warmth and familiarity, or that "狗狗" is affectionate where "狗" is neutral.

Case 2: The "Save" button 🔗

In app interfaces, the word "Save" appears constantly. "Save your changes", "Save this routine", "Save your settings", "Save your progress."

In English, "save" handles all these contexts fine. In Chinese, context determines which word you use:

• 💾 保存 (save/store data, files, changes — correct for apps)
• 🛟 救 (save a life, rescue someone from danger)
• 💰 节省 (save money or resources)

Machine translation often defaults to 救 because it's the most common translation for "save" in general contexts. But imagine a button in Tiimo that says "救改变" ("rescue the changes"). Melodramatic and confusing. The correct translation is always 保存 for app contexts. But MT engines don't consistently recognize the difference. A human translator knows immediately which "save" is needed just from context.

Case 3: "Unload My Brain" 🔗

Tiimo uses playful, encouraging language to make planning feel less overwhelming. One feature helps users get tasks out of their heads and into the app. The English string: 🧠 "Unload My Brain".

This is perfect for the context. It's casual, relatable, and captures that feeling of mental clutter you need to externalize. For people with ADHD, this framing is both accurate and empowering.

🤖 The MT suggestion: "卸载我的大脑" (literally: "Uninstall my brain")

In Chinese, 卸载 is computer terminology. It means "uninstall software" or "remove a program from your system." When applied to 大脑 (brain), it sounds like a tech operation gone wrong. As if you're removing your brain like it's a malfunctioning app.

This is awkward and even slightly disturbing. It completely misses the mental health framing that makes the original English work. The correct approach requires, of course, understanding what "unload" means metaphorically. Better translations would be:

• "清空大脑" ("clear out my mind"), or
• "整理思路" ("organize my thoughts").

👩‍💻 Three mistakes = a common truth 🔗

All three examples show the same problem: machine translation translates words but doesn't fully retain the source meaning. It doesn't understand tone, cultural context, or how metaphors work across languages.

For generic content, that's manageable. For culturally sensitive projects like Tiimo, where the target audience is neurodivergent users who deserve language that's accurate, expressive, approachable, and human, MT shortcuts don't work.

Localazy has since integrated AI translation that understands brand voice and follows glossary terms automatically — Petr explains more above. That's a significant step forward that greatly improves the final results (you can see an actual test run by Dorota Páwlak here). But whether you're using traditional MT engines or the latest AI, you must keep in mind that these tools are a good starting point, but the final translations need the eyes of an expert.

📚 Related read: A practical guide to translating with Localazy AI

🔄 Continuous localization: the next step 🔗

Localization doesn't end when the app is fully translated and launched in the target market. Apps update, features get added, and new strings appear. The real test of a platform is how it handles the ongoing maintenance cycle.

When I asked Clémence what changed for Tiimo after moving to Localazy, she explained:

"Since moving this work into Localazy, it's easier to assign designated translators to specific locales and let them work in isolation with the right context. Each translator only sees strings for their market. The setup fits cleanly with our CMS, so updates move from translator to production with less coordination"

From my side, this meant getting notifications whenever new strings were added. I could review updates on my own schedule, translate them, and know they'd integrate smoothly into the next build.

• ❌ No coordination meetings.
• ❌ No file exports and imports.
• ✅ Only a clean, continuous workflow.

But here's what good localization partnerships really require: staying open to feedback, especially from users. And we'll get to how that played out for Tiimo below.

The incident that proved platform choice matters 🔗

Before Tiimo moved to Localazy, they experienced a common but frustrating problem. A few months after the Chinese launch, a user reported garbled text in parts of the app. When the team brought me in to investigate, we discovered that during an app update cycle, some of my human translations had been accidentally overwritten and reverted to machine translations. The garbled text resulted from encoding problems in how those MT strings were processed.

Quality at launch is pointless if your workflow can't maintain it. A good translation today becomes bad translation tomorrow without proper maintenance

We fixed it quickly. I retranslated the affected strings. The developers pushed the update. Tiimo responded directly to the user who'd reported the issue. But it was a reminder: localization quality depends on the partnership between developer, platform, and localizer. Clear workflows matter. Version control matters. Systems that preserve human translation decisions during updates matter. This is one of the reasons why Tiimo moved to Localazy:

• ⚙️ The tighter CMS integration meant fewer opportunities for translations to get accidentally overwritten
• ⏮️ The version history feature provides an audit trail
• 🔄 The workflow preserves translator decisions through update cycles

☝️ A tip for translators: set up your glossary early 🔗

If I could go back to the start of the Tiimo project, I'd do one thing differently: ask the team to set up a glossary in Localazy before I began translating.

The platform's glossary feature highlights defined terms during translation and validates your work against them. For a project like Tiimo, this would have me saved time on questions like:

• 👥 What exactly is "body doubling" in Chinese?
• 📅 Should we use 周 or 星期 when referring to weekdays?
• 🧠 How should we consistently translate "executive function"?

Having these decisions documented upfront means they surface automatically when those terms appear in new strings. For projects managing 22 languages with different translators, that consistency is essential.

Localazy has also added style guides, which let teams define tone, formality, and brand voice expectations. Combined with the glossary, these tools help maintain a unified experience across locales.

✨ Good localization needs all three 🔗

From this experience, I could say that successful localization is a mix of empathy (Tiimo), cultural nuance (me), and robust tooling (Localazy).

Since Tiimo launched in Chinese, we've seen growing adoption in this market. That includes my friend, the lawyer I mentioned at the beginning of this article. She's using Tiimo now. So is her son. She's told me how much the planning features help them both manage their days with less overwhelm.

That feedback means everything. It means we've suceeded making tools accessible to people who need them. With a solid software localization platform, our job is much easier. And with the help of linguists, independent developers and small teams can launch multi-language apps without enterprise-level budgets, as long as they integrate continuous updates into their workflows. Because localization is a long-term relationship, not a one-time task.

In the last three years, nearly every single day has been shaped by AI-powered launches. Sometimes these new creations solve real problems, other times, they’re only a shiny distraction. Sometimes they overpromise and underdeliver; other times they prove to be better than any marketing slogan.

Where does Localazy AI fit in this spectrum? Let’s have a look at the promise first:

That’s a big claim to live up to. And if you’re a translator or someone working daily with those inquisitive creatures, your first reaction might be: Sure, maybe it does, but for all projects? For all content types and language pairs? What if my style guide is super specific, packed with rules on gender neutrality, or instructions on how to deal with creative content? Is it equally useful for technical and marketing texts, or does it only excel in one domain?

Since I happen to belong to those curious creatures, I’ve decided to put that claim under the microscope.

🎲 The rules of the game 🔗

Three language pairs, two texts, one tool that unites them all: Localazy AI.

This test assesses how the new feature works with technical content and marketing copy. Both texts were translated with Localazy AI from English into Polish, German, and Spanish. Each source contained 400-500 words and was accompanied by a glossary with 10 terms and a style guide with detailed information, such as tone of voice, examples of preferred translation, or untranslatable terms.

For each text, I created a separate project with three languages and one style guide. The style guide included instructions for all three locales, with exceptions, if relevant, on how to approach translation in another language. For example, for German, the marketing copy and the manual had to be formal, and for other languages, informal. These exceptions make for a great opportunity to test if the tool can deal with language override instructions.

The style guides also contained examples of preferred translations in all three languages.

To score the output created by Localazy AI, I evaluated terminology adherence, style guide faithfulness, and translation fluency. No complicated calculations here – just 1 point for meeting the criteria fully, 0 for not meeting it at all, and deducted fractions of points for small deviations.

Note: Since the tool documentation states that Localazy AI works best when the source language is English, I decided not to push it to the edge of its capabilities and focus on this source language only

Let’s see which content type and language pair was handled by Localazy AI with the greatest care.

1️⃣ Part 1: Marketing copy 🔗

The first test candidate is a 415-word marketing copy from a fictional brand offering a Smart Tea subscription. 🍵 While I’m not entirely sure such services exist in real life, the text created for this experiment includes plenty of real-world challenges: a few creative phrases, a couple of brand names, and a decent dose of marketing language.

The style guide for this translation included instructions on tone (warm, calming, and aspirational), target audience definition (urban professionals interested in a mindful lifestyle), and other rules such as “avoid medical claims and literal translation” or “address the reader directly”. The only exception to the last rule was German, where the formal tone was required. Another key rule was gender neutrality.

Source text 🔗

At Solviva, we believe that everyday rituals deserve a little more attention.
In a world that often moves too fast, small moments of calm can make a big difference. A warm cup of tea in the morning. A quiet pause in the afternoon. A gentle evening infusion before sleep. These simple rituals help us reconnect with ourselves and restore balance in our daily lives.
That is why we created the Smart Tea Subscription.
Our subscription service delivers carefully curated herbal blends straight to your doorstep every month. Each monthly collection is designed by our team of tea experts, who draw inspiration from traditional wellness rituals around the world.
One month you might discover calming herbs inspired by Mediterranean evening traditions. Another month might bring energizing blends influenced by ancient Asian tea culture. Every collection is an invitation to explore new flavors, aromas, and moments of mindfulness.
But Solviva goes beyond simply delivering tea.
Through our mobile app, you can personalize your Smart Tea Subscription to match your lifestyle. The app allows you to share your preferences, daily routines, and lifestyle goals, such as better focus, more relaxation, or improved evening wind-down rituals.
Based on your input, the app recommends herbal blends that fit naturally into your day. Need a gentle evening infusion to help you slow down after a busy day? Looking for an energizing blend to start your morning with clarity? Solviva helps you build small wellness rituals that feel effortless.
Every tea we offer is crafted with care and respect for nature.
All Solviva teas are made from organic ingredients sourced from trusted growers around the world. We work closely with small farms that share our commitment to sustainability, biodiversity, and ethical sourcing.
This approach allows us to ensure that every herbal blend meets the highest standards of quality while supporting farming communities and protecting the environment.
But what truly makes Solviva special is the experience.
Opening your monthly collection should feel like receiving a thoughtful gift. Each delivery includes beautifully packaged herbal blends, tasting notes from our tea experts, and simple suggestions for creating your own wellness ritual at home.
Whether you enjoy your tea during a quiet morning moment or share it with friends in the evening, Solviva turns everyday tea drinking into something more meaningful.
Because wellness doesn’t have to be complicated.
Sometimes, it starts with something as simple as a cup of tea.
With Solviva’s Smart Tea Subscription, those moments of calm become part of your everyday life.

Results 🔗

Localazy AI consumed 2 credits per language pair. It took about one minute to translate each language, which is not so bad, considering the context that AI has to digest before spitting out the content.

Were the results worth waiting for? Absolutely.

Here’s a quick overview of the results per language:

🇵🇱 Polish

There’s not much to complain about. Localazy AI applied the style guide correctly, including the sample translations. Nearly all terms were rendered as per the glossary. One term was skipped, and another one had a switched word order (“wieczorny napar” instead of “napar wieczorny” for “evening infusion”). The translation was accurate and fluent, although some phrases could have been translated in a more creative way, instead of copying the source sentence structure. The results deserve one point for the style guide adherence, 0.8 for the overall translation quality, and only 0.8 for terminology due to the two missed instances.

🇩🇪 German

Similar story as above. Terminology was skipped in one case only. “Smart Tea Subscription” appeared in the text three times; once the model translated it as per the glossary, twice it was left in English. The model might have been confused by the use of capital letters in the source and probably took the phrase for a brand name, applying the style guide rule requesting to leave the brand names untranslated.

Other style guide rules were followed, too, especially regarding the formal register. The general instruction was to use casual and informal language, except for German. Localazy AI did respect this language override.

The tool considered the sample translations provided with the style guide. Whenever the source included sentences similar to the submitted examples, the model reacted accordingly and rendered the text based on the wording from the examples.

All in all, the translation was fluent and natural, which can justify the score of one full point. Style guide adherence gets one point too, while terminology compliance has to settle for a modest 0.8.

🇪🇸 Spanish

The terminology blunders on repeat. “Smart Tea Subscription” was treated as untranslatable in two cases; in the third one, it was translated as per the glossary. The style guide passed the test again; however, fluency suffered a bit. There was one missing article, one missing punctuation mark, and two phrases rendered for Spanish-LATAM, instead of Spanish Spain.

This only proves the point highlighted by Localazy on every single step: you can’t leave AI to its own devices, ignoring human judgment. Human expertise is always a key ingredient in any AI-powered adventure to ensure the text is contextually and linguistically correct.

This translation deserves one point for style guide adherence, 0.8 for terminology, and 0.8 for fluency.

2️⃣ Part 2: Technical manual 🔗

The second test round consisted of a 470-word drone manual. 🚁 An equally fictional brand, with equally representative text features such as instructions, industry terms, or units. The glossary included 10 terms in each language, and the style guide provided more context, such as the requirement to use a neutral and precise tone, apply imperative form for operational instructions, and keep product names untranslated.

To give the model a taste of the desired translation, I included sample translations for each language. Again, in terms of formality, German called for a formal register, and Spanish and Polish were allowed to stay neutral. Gender neutrality was an important requirement as well.

Source text 🔗

The LiftMate X200 is an autonomous warehouse drone designed to transport lightweight inventory items within modern distribution facilities. The system combines computer vision, onboard sensors, and cloud-based coordination software to ensure efficient and safe movement of goods between storage areas, picking stations, and packaging zones.
The LiftMate X200 is optimized for indoor warehouse environments and supports automated logistics workflows. By integrating with warehouse management systems, the drone can receive and execute delivery tasks automatically, reducing the need for manual transportation of small packages.

System setup
Before operating the drone, ensure that the charging dock is properly installed and connected to a stable power source. The charging dock should be placed on a flat, unobstructed surface within the designated charging zone.
Next, install the navigation beacons in all operational zones of the warehouse. These beacons allow the drone to determine its position with centimeter-level accuracy and maintain a stable flight path. Navigation beacons should be mounted at a height of 2–3 meters and positioned according to the installation map provided with the system.
Once the hardware components are installed, connect the system to the AeroSync Control Panel. The control panel allows operators to configure the drone, assign delivery routes, and monitor system performance in real time.

Starting a delivery task
To begin operation, open the AeroSync Control Panel and create a new delivery task. The operator must specify the pickup location, the destination zone, and the expected payload weight.
The system automatically verifies whether the payload exceeds the maximum payload capacity of 3 kg. If the payload is within acceptable limits, the drone initiates the autonomous flight sequence and proceeds to the pickup location.
During the flight, the onboard optical sensors continuously scan the environment to detect obstacles such as shelving units, equipment, or personnel. If an obstacle is detected, the drone automatically adjusts its route to maintain a safe flight path.

Safety features
The LiftMate X200 includes several safety mechanisms designed to prevent accidents and operational disruptions. If the drone detects a sudden obstruction or loses connection with the network, it automatically switches to safe hover mode until communication with the control panel is restored.
In addition, the system continuously monitors battery health to ensure safe operation. When the battery level falls below the recommended threshold, the drone automatically returns to the charging dock.
Operators should ensure that warehouse personnel are aware of active drone zones and avoid placing temporary obstacles within designated flight corridors.

Maintenance
Routine maintenance should be performed every 200 flight hours to ensure optimal performance.
Maintenance procedures include:
Inspecting propellers for visible damage
Cleaning the optical sensors to remove dust or debris
Verifying the condition of the battery and checking battery health in the control panel
Ensuring the charging dock and navigation beacons remain securely installed
Failure to follow recommended maintenance procedures may reduce system efficiency and may void the product warranty.

Results 🔗

This time, Localazy AI consumed 2.3 credits per language, and the results were ready after roughly 1 minute.

What was the output quality? Surprisingly, no surprises again.

🇵🇱 Polish

No big deviations were detected here. The only problematic term was “control panel”, which was translated as per the glossary only when written in lower case. When both words were capitalized, the model treated the phrase as an untranslatable item and left it in English. Amusingly, when another term from the glossary appeared once in lower case and once in upper case (“Delivery Task”), the correct glossary term was applied every single time.

The style guide gained the respect it deserved, and the translation was accurate and fluent. These two areas earn one full point, while the glossary adherence receives 0.8 points.

🇩🇪 German

Glossary adherence was a bit tricky here. “Control panel” was translated correctly only when it appeared in the source in the lower case, but the upper case was rendered as an untranslatable term.

Apart from this little glitch, the style guide was applied correctly, and the language override requesting a formal tone was respected. There were no problems in the target text, which means one full point again for the style guide adherence and translation, and a little bit less for glossary adherence.

🇪🇸 Spanish

The technical text didn’t pose any challenges in this language either. All phrases were rendered as Spanish for Spain with no linguistic issues. The style guide was applied, and the glossary was missed only in the case of “control panel” written in the upper case. It seems the model followed a similar pattern of case confusion for all languages.

3️⃣ One more attempt: Mobile app strings 🔗

Since the tool passed the first test with flying colors, I decided to raise the bar. In the final experiment, I created several ambiguous mobile app strings with hidden pitfalls, such as variables representing numbers. 📵 These tricky creatures may change the grammatical case of surrounding words when you translate into highly inflected languages, so it was a trap worth constructing. My high-inflected target language this time was Polish, and the plan was to test how Localazy AI can handle not only the delicate placeholder-infused strings but also gender neutrality in more complicated sentences.

Source text 🔗

Welcome back! 
All set and ready 
Ready to go 
Level %d reached 
%d points earned 
%d tasks completed today 
Goal missed yesterday 
%d-day streak achieved 
Performance improved 
New badge unlocked 
Early access granted 
Invitation received 
One step closer to your goal 
Goal completed 
Great progress so far 
Improvement detected 
No activity today 
Inactive for %d days 
Rank: #%d this week 
Daily goal achieved 
Plan not completed 
Preferences updated 
Offline mode active 
Session expired 
Try again later 
Something went wrong 
Action required 
Continue 
Skip for now 
Keep going

The source text was accompanied by a glossary of 10 terms and a style guide explaining how to avoid some of the pitfalls intended to push the tool to the extreme. Since the strings were for a fictional health-tracking app, the instructions called for a neutral, friendly tone. The style guide also included examples of how to translate gendered phrases (e.g., by using passive voice or preferring noun-based instead of verb-based phrases), and the rule to adjust grammar around variables representing numbers (e.g., “Points earned: %d”, instead of “%d points earned”).

Results 🔗

What happened in this case? Here’s a short overview:

📲 Mobile app in action

The cost of translating my 90 words of mobile app was only 0.6 credits and took less than a minute. This quick and cheap action resulted in surprisingly good content. Since my instructions regarding strings with variables were very precise, the tool rose to the challenge and provided grammatically correct phrases. For example, “%d task completed today” was rendered as “Zadania ukończone dziś: %d” to avoid problems with cases (the noun form changes depending on the preceding number).

The tool did well in terms of gender-neutrality, also in instances where no matching or similar examples were available in the style guide. Specific rules such as “Avoid gendered verb forms whenever possible” came to life in the translation of the string “Ready to start” that became a neutral “Gotowe do startu” rather than masculine-marked “Gotowy” or feminine “Gotowa”.

All the glossary terms were applied correctly, and my ambiguous fitness app, constructed to test the tool’s limits, turned out to be less of a workout than expected.

Once again, the test confirmed that Localazy AI follows not only the glossary, but also the style guide, which is not an easy quest. Many localization platforms that I had the pleasure to explore don’t include the style guide feature, or the style guide rules are followed partially. So, hats off to Localazy for solving this issue.

☝️ A word of warning

All this, of course, doesn’t mean that you can simply create a super-specific set of rules and an extensive glossary, hit “Use Localazy AI” and then publish the output in the blink of an eye. Every combination of language, content, and instructions may provide different results, so don’t forget to invite a professional linguist into your project to make sure your content works as required.

👁️ If this test peaked your curiosity, upload your own strings today to experiment with formality and different target languages. You can use the source text examples provided above by hitting the copy button on the upper right-hand side of the code boxes

🔬 Room for improvement 🔗

Two decades ago, Daft Punk had us all singing "Harder, Better, Faster, Stronger”. Not everything needs to be pushed to extremes, but sometimes it pays to “Work it harder, make it better”, even if the context changes. So, if I were to point out where Localazy AI could level up, I’d focus on the following:

1. Uploading glossaries as external files 🔗

When creating the projects, my biggest limitation was the lack of an option to add a style guide or glossary as a file. Both assets have to be submitted manually. For style, that’s manageable: the tool asks plenty of questions and guides you toward the right choices. Glossaries, however, are another story.

Entering terms one by one quickly becomes tiring, especially when you already have TBX or Excel glossaries sitting in your local folders. And many companies do. Adding terms manually, across multiple languages, isn’t exactly the most rewarding task. Even with my modest set of 10 terms across three languages, the setup took longer than the AI translation itself. If you’re saving time with AI translation, you probably don’t want to give it back by copy-pasting content that already exists elsewhere.

2. Including screenshots in AI translation 🔗

Localazy AI looks into style guides and glossaries when translating. But sometimes it helps to look further. For example, on screenshots. Those pieces of content serve as an invaluable source of context, especially for mobile apps and games. The tool can already recognize text from screenshots and match it with relevant source keys to show more content for translators. Maybe it could also go an extra mile and consider the screenshots as context for the AI-powered translation?

3. Exporting style guides and glossaries 🔗

Another priceless addition would be the export option for glossaries or style guides. In my experiments, I planned to create two similar projects using the same assets. But once I realized this would require manually recreating both the style guide and glossary, I quickly dropped the idea.

Exporting these context assets isn’t just useful for controlled experiments. It matters in real-life projects, too. You might be working on a new project for the same client and want to reuse an existing glossary or style guide. Without an export option, that means starting from scratch. A simple export feature could save a significant amount of time and avoid unnecessary frustrations.

👍 Delivered as promised 🔗

Grand promises are often difficult to keep. My experiments proved that Localazy AI is not selling fantasy by claiming it can deliver high-quality translations that understand your project’s context, terminology, and style requirements.

However, to see this promise fulfilled in your projects, you will need much more than a great tool. Detailed style instructions with sample translations indicating your desired style, decent glossaries, and human expertise remain invaluable factors for your success story. Will you give it a try?

Without a proper i18n project setup (especially when both your apps evolve in parallel), you are likely to deal with duplicated work, conflicting translations, missing keys, inconsistent product wording, etc. This is where i18n project management comes into play and features like format conversion become important.

Let's see how you can structure your projects right to avoid problems in the long run.

☝️The reasoning behind structuring 🔗

When you are localizing for both iOS and Android, solid structuring can save you many headaches. Even if both platforms serve the same product, their string sets usually behave differently, such as:   

• Having the same concept but different phrasing:

iOS: "Allow push notifications?"
Android: "Turn on notifications for this app?"

• Sharing meaning but different key names:

iOS: "profile.logout_button.title"
Android: "menu_logout"

• Including platform-specific features (for instance, Android apps come with a biometric sign-in option).

Recognizing the differences here is what tells you whether to group all strings into one project or split them into multiple ones. And this is where Localazy’s superpowers shine:

Format Conversions 🔗

You maintain strings in one platform’s format. Localazy exports them into the other platform’s format (iOS XCStrings ↔️ Android XML). As simple as that. No manual rewrites or restructuring are needed.

Translation Memory 🔗

Using your previously approved translations, you get suggestions whenever identical matches appear across different strings. You can then reuse them as you wish.

Duplicity Linking 🔗

Translation Memory allows you to reuse previous translations. But what if you didn't have to? With Duplicity Linking, you won't have to translate the same keys over again: you link them together and let them share their translations, with changes applied automatically across all linked duplicates.

With these in place, your team won’t translate “Login” a dozen times, or create multiple translations like “Log in”, “Login”, “Log In”, each demanding translations of their own. Together with easy format conversion, these three features halve your workload before you even realize it.

Now, let's get to the nitty gritty. We'll outline the most common scenarios when iOS and Android strings are mixed, and some easy steps to fix it.

1️⃣ Scenario 1: Strings are identical across iOS and Android 🔗

This is pretty much a fairy tale for mid to large-sized mobile development. If your apps share all strings across both platforms, a single Localazy project with just one platform’s string files is all you need.

This approach works when:

• 👁️ Differences are mostly visual (your UI layouts are adapted to each platform’s style, while the UI wording and code logic stay the same).
• 💬 You've decided to maintain a unified language throughout the platforms.

In this setup, you only send strings from one platform into Localazy. Most teams pick Android for this, simply because it already holds the bulk of their strings. Once the strings are in, Localazy takes care of converting everything into the iOS format using format conversions.

Steps 🔗

1. Upload your Android strings (strings.xml) to a single Localazy project.
2. Translate everything there in one MT/AI/human round.
3. Export the translations in the iOS format (.xcstrings or .strings) using Localazy’s format conversion.

It gets even easier if you use the Localazy CLI: you can get strings for both platforms automatically by including the command line tools in your CI/CD or build process.

Why this works better 🔗

Keeping things in one place will help you in several fronts:

• No duplicated translations.
• End of inconsistent terminology.
• Translations automatically apply to both platforms.
• Format conversion ensures Android and iOS always get the right output.
• Translation Memory fills in recurring text automatically.

2️⃣ Scenario 2: One platform contains all the strings of the other 🔗

Landing from the fantasy world into the real one, this is the most common situation you’ll see in real projects. In many mobile app setups, both apps share most of their wording, but one platform includes a few extra screens or features on top. This leads to one of your platforms containing a larger string set, while the smaller platform’s strings are fully included in the larger one.

Imagine these contexts:

• Your iOS app ships more features (and resultantly, more strings).
• Your Android app kept some legacy screens that the iOS app never had.

Example: Your iOS app has 150 strings and the Android version has 95. 95 of them are overlapping, but 55 only belong to iOS.

To handle this, you’ll need two Localazy projects: a common and a platform-specific one (here, for iOS).

Steps 🔗

1. Upload Android’s shared strings (strings.xml) to the common project.
2. Translate the full set of strings once for all existing languages.
3. Export translations from the common project in .strings or .xcstrings using format conversions.
4. Upload the iOS-only strings into the platform-specific project.
5. Export the translations from the iOS-specific project (no conversion needed, but you still export them so your iOS-only strings are translated and ready to use).
6. Merge both exported string sets into your iOS app by placing both files inside the localization folder.

The same logic applies vice versa.

Why this works better 🔗

In this situation:

• Shared wording stays centralized.
• Extra strings live separately.
• Translation Memory auto-suggests known translations.
• Format conversions keep both outputs correct.

3️⃣ Scenario 3: Both platforms contain unique strings 🔗

This is the full independence case. When your apps:

• ship their own features,
• have separate flows & roadmaps,
• or evolve at different speeds,

it’s time to give each platform its own space while still keeping them connected behind the scenes.

This time, you still use two projects (one for Android, one for iOS) but you hand the mic over to Localazy’s Automations to handle the smart work in between.

Steps 🔗

1. Create two projects: an iOS project and an Android project.

These projects will store common strings + strings that only exist in these apps, like:

• iOS-specific features (e.g. “Use Face ID to continue”).
• Apple ecosystem elements (e.g. “Sign in with Apple”).
• Android biometric features (e.g. “Use fingerprint to continue”).
• System notifications (e.g. “This app is using battery in the background”).

2. Spot and solve your duplicates using one of these two methods:

• Cross-project Translation Memory (TM)

This is the basic setup to avoid duplicates. TM will detect matches and let you reuse and modify them independently. You can set up the cross-project feature via Connected Projects and apply changes in bulk using Automations.

• Cross-project Duplicity Linking

This method completely automates the sync process, creating a tight connection between duplicates. Once connected, you don't have to think about it ever again. For teams whose iOS and Android apps don’t grow at the same pace, this is the best option long-term.

For instance, if you make a translation change in the iOS Project, Localazy will automatically update the Android version of that same text, and vice versa

Why this works better 🔗

Taking the independent path has its own merits:

• Everyone knows where strings live.
• Translators only see strings that actually show up in the app they’re working on.
• Each platform can develop at its own pace.
• Debugging becomes much simpler.
• No manual intervention is required.

📲 Use case examples 🔗

If you're still unsure on what solution would be best for your use case, here are some examples for different industries and contexts.

Fitness app: Shared UI, high overlap 🔗

On both iOS and Android, the main screens use the same wording for buttons and labels. The only real difference is that Android shows a couple of extra system permission prompts.

News app: Mostly shared UI, but one platform has a few extras 🔗

In a news app, both iOS and Android will usually show the same basics: headlines, section names like “Sports” or “Business”, and the main category labels. Where things start to drift is when one platform gets a couple of bonus features (for example, iOS has “Saved Articles” and “Reader Mode”, while Android doesn’t).

Marketplace app: Mostly non-shared UI, different features and roadmap speeds 🔗

Marketplace apps often diverge heavily. Maybe for the same product, its Android app focuses on seller tools, while its iOS counterpart leans more into order management and fulfillment. Resultantly, each platform ends up with its own identity, including unique screens, different roadmap priorities, and very little shared UI.

？FAQs 🔗

Can I start with one project and move to two later? 🔗

Yes. You can later split your project into common and platform-specific ones as things grow.

How do I choose between “one project with rules” and “two projects”? 🔗

If both platforms move in lockstep, stick to one project with rules. If the bigger app runs ahead and needs more freedom, go with two projects.

Can using multiple Localazy projects slow down mobile app localization? 🔗

No, in fact, it's the complete opposite. Thanks to Translation Memory and Duplicity Linking, Localazy takes care of the shared stuff on its own. Translators end up seeing only what’s actually relevant to their platform, which usually makes the whole process faster.

Can I handle Android localization programmatically with Localazy? 🔗

Yes. Use Localazy CLI or the Android Localazy plugin to automate uploads and downloads entirely. Use the plugin if your team is more comfortable staying in Gradle rather than dealing with separate CLI calls.

Should I connect Translation Memory to Glossary? 🔗

If your setup grows beyond two projects (maybe you added a separate admin app or a lite version of your main Android app focusing on low-end devices), it makes sense to connect both to ensure important terms, like product names or UI labels, are kept consistent.

💬 A final note 🔗

Working on mobile app localization across iOS and Android can look overwhelming, but it really doesn’t have to be. With a bit of upfront i18n structure, plus format conversions, Translation Memory, and some cross-project automation, Localazy handles most of the heavy lifting for you. Try it today and contact the support team if any questions arise.

I've spent years advising development teams on internationalization, and one pattern keeps repeating: teams discover the cost of postponing i18n work far too late. The experience of my fellow member at the LangOps Institute, Rémi Auxenfans, captures the problem better than anything I could describe:

"Over 20 years building localization infrastructure at one of Canada's largest software companies taught me a lot. And two projects in particular stick with me because they perfectly show what’s at stake. In both cases, development teams faced the same challenge: launch internationally within six months. The outcomes couldn’t have been more different.

The first team had postponed internationalization for years. When expansion arrived, they discovered hundreds of hard-coded strings, UI components sized only for English, and date logic locked to one locale. The system rebuild consumed months, translators billed extra for fixing inconsistencies, developers spent weeks fixing bugs buried in years-old code… and launch postponement became inevitable.

The second team took a different path from the very beginning. They externalized strings immediately, designed flexible layouts, and introduced pseudo-localization before real translations existed. When launch came, multilingual versions shipped alongside English without any emergency fixes and delays. There was just one difference between both teams: the second treated internationalization as infrastructure rather than something that could wait."

☝️ Internationalize even when you’re not ready to localize 🔗

Let's clear up a common misconception: localization and internationalization are not the same thing. While localization is the output your users ultimately interact with (translated content, adapted formats, and culturally appropriate messaging), internationalization represents the infrastructure that makes localization possible. It's what developers build.

This is why you can't localize a product that hasn't been internationalized, but you can internationalize a product you don't plan to localize yet. And that's exactly where you save money in the long run.

When you internationalize from day one, you're preparing your codebase to support multiple languages and regions even if you only ship in English initially. Basically, when you skip this step, you're building a house without a foundation for the second floor you'll eventually need. 😬🏗️

You can't localize a product that hasn't been internationalized, but you can internationalize a product you don't plan to localize yet. That's where you save money in the long run

Why internationalization debt isn’t "just" tech debt 🔗

Once you understand that internationalization is the cornerstone and localization is the layer that sits on top, the difference becomes clear. With regular technical debt, you're improving something that already works. You might take shortcuts in the dev process to ship faster, knowing you'll tidy things up later.

Internationalization debt is different. You're not making something work better. You're making something work for entire populations who currently can't use your product at all. And the cost of catching up grows faster than most teams expect.

I usually ask development teams a question that makes them uncomfortable:

I'm not being rhetorical. I ask because I've seen what happens when teams finally face that reality. Everything seems manageable at first, and a few hundred code updates might seem like a week of work. 🤷🏽‍♂️ But those updates don't stay contained. They spread across years of feature development, buried in modules developers wrote and forgot about long ago. And as the work multiplies, what looked like straightforward cleanup becomes months of rebuilds that touch every corner of your product and blocks everything else your team needs to ship.

Postponing i18n is a market blocker for SaaS 🔗

No business environment makes the impact of internationalization debt more visible than SaaS, where it directly affects the entire business model. SaaS products live and die by seamless user experience. When someone signs up, they expect everything to simply work for them, regardless of their language or region. If it doesn’t, you lose something more than a single customer: you lose credibility in an entire market.

This happens more often than you'd think. I've tested apps in Arabic that looked polished in English but became completely unusable the moment I switched languages. This didn't happen because of bad translations… the interface literally collapsed when text spilled off screen, navigation broke, and buttons shifted out of view. The product simply wasn't built to handle anything beyond English, and as a result, that company doesn't exist in Arabic-speaking markets.

For SaaS specifically, internationalization debt creates various challenges:

• Releases become nightmares: Every feature you ship needs to work in every language you support. If your infrastructure wasn't built for this, each release becomes a localization project instead of a deployment.
• Users expect real-time updates: Automated translations, even when occasionally flawed, create more trust than delayed "perfect" translations that leave users behind. But automated translation only works when your system can handle it.
• Every friction point multiplies: Poor translations might get a shrug, but poor internationalization breaks the product. That's when support tickets pile up, eating resources and slowing teams down at every touchpoint.

Postponed i18n creates structural problems that become harder and more expensive to unwind later. These issues usually appear small and isolated, but they compound as your product expands

By the time you're ready to 'fix' internationalization, you've already capped your growth. But what exactly falls apart when you skip it?

👻 3 common i18n tech debt horror stories 🔗

My colleague Rémi has identified three specific technical patterns that create the most pain for development teams. These examples stem from real issues he's encountered repeatedly while building localization infrastructure for products serving 24 languages:

1. Hard-coded strings buried in codebases 🔗

This is a classic i18n struggle. Rémi recounts that, during one project, his team discovered the login module alone contained mixed keys like login.button, BTN_LOGIN, and auth.signinButton. Each developer had followed a different pattern. Over time, this created nine separate "Log in" or "Sign in" strings across 14 languages. "Translators billed extra for repetitive content, QA flagged terminology mismatches in every release, and Japanese and German users began telling us they were confused", he says. "The interface language felt inconsistent to them, and they couldn't figure out why the same action had different labels depending on where they were in the application."

"This seemed harmless when the codebase was small. But imagine the refactoring required when that grows to a million lines… Multiply that shortcut by years of feature development = you end up with content scattered everywhere, impossible to extract cleanly when expansion finally arrives."

Once the company standardized the naming into a simple, predictable structure and merged duplicates, the results became concrete: fewer translation units, cleaner code reviews, and a measurable drop in global support incidents tied to inconsistent language.

2. Text stitched together in code that breaks in every other language 🔗

English developers often write constructions like "You have " + count + " new messages". It works in one language, but breaks in almost every other. The pattern simply becomes unmaintainable once pluralization rules, gender, and word order enter the picture.

"After converting these cases into proper message templates with parameters and locale-specific plural logic, the team saw immediate improvements: translator escalations stopped, layout inconsistencies disappeared, and last-minute requests to 'shorten' text for UI constraints became very rare", says Rémi.

3. Architecture that assumes one language 🔗

The third common problem is companies building their entire systems around assumptions that only work for English. This includes module and component interactions, as well as reading direction. This was the case of a settings panel he worked with, which had pixel-fixed widths for buttons and labels. "It was beautiful in English, but completely broken in German and Arabic", Rémi recalls.

To avoid costly one-off fixes, the company introduced pseudo-localization for the next sprint: "Things got way easier then because designers could suddenly see expansion, diacritics, and mirrored layouts in their prototypes before translators touched any files. Everyone involved was relieved they could catch layout issues during design rather than QA. It was a single, small change that shifted the development culture and changed everyone's routines for the better."

Companies tend to build their entire systems around assumptions that only work in English. This leads to problems with UX components and reading direction later on. Prototyping early avoids the problem

🤦🏽 The excuses we hear about early internationalization 🔗

Teams of every size and stage use surprisingly consistent reasoning to postpone internationalization. We hear these frequently:

"We're focused on our local market right now" 🔗

Fair point. But even "local" markets have international users. A Spanish SaaS product will attract immigrants, tourists, and international employees working in Spain. You're already serving multiple languages without realizing it yet.

More importantly, focusing on your local market doesn't mean you'll stay there forever. No one builds a product thinking, "I will never leave this country." Even if your plan is not to expand now, you need to prepare for it. You need to put it in your product plan. Every decision you make going forward should consider how it affects internationalization.

"We don’t have the budget" 🔗

This one is extremely common. What I usually say is that, although you might object with insufficient resources, you actually can't afford not to look into this now, because you won't be able to afford it later. It's just going to be too expensive, and/or will have consequences in your team's capacity and resources (imagine having to face a whole structural revamp of bigger architecture when you finally decide to localize).

"Our developers are overloaded with features and bugs" 🔗

Sure. Every startup is resource-constrained. You're under pressure, releasing new things, fixing bugs, doing things all the time. It's understandable that you may not have the capacity to do it straight away.

But just as you do with everything else in your software stack and in your product plan, you need to weigh out the pros and cons of not doing it now versus spending some time on it to save yourself in the future. It's like preparation for anything. Would you prepare for a camping trip by getting all the stuff you need beforehand, or just figure things out when you get there?

"We're not going international, so why bother?" 🔗

If that's where you want to stay and that's your sole focus, then genuinely don't bother. But honestly, if you ran a business, would you really plan to stay in one country forever?

💭 Questions you should ask before deciding 🔗

If you've worked through the common objections and still aren't sure whether internationalization should be a priority, a few simple questions can clarify your direction.

1. What’s your long-term growth plan? 🔗

Every team says they want to grow, even if they're "focused on the local market" for now. If your roadmap includes expansion beyond your current country, even if it's two years away, you need the infrastructure that makes that expansion possible. Good UX in other languages starts in how you build the product today.

Do you envision going outside of your current market? If yes, then the answer is you have to internationalize. The same way you're building the user experience in the source language, the same way you have to do it for others. Otherwise you won't exist in those markets.

2. Can you afford the scaling cost? 🔗

Your codebase won't stay small. It might feel manageable now, but it usually becomes way more complex as you add features, components, and contributors. You can always internationalize later, but refactoring costs escalate with every update.

Think about your product roadmap for the next two years. Every module, every component you build today either makes future internationalization easier or considerably harder. If it doesn't have proper internationalization, then every time you try to implement a new feature in the languages you want to support, you will come across problems.

3. How much rework are you willing to accept? 🔗

Teams rarely enjoy large-scale refactoring. If your honest answer is "as little as possible", then the most efficient move is building with internationalization in mind from the start. This way you avoid a potential months-long overhaul that freezes other development.

😣 What to do if you already have the debt 🔗

If you've realized your product already carries internationalization debt, don't panic. Many teams learn this late, and it's still completely fixable. What matters now is approaching it methodically.

1. Understand where you are 🔗

The first step is a cliché solution for solving such problems: understand what the problem is. You need to see where you are, what you have and what you don't have.

2. Set a specific goal 🔗

Set a goal for yourself. Say "I want to expand into these specific markets." Pick specific targets. If you want to go to Japan, China, or Egypt, each of these countries has their own requirements and complications because of scripts and writing systems. When you pick specific targets, you get answers and you get a definition of what the specific challenges are.

Once you have those targets, think about what you need if you want to go there now. This question can be answered by someone in your network or by looking online for an expert in internationalization. There are lots of people who can do consultations for this, assess your situation, and give you advice on what can be done and where you can go. Or you can do reading in general. There are so many resources that explain the problems and challenges, like:

• This official Unicode standards guide
• The Unicode CLDR Project
• The complete React Intl docs
• This article about React i18n by Jessy Mussoko
• This hands-on i18n guide by Julia Díez
• This list with Unicode Consortium specialists you can contact

Use whatever resources you have and see how far you can go. But if you get stuck quite early in the process, for whatever reason, then definitely engage a professional consultant

3. Prioritize by impact 🔗

Given the resources you probably have, you're not going to solve the problem straight away. But at least you can make it less problematic and consequently more manageable in the future.

Start with what directly blocks your goals, where it would make the most impact, and how to implement it. You don't have to go all in at once. For example: users can tolerate rough edges in settings screens, but they won’t tolerate a broken signup. Similarly, a bit awkward or unpolished text is likely to have a lower priority than poor navigation causing confusion and zero product adoption.

4. Baby steps are enough 🔗

Start small, learn what works, identify what's difficult, and apply those lessons to the next piece. Bit by bit, build your understanding of what is required. The more you learn about it, the more you'll understand its importance, and the more it will affect your decision to say "okay, now that I know about this, we need to implement it as soon as possible."

5. Use standard solutions 🔗

Everyone internationalizes eventually. It's either the hard way or the easy way. The solution is there. You don't have to reinvent the wheel. You don't have to recreate something specific for you. There are standardized solutions that everyone can use.

You don't need to build internationalization infrastructure from scratch. You just need to be aware, have some prototypes, do some testing. Don't push it to production yet: just keep it there so you know. Spend an hour just learning about this and do a few things to see how it works.

6. Plan like any feature 🔗

Plan it just like any of your features and any of the items on your product plan. Just plan it and see how it would work. Treat internationalization as infrastructure work that enables future features. Put it in your roadmap, assign capacity, set milestones, and track progress. Treat internationalization like the essential work it is, not as a side project developers tackle when they have spare time.

🦺 Start with structure, everything else follows 🔗

I once spoke with a CTO whose video editing product served primarily English-speaking users. They chose not to translate their entire interface into Arabic or Hebrew, but they built their system to handle right-to-left subtitles from day one, because users from those markets needed to edit their own content. That single architectural decision meant they could serve customers in dozens of countries without limiting what those customers could create.

That's what internationalization enables. You don't have to support every language immediately. What you do need are systems that won't break when you add them. When that's done, adding languages becomes routine deployment, not a multi-month project. Expansion happens on your timeline, not when accumulated debt forces your hand.

The companies that succeed internationally are usually the ones who built foundations that made localization straightforward.

Enter Localazy, the modern translation management solution that allows you to translate XCstrings files with ease. And better yet, if you’re feeling lazy (pun intended), it lets you auto-translate XCstrings using the Localazy CLI or API as well.

Let’s take a step-by-step look at how to translate XCstrings files stored in an iOS app using Localazy.

🧐 Why use Localazy to translate XCstrings? 🔗

Before diving into the tutorial, let’s see exactly why you should choose Localazy.

Even though XCstrings somewhat lowered the hassle of dealing with multiple languages, managing localized text usually means endless copy-pasting, manual edits, and even solving merge conflicts that arise.

With its XCstrings built-in support, Localazy lets you:

• Use the Localazy web app or CLI to upload your app’s .xcstrings files
• Translate XCstrings files online using the Localazy editor
• Use its translation memory and machine translation features
• Update and translate new content (continuous localization) through Localazy CI/CD

Localazy lets you focus on your iOS app development instead of making you google “translate xcstrings files” over and over.

➡️ Step-by-step guide: Translating XCstrings files with Localazy 🔗

In this tutorial, we will create a simple iOS app from scratch to demonstrate the whole process.

Prerequisites 🔗

Since XCstrings were introduced with Xcode 15, we’ll need to run Xcode 15 or higher.

Step 1: Create an iOS app 🔗

First off, open Xcode and press Create New Project. For the template, choose App under the iOS tab. Then, give a Product Name (MyAppToTranslate) and an Organization Identifier of your choice. Also, set the Interface as the newer framework, SwiftUI.

Leave the rest of the options as is and press Next > Create.

Our project’s ContentView should already show a traditional “Hello, world!” text added to the app’s UI. But, why not replace it with something that feels closer to real app content we as devs usually deal with?

Text("Welcome back, %@!")
Text("You have %d new message(s).")

This content will help us later when showing how placeholders and plurals behave once localized.

Step 2: Export XCstrings files from Xcode 🔗

Time to bring out the XCstring files:

1. Go to Product > Export Localizations and select your base language (usually English).

2. Give a name for the localizations and press Export to generate and save the .xcstring files, one of which holds our wish-to-be-localized text.

3. Open the Finder and navigate to the directory of your project. There you’ll find another folder with the name we chose when exporting the localizations (MyAppToTranslate Localizations, in my case).

4. Head inside that directory. There you'll find an xloc file (or Xcode Localization Catalog), which is Xcode’s way of packaging multiple XCstring files together. Right-click on it and choose Show Package Contents. Navigate through the folder structure and you’ll find the .xcstrings files. The localizable-xcstrings  file holds the text we’ll send to Localazy for translation.

5. Drag and drop localizable-xcstrings to your project’s root on Xcode, choosing Copy files to destination. Then open the file and you’ll see that the lines we entered earlier are actually keys: one for the greeting and another for the message count.

6. To not leave the value fields empty, fill them with the text in their corresponding key fields.

7. For added convenience, rename the localizable-xcstrings file as en.xcstrings.

Placeholders are the parts of a sentence that change depending on user data, such as %@ for the name and %d for the message count, in our case. When translating, you only change the surrounding text, leaving the format specifiers untouched.

On the other hand, plurals are used when a phrase changes based on a number, such as in the English language, “1 message” vs “2 messages”. XCstrings handles these elegantly. And Localazy keeps those plural rules intact when translating.

If you're new to plurals in software localization, check out this guide to get started

Right now, our “You have %d new message(s).” is just one string. To enable proper singular/plural switching, let’s convert it into a pluralized entry in Xcode:

1. Open en.xcstrings in the String Catalog view (if you see a raw JSON, right-click the file > Open As > String Catalog).
2. Select the “You have %d new message(s).” row.
3. On the Attributes Inspector panel on the right:

• Add Parameter, name it “count”, set Type to Number.
• Add Variation > By Parameter > Count > Plural.
• Fill English forms: one: "You have %d new message." / other: "You have %d new messages."
• Click Save.

If you don’t see the mentioned UI controls in your Xcode, it's time to place the printf-style format specifier pluralizations directly in the en.xcstrings source code instead:

1. In Xcode’s Project Navigator, right-click en.xcstrings > Open As > Source Code.
2. Inside the “strings” section, replace the "You have %d new message(s)." key-value entry as follows:

"You have new message(s).": {
  "extractionState": "manual",
  "localizations": {
    "en": {
      "stringUnit": {
        "state": "translated",
        "value": ""
      },
      "variations": {
        "plural": {
          "one": {
            "stringUnit": {
              "state": "translated",
              "value": "You have %d new message."
            }
          },
          "other": {
            "stringUnit": {
              "state": "translated",
              "value": "You have %d new messages."
            }
          }
        }
      }
    }
  }
}

3. Save your file, then right-click again > Open As > String Catalog to return to the table view.

Step 3: Create a Localazy project 🔗

Now it's time to set up a Localazy project to translate our files.

First up, make sure you’re registered. Even a free account will be enough for our use case. Secondly, create a new project with a preferred name (to keep with the topic, we will use “TranslateXCstrings”).

Step 4: Upload your XCstrings files 🔗

To upload, you have two options:

We can upload and translate the files online using the Localazy Dashboard. Inside your project, click "Drop your source language files" and choose the en.xcstrings file we saved earlier:

For the file format, choose XCode String Catalogs from the dropdown. Then, click Next step > Upload to easily add the file as a source key of the TranslateXCstrings project.

Why restrict to manual methods when you can delegate your work automatically? Say hello to Localazy CLI. To install it, open your terminal and enter the following command:

brew tap localazy/tools
brew install localazy

Afterwards, let’s create a simple localazy.json file in our project’s root directory as follows:

{
  "writeKey": "app-write-key",
  "readKey": "app-read-key",

  "upload": {
    "type": "xcstrings",
    "files": ["en.xcstrings"]
  },
  "download": {
    "files": "Localizations/Localizable.xcstrings"
  }
}

This JSON file acts as the configuration file for our Localazy project.

Along with the upload / download sections that tell which source files to take and where to save the translated files, Localazy CLI requires 2 simple keys for its authentication purposes:

• writeKey: required when uploading our source material (in our case, .xcstrings file) to Localazy.
• readKey: needed to download the Localazy-translated files back to our project.

These authentication keys are generated when we create our project.

To easily find your Localazy project’s authentication keys later on, toggle the left sidebar of your project and navigate to Project settings > Access keys:

Don’t forget to add these authentication key values to your localazy.json file.

Now open your terminal in the project root folder and enter the following command:

localazy upload

If all went well, you should see a successful message as shown below:

Let’s also head over to our Localazy project and see if the source language has been uploaded:

Step 5: Translate your file 🔗

Your Localazy project currently displays all the base strings ready for translation. Our %@ and %d format specifier placeholders stay locked, so we can safely translate around them, whether it's manually or automatically through machine translation.

Let's start with the traditional way:

1. In the Localazy editor, click on Add language on the right side of the table.
2. From the pop-up dialog, choose and add any language you prefer. Untick the Machine Translations pre-translate option for now.

3. Click Translate next to your new language and manually edit the translations on the editor.

4. Now head back to the dashboard to view the two entries and plural forms added for the new language:

Note: Xcode doesn’t watch our browsing habits! We have to inform it that we just created translations to the base strings, which we need to load and use in our "MyAppToTranslate" app. In the project settings, add your new language under Project > Info > Localizations:

Localazy offers automatic translation features, saving you hours of manual work in seconds:

1. Machine translation (MT)

You can choose between multiple MT providers like DeepL, Google Translate, or Azure to translate your iOS files. You can also use Localazy AI (enhanced by Style Guides) for higher tone and brand accuracy.

Depending on your pricing plan, you'll see these suggestions at the bottom of your translation interface. Just click Use this and they'll be automatically applied, or select all your keys from your dashboard and click on Actions > Use Machine Translations to translate your project in bulk. This type of action can also be automated in different ways through the Automations feature.

2. Translation Memory (TM)

Imagine translating a given text in your product once — nothing unusual. Now, imagine translating the same text 10 times, or 100, if not 1,000 times? A pointless, annoying, and costly repetition. Translation Memory lends a hand here by memorizing your previously approved translations and suggesting them when similar text appears elsewhere in your product. Select the translation and save it directly.

Step 6: Download and import back into Xcode 🔗

When you're done, you can ask Localazy CLI to download the XCstrings files by inputting this command:

localazy download

According to the download instructions we set in localazy.json, Localazy CLI will download a Localizations/Localizable.xcstrings file holding both your source and target texts.

Replace the content in your en.xcstrings with the text in the localized XCstrings file you just downloaded. Then open your en.xcstrings in the String Catalog and you’ll see your app now holds both the base strings and their Italian translations:

That’s all it takes! Switching our simulator to the other language and running our iOS app will show the translated text, as intended.

Quick test 🔗

Let’s test this out, shall we?

In the ContentView, replace the existing two Text(...) lines with the code below:

let userName = "Dasun"
let unread = 23

// Load and format localized string with %@
Text(String(format: NSLocalizedString("Welcome back, %@!",
                                      tableName: "en",
                                      bundle: .main,
                                      value: "",
                                      comment: ""),
            userName))

// Load and format localized string with %d
Text(String.localizedStringWithFormat(
    NSLocalizedString("You have new message(s).",
                      tableName: "en",
                      bundle: .main,
                      value: "",
                      comment: ""),
    unread))

These simply fetch the localized text from the String Catalog, then fill in the given variable values, showing the real name and correct plural in the simulator.

？FAQs 🔗

Can I use Google Translate with Localazy? 🔗

Definitely. Localazy can use several machine translation engines so you can get instant translations and tweak them as needed. List of options available here.

Will this work if I’ve got an Android version too? 🔗

Yes. You can manage your iOS translation files (.xcstrings), Android XML files, and other formats under the same project.

How do I check if my translations were imported correctly? 🔗

Change your simulator’s language, rerun the app, and check if the text has switched correctly.

Do I have to pay for all this? 🔗

Depends on your needs. Localazy's free plan is more than enough for personal and small-scale apps, but if you have a larger SaaS project or a product you want to scale internationally, we recommend looking into the platform's paid plans.

Well, it's not that easy.

While building Accesstain (a digital accessibility platform), I've been studying how teams approach multilingual accessibility. What I found surprised me: most companies think they're inclusive when they're actually creating new barriers. The problem is that teams treat accessibility and localization as separate problems when they're really two sides of the same coin.

🫥 Hidden accesibility failures have a cost 🔗

According to the WHO, over a billion people worldwide live with some form of disability. Many others aren't fluent in your primary language or have limited literacy. When you combine language barriers with accessibility needs, the user group grows massive. Yet most teams have no idea how their localized versions actually perform for these users.

Sure, your English site might have passed accessibility tests, got translated, and shipped. But the Spanish screen reader user encounters English alt text. The German user with dyslexia faces sentences twice as complex as the original. The Arabic user finds a right-to-left interface that still thinks like a left-to-right design. What we might consider edge cases are actually predictable failures that happen because our tools and workflows weren't designed for this reality.

Think of a public service: if a healthcare website provides information in multiple languages, the goal is to make sure that patients in those languages can access crucial info about their health. Accessibility often relies on good localization to make services functional and equitable for diverse users.

When you combine language barriers with accessibility needs, the user group grows massive

The bottom line is that a translated product is a more accessible product in principle. But in practice, this holds true only if we localize the right way.

So, why do so many localized products still fall short on accessibility?

⛓️‍💥 Where 'standard' localization breaks down 🔗

Let me start with a harsh truth: just translating an interface or documentation doesn't automatically guarantee an accessible experience. Some common gaps in standard localization workflows can leave people behind. One big issue is what gets translated versus what gets overlooked.

The invisible text problem 🔗

Most workflows focus on visible content (menus, buttons, headlines) but miss the invisible strings that assistive technology depends on:

• 💬 Alt text for images that screen readers announce
• 🏷 ️ARIA labels that explain complex interface elements
• ⚠️ Form field instructions and error messages
• 📹 Video captions and audio transcripts

Translation complexity 🔗

Translators often follow the source text too closely, creating formal or complex versions that hurt readability:

• Simple English becomes legal-document French
• Clear instructions become jargon-heavy German
• Conversational tone becomes corporate-speak in Italian

Design and layout failures 🔗

According to WebAIM's analysis of over a million homepages, 55% of images already lack alt text, and 79.9% have contrast errors before translation, which adds more problems:

• ⬅️ Right-to-left disasters: Arabic or Urdu sites that don't flip layout direction, confusing users and increasing cognitive load
• 📏 Text expansion chaos: German text can be 30% longer than English, breaking interface designs
• 📑 Overflow and overlap: Translated content that gets cut off or covers other elements

📐 To help with that, Localazy has developed a Figma plugin to make sure your designs stay readable and usable in every language

Missing reading level checks 🔗

Standard practices assume accurate translation equals comprehensible translation, but teams rarely verify that reading complexity stays consistent across languages. A user-friendly English interface can become an accessibility barrier in other languages simply due to translation style.

The real cost of siloed thinking 🔗

The core issue runs deeper than missed translations or cramped layouts. Most organizations handle accessibility and localization in completely separate teams, with different tools, different timelines, and different success metrics. The accessibility team tests the English version, the localization team translates the strings, and nobody tests whether the Japanese user with low vision can use the product comfortably.

This separation creates systematic blind spots: the people who understand accessibility best don't speak the target languages; and the people who understand the target languages don't know accessibility requirements. The result are products that are technically multilingual and technically accessible, but actually unusable for the people who need both.

💡 Redesigning localization for real inclusion 🔗

So, how do we close these gaps? It starts with broadening our vision of what localization involves. While researching solutions for an accessibility project, I've studied teams that successfully crack this challenge, whether in travel, e-commerce, or SaaS. The ones that succeed don't treat localization and accessibility as separate processes, they just design them together from the start. Here are some ways an inclusive localization workflow can make a difference:

Write for translation (and for understanding) 🔗

Clear, simple writing in your source language makes everything easier. Everyone understands it better, and translators can keep that clarity when they convert it. Localization experts often read your original text first and suggest changes. They might split up long sentences or replace fancy words with everyday ones.

Rather than being picky about language, this is about making your content work for more people. Simple language helps users with lower reading levels, people learning the language, and those with cognitive differences. Some teams write style guides that translators can use in every language, keeping that friendly, readable feel no matter where their product goes.

Localize all the content, not just the obvious content 🔗

As discussed, a lot of important text lives in places like image alt attributes, form labels, ARIA attributes, error messages, and transcripts. A broader localization vision makes sure these are identified and included in the translation process. You may consider working with developers to externalize those strings into the resource files that translators work on. It also means educating translators about the purpose of these texts.

A lot of important, localizable text lives in alt and ARIA attributes, form labels, error messages, and transcripts. These need to be identified and included in the localization process, and translators need to know their purpose

Translating an error message that's off-screen or a piece of alt text is a bit different from translating a heading; here, one has to understand that context is the key. I'd say that every accessible product needs testing with real users. Get a native speaker who uses a screen reader to try your app. Have them check that buttons, image descriptions, and everything else sounds right in their language. Sure, this takes more time, but it catches problems that would shut out users who rely on these features.

Adapt design and workflows for each locale 🔗

Truly inclusive localization treats UX as more than just words. It asks, "Does this feature or layout make sense and feel natural in this language/culture?" Sometimes, the changes needed are fairly mechanical: enabling right-to-left layouts, expanding UI elements to accommodate longer text, or choosing a font that has good readability in the target script. This makes the interface immediately more usable because it aligns with users' reading patterns.

Familiar visual hierarchy reduces cognitive load for everyone, especially users with cognitive disabilities or those using zoom/magnification. Font choice is another seemingly small detail with a big impact. A font that works great for English might be illegible or just unpleasant in Japanese or Hindi. Apart from that, consider icons and imagery: not all symbols are universally understood. An envelope icon might mean "email" in the US, but could be confusing in a culture where that image isn't associated with messaging. Localization specialists can flag these and suggest more suitable alternatives for their audience (or at least supplement with text labels).

Include local accessibility testing and feedback 🔗

As discussed earlier, one really good approach is to involve users or testers from the target locale who have disabilities during your QA phase. They can provide insights that neither your base-language accessibility testers nor your translators might catch. Maybe in one language, the formal word used for a button is technically correct, but too long for a screen reader to easily speak without cutting off; a native screen reader user could catch that. Or perhaps a color choice that passed contrast checks in English looks different against the longer German text and needs adjustment. Smart localization workflows budget time for this testing instead of hoping one approach works everywhere.

You need to get localization involved from the start of your design process, not bolt it on later. Get your designers, developers, translators, and accessibility people talking to each other while you're building things. I know this sounds like it'll slow you down, but localization tools like Localazy help keep designers, developers, and translators on the same page, without the usual back-and-forth. This saves time, resources, and unnecessary ambiguities. The payoff for this effort is a product that delivers a truly equivalent experience across languages.

🦾 How AI can fix accessibility gaps 🔗

AI could solve the specific multilingual accessibility problems I've outlined, but most teams miss the opportunity entirely. They focus on translation speed rather than fixing the barriers that exclude disabled users across languages. Here's how these tools can directly address the accessibility gaps that traditional workflows create.

Generating accessible content in every language 🔗

Remember the problem of Spanish sites with English alt text? AI can generate image descriptions in dozens of languages instantly. Instead of screen reader users encountering "Close button" in English on a Spanish interface, AI creates proper alt text that reads "Cerrar botón" from the start.

The same applies to ARIA labels, form instructions, and error messages. AI can ensure these critical accessibility strings exist in every target language, not just the visible content.

In the case of Localazy, if you include alt text and accessibility labels in your localizable files, the platform will help you easily identify and translate them accordingly.

Maintaining reading accessibility across languages 🔗

When translations come back overly complex (e.g., turning simple English into formal German legal-speak), AI can flag the reading level mismatch. It can identify when translated content exceeds the cognitive load of the original, alerting teams that users with dyslexia or limited literacy will struggle.

AI can also rewrite complex translations into simpler versions automatically. Rather than leaving translators to figure out appropriate complexity levels for each audience, AI tools can create simplified versions that keep the same readability as the original. These tools spot phrases and cultural references that might confuse people reading in a second language, offering clearer options instead.

Localazy's Style Guide allows you to set tone, formality, sentiment and audience expertise details per language, prompting Localazy AI to automatically follow the instructions you set for any specific audience every time you translate

Catching design-breaking issues 🔗

When German text expands 30% longer than English and breaks your carefully designed interface, AI can predict these problems before launch. You don't need expensive, specialized tools to catch these problems. You can simply feed your design specifications and target languages to your favorite LLM, and it'll flag potential overflow issues, cramped clickable areas, or contrast problems with longer text, all without additional investment.

For right-to-left languages, AI can verify that RTL layouts maintain proper accessibility structure. It can check whether screen reader navigation order makes sense when mirrored, or whether keyboard navigation still works logically in Arabic or Hebrew versions.

Automating multilingual media access 🔗

Speech recognition AI can transcribe audio accurately in many languages and auto-translate captions, making it feasible to provide video accessibility in 10 languages instead of just English. This directly solves the problem of Deaf users being excluded from non-English content.

Even more promising, companies like Signapse use AI to generate sign language translations via digital avatars, creating thousands of signed versions for public announcements and web content.

⚠️ As always, it needs human judgment 🔗

Sometimes AI stumbles where context matters the most. Auto-generated captions that mis-transcribe critical words can be worse than no captions. Translation engines sometimes choose terms that are technically correct but inappropriate for accessibility contexts; like using formal medical terminology when simple language would be clearer.

When Apple used AI alone to summarize news articles, it produced errors that made headlines. The lesson applies here: AI excels at identifying problems, generating starting points and scaling, but human experts must verify that solutions actually work for disabled users in each target language.

Hybrid approaches can make multilingual products truly achievable without a massive resource allocation. Instead of choosing between breadth (many languages) and accessibility depth (proper support for disabled users), you can deliver both

In practice, a winning approach could look like this:

• Teams use LLMs to quickly assess potential problems across multiple languages by describing their interfaces and target languages; asking questions like 'Will this checkout flow have text overflow issues in German?' or 'What cultural accessibility concerns might arise with this Arabic layout?'.
• Human experts then focus their time on the problems AI flagged as most probable, rather than manually reviewing everything. Translators verify whether predicted text expansion will actually break layouts, and accessibility specialists confirm whether flagged navigation issues would really impact users.

🦻 Building systems that work for everyone 🔗

All in all, better translation or better accessibility testing applied in isolation won't solve the problem. Building systems where these disciplines work together by default will. This means that accessibility requirements get automatically included in translation briefs, layout testing includes multiple languages from the start, success metrics account for both language and accessibility barriers, and so on.

This integrated approach benefits everyone: users get experiences that actually work in their language with their assistive technology, teams catch problems earlier when they're cheaper to fix, and products expand to new markets without creating new barriers.

It all boils down to not treat accessibility and localization as separate problems. At the end of the day, the goal is a product that anyone can pick up and succeed with, without frustration, whether they're viewing it in English, Spanish, Japanese, or any other language. If you've invested in making a great product, extending that greatness to all audiences through accessible localization is the natural next step.

👩‍🦯‍➡️ Making it real: 3 accessibility checklists 🔗

If you're shipping in multiple languages, you're already committed to inclusion. The question is whether you're delivering on that commitment. True digital inclusion means users succeed regardless of their language or abilities.

Start by:

• Auditing one key user flow in your non-English versions. Can a screen reader user complete it successfully in Spanish? Does your German interface still work when text expands? Are error messages helpful in Japanese, not just accurate?
• Checking those hidden accessibility strings: the alt text, ARIA labels, and form instructions that assistive technology depends on. If they're still in English while everything else got translated, you found your first fix.
• Testing with real users who speak the target language and use assistive technology. Their feedback will reveal gaps that neither your accessibility team nor translators would catch working separately.

Below you'll find the checklists you can use to make this process easier.

Before you translate 🔗

When translation is in progress 🔗

For final validation 🔗

📋 Free accessibility cheatsheet 🔗

Bottom line is: the tools and knowledge exist to make truly inclusive multilingual products. The question is whether you'll build accessibility and localization integration into your process or keep treating them as competing priorities. Your users in every language deserve experiences designed for their actual needs. When you solve for accessibility and localization together, you create products that truly work for everyone. And that's something worth building.

In this guide, we will explore LinguiJS in depth and demonstrate how to use it with Localazy to handle translation in a React application. We’ll be going through a basic translation workflow, using LinguiJS translation and its i18n support to easily localize your app to other languages.

📋 Prerequisites 🔗

• Install Node.js (v20 or higher) if you don't have it already.
• Install LinguiJS CLI (v5 and higher) using the command npm install --save-dev @lingui/cli.
• It is important to note that Create React App (CRA) is deprecated and no longer recommended. We will be using Vite, which is fast, lightweight, supports TypeScript, JSX, and also modern bundling.

➡️ App setup 🔗

Let’s start with our demo React application. We will be building a user profile dashboard that contains user basic information such as email, location, technologies and a CTA button.

1. Create a new project with the following command:

npm create vite@latest localazy-react-example --template react-ts

2. At this point, we are ready to run our project locally. To start the local development server, visit the url http://localhost:5173/ or run the command:

npm run dev

3. Now that we have our basic React app setup successful, we will be making some updates and edits to some components of our project directory.

The App.tsx file in the root directory should contain the following code snippets. This builds the UI for the user profile and a sidebar that will be used to switch between languages later on.

// App.tsx

import "./App.css";
import UserProfile from "./components/UserProfile";

function App() {
  return (
    <>
      <div>
        <button className="side-bar">
          English
        </button>
        <button className="side-bar">
          Spanish
        </button>
        <button className="side-bar">
          Czech
        </button>
      </div>
      <UserProfile />
    </>
  );
}

export default App;

We need to create a new component called the UserProfile.tsx in the src/components folder. Add an image in the assets folder that can be referenced and imported as the profile image.

// src/components/UserProfile.tsx

import image from "../assets/profileImage.png";

function UserProfile() {
  return (
    <div>
      <img src={image} alt="User avatar" className="logo" />
       <h1>
        Hello Mary Okosun
      </h1>

      <p>
        Email: mary.okosun@example.com
      </p>

      <p>
        Country: Lagos, Nigeria
      </p>

      <p>
        Technologies: React.js, Nest.js, Typescript and Typeorm.
      </p>

      <p>
        Bio: I am a backend developer with extensive experience in designing
          and building scalable, high-performance web applications. I specialize
          in server-side technologies such as Node.js, TypeScript, and Nest.js,
          and I have a strong background in working with relational and
          non-relational databases, including PostgreSQL and MongoDB. I enjoy solving
          complex problems, optimizing application performance, and
          collaborating with cross-functional teams to deliver robust,
          production-ready solutions. I am passionate about continuous learning
          and adopting best practices in backend development.
      </p>
      <button>
        Hire Me
      </button>
    </div>
  );
}

export default UserProfile;

You can find the styling CSS file in the starter project with all the component code on GitHub. You can also see our user profile application below.

🌐 Internationalize a React app with Lingui 🔗

Installation 🔗

The next step is to install LinguiJS for the in-app translation management. Lingui needs a transpiler to work. This transpiler is responsible for transforming Lingui's JS/JSX components into ICU MessageFormat and extracting message IDs. There are two supported transporters, which are the Babel and SWC transpilers. For this project, we will be using the Babel transpiler.

Babel is a JavaScript transpiler that converts modern code into backward-compatible versions and allows custom syntax transformations

Open the newly created project terminal and install the following dependencies:

npm install --save-dev @lingui/cli
npm install --save @lingui/react
npm install --save-dev @lingui/babel-plugin-lingui-macro
npm install --save-dev @lingui/vite-plugin
npm install --save-dev @lingui/format-json

• npm install --save-dev @lingui/cli: If not already installed during the prerequisite stage, this installs the Lingui command-line tool.
• npm install --save @lingui/react: This allows us to use Lingui inside React components.
• npm install --save-dev @lingui/babel-plugin-lingui-macro: This plugin makes the macros work so that Lingui can capture text, replace placeholders, and generate translation catalogs.
• npm install --save-dev @lingui/vite-plugin: This plugin integrates Lingui into the Vite build system, making it compatible with Vite and ensuring message catalogs load and macros work during development and production builds.
• npm install --save-dev @lingui/format-json: This installs the JSON formatter plugin, which is needed if we want to save our extracted messages in a JSON format.

LinguiJS configuration 🔗

Create a new configuration file, .babelrc, at the root directory and add the following snippet:

{
  "plugins": ["@lingui/babel-plugin-lingui-macro"]
}

Make sure to update the file vite.config.ts to include the Babel lingui macro plugin. This is because the @vitejs/plugin-react does not use the Babel config .babelrc created in our project by default. We have to specify the Babel options directly in vite.config.ts:

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import { lingui } from "@lingui/vite-plugin";

export default defineConfig({
  plugins: [
    react({
      babel: {
        plugins: ["@lingui/babel-plugin-lingui-macro"],
      },
    }),
    lingui(),
  ],
});

Next, we will create a Lingui config file lingui.config.ts at the root of our app with the following code:

import { formatter } from "@lingui/format-json";

export default {
  locales: ["en", "es", "cs"],
  sourceLocale: "en",
  catalogs: [
    {
      path: "src/locales/{locale}/messages",
      include: "src",
    },
  ],
  format: formatter(),
};

We are defining our supported locales in the locales array; we’ll use English(en), Spanish(es), and Czech(cs). en is the default sourceLocale.

Inside the catalogs array, define the file path to write the extracted translation messages. Then define an include array of paths where Lingui should look for translations in our code, which is the entire src directory. The format is passed to be in JSON format using the formatter package installed during setup.

Afterwards, we need to do a little modification and add new scripts to the package.json, which will help to extract and also compile our translations. Add the following command:

// package.json

{
   "scripts": {
   	  ....,
      "extract": "lingui extract",
      "compile": "lingui compile --typescript"
   }
}

🗣️ Internationalization 🔗

It's time to prepare our app for content translation. The internationalization process begins with wrapping all our static tags in the UserProfile.tsx file using the Trans tag.

The Trans tag is a JSX Macros that translates React components. It handles translations of messages, including variables and other React components.

Update the UserProfile.tsx file to wrap all static messages and text with the Trans macro tag:

import { Trans } from "@lingui/react/macro";
import image from "../assets/profileImage.png";

function UserProfile() {
  return (
    <div>
      <img src={image} alt="User avatar" className="logo" />
      <h1>
        <Trans>Hello, I am Mary Okosun</Trans>
      </h1>

      <p>
        <Trans>Email: mary.okosun@example.com</Trans>
      </p>

      <p>
        <Trans>Country: Lagos, Nigeria</Trans>
      </p>

      <p>
        <Trans>Technologies: React.js, Nest.js, Typescript and Typeorm.</Trans>
      </p>

      <p>
        <Trans>
          Bio: I am a backend developer with extensive experience in designing
          and building scalable, high-performance web applications. I specialize
          in server-side technologies such as Node.js, TypeScript, and Nest.js,
          and I have a strong background in working with relational and
          non-relational databases, including PostgreSQL and MongoDB. I enjoy solving
          complex problems, optimizing application performance, and
          collaborating with cross-functional teams to deliver robust,
          production-ready solutions. I am passionate about continuous learning
          and adopting best practices in backend development.
        </Trans>
      </p>
      <button>
        <Trans>Hire Me</Trans>
      </button>
    </div>
  );
}

export default UserProfile;

To test that our script is set up correctly, run the following extract command. This command will pull all the Trans wrapped text into translatable files:

npm run extract

The command will create three new files in three locales folders with the different locales as their folder name, as seen below.

⛵️ Localization with Localazy 🔗

Create a new project 🔗

Go to Localazy signup, join our community by creating an account, then create a new project.

You can use the Public project type so other contributors can freely help with the translation of your app. Select English as your source language.

Content upload 🔗

To upload your content, follow these steps:

1. Install Localazy CLI by running the command in our demo app’s terminal:

npm install -g @localazy/cli

2. Afterwards, create a configuration file, localazy.json, in the root folder of your project. Modify the file and include the following snippets:

{
    "writeKey": "your-write-key", 
    "readKey": "your-read-key",
  
    "upload": {
      "type": "json",
      "files": "src/locales/en/messages.json"
    },
  
    "download": {
      "files": "src/locales/${lang}/messages.json"
    }
  }
 

The writeKey and the readKey can be obtained from the Access Keys tab on the project dashboard. These keys are used to authorize your request.

The upload section instructs Localazy CLI on how to collect files to be uploaded. In our project, the type of file we'll upload to the dashboard is a JSON file, which is the src/locales/en/messages.json .

The download section describes how to process translated files and where to write them. In our case, after successful translation, the downloaded translated files will be placed in src/locales/${lang}/messages.json, where lang is the language of the translated file.

3. After setting up your localazy config file, you can go ahead and upload the content to the Localazy dashboard with the command:

localazy upload

Now you can either refresh the browser to see the content or redirect to the project link in the terminal:

4. The next step is to add new languages. In our application, we will be translating our content to Czech (cs) and Spanish(es).

We will find different suggestions provided for us. You can use some of the machine translation options, like Google Translate or DeepL, directly from the translation interface, or for bulk and automated translation of your texts. You can also use Localazy AI if you're looking for a more accurate result that consistently uses your project's glossary, context, and style guide automatically.

The best translation option for your project will depend on your goals, needs, and budget. Check out the documentation on MT, this article about Localazy AI and our translation services guide for more info

Download 🔗

After translating our app, it is time to download the translated phrases.

Run the command in your app terminal:

localazy download

This command downloads all the freshly added languages and newly accepted phrases. We now have the updated translated version messages.json in the es and cs folders containing the translated phrases.

🔄 Translation to different languages 🔗

Lingui introduces the concept of compiled message catalogs. Before we load translated messages into our application, we need to compile them.

We will use the compile command to do this:

npm run compile

We can see that there is a new file, messages.js, for each locale inside the locales/{lang} folder. This file contains the compiled message catalog.

We will now load this file into our app and set the active language to en, and that becomes the default language. Update the main.tsx file to include the following snippets:

import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import "./index.css";
import App from "./App.tsx";
import { I18nProvider } from "@lingui/react";
import { i18n } from "@lingui/core";
import { messages as enMessages } from "./locales/en/messages";
import { messages as esMessages } from "./locales/es/messages";
import { messages as csMessages } from "./locales/cs/messages";

i18n.load({
  en: enMessages,
  es: esMessages,
  cs: csMessages,
});
i18n.activate("en");

createRoot(document.getElementById("root")!).render(
  <StrictMode>
    <I18nProvider i18n={i18n}>
      <App />
    </I18nProvider>
  </StrictMode>
);

The App.tsx should also be updated as below. This introduces the onClick function that includes the functionality for switching languages.

import { i18n } from "@lingui/core";
import "./App.css";
import UserProfile from "./components/UserProfile";

function App() {
  const switchLanguage = (lang: string) => {
    i18n.activate(lang);
  };

  return (
    <>
      <div>
        <button className="side-bar" onClick={() => switchLanguage("en")}>
          English
        </button>
        <button className="side-bar" onClick={() => switchLanguage("es")}>
          Spanish
        </button>
        <button className="side-bar" onClick={() => switchLanguage("cs")}>
          Czech
        </button>
      </div>
      <UserProfile />
    </>
  );
}

export default App;

✔️ Conclusion 🔗

In this article we demonstrated how to use Localazy and LinguiJS to localize a React application. Localazy is a powerful tool that makes translating applications faster, easier, error-proof, and more fun.

Now, you can download the repository with the demo project to explore it. If you have any questions, check out the Localazy documentation about the React integration or drop the team a line for quick support.

WhatsApp functions as the second most popular immediate entry point to the internet for hundreds of millions of Africans, according to a Rest Of World report. In Kenya, South Africa and Nigeria, 95-97% of mobile internet users use WhatsApp, making it a foundational part of the continent’s digital experience. As users already communicate there in their native languages, WhatsApp-based services are expected to do the same. A GSMA report on mobile internet adoption in Sub-Saharan Africa shows that many first-time and low-literacy users will disengage from digital services if content isn't in their native language.

💬 Why is WhatsApp the most popular digital platform in Africa? 🔗

Africa is the world's most linguistically diverse region, with more than 2,000 languages spoken across 54 countries. This diversity runs up against uneven connectivity, low-spec Android phones, and expensive data for connectivity. When users find a single, lightweight messaging app with free or cheap bundles from telcos, it becomes a staple. For Africans, WhatsApp is:

• Compatible with low-end smartphones.
• An image and media compressor that can still retain much of their quality.
• Where families, churches, trade groups, school alumni, and political campaigns thrive.

Analysts at Business Report described WhatsApp as a digital lifeline for the developing world and a core part of Africa’s tech evolution. It continues to prove to be so. With the launch of its successful business optimized version, WhatsApp Business, this means in practice that:

• Small shops can manage catalogs, orders, and delivery entirely by chat.
• Health workers in Southern Africa can improvise hospital systems through WhatsApp referrals when official tools fall short.
• New AI services can launch first as WhatsApp bots because that’s where users actually are.

For the longest time, WhatsApp Business used to be small-scale vendors leveraging its catalogue options and automated responses to showcase and manage their businesses. Now, full-scale startups are building their entire programs on WhatsApp.

📲 The African tech startups building on WhatsApp 🔗

From payment systems to veterinary services and fully-embedded e-commerce stores, these startups want to reach as many customers as possible on WhatsApp.

Doorcas’ veterinary proposition 🔗

Doorcas started with a web app but farmers wouldn't use it no matter how simplified they made it. “Right now on our web app, you only need your phone number and a password to set up an account,” founder Abayomi Olode says. “But people still don't use it. We thought of something they'd be more familiar with and realized it was WhatsApp. They feel that it is faster and they already use it well.” In Nigeria, where 40% of all households keep livestock and where WhatsApp penetration exceeds 90% among smartphone users, it seemed the most realistic option for Olode and his team.

Once the company became WhatsApp-based, farmers could reach them with a simple text. They are able to report issues, share pictures, or even send videos of sick animals directly through the app, which Doorcas logs into their system. “We couple their shared information with AI algorithms to predict diseases before they occur,” the founder explains. The company’s strongest hook is a free physical farm consultation, something that instantly builds affinity. “It is our best USP yet.”

“On our web app, you only need your phone number and a password to set up an account. But people still don't use it. We thought of something they'd be more familiar with and realized it was WhatsApp. They feel that it is faster and they already use it well” - Abayomi Olode, CEO of Doorcas

Nigerian farmers rely heavily on emotional cues in conversation, so while quick replies help Doorcas handle simultaneous emergencies, they never let automation dominate. “We jump in as fast as possible so they know there’s a real human behind the message.” Many users switch between Yoruba, English, and Pidgin as they talk, expecting the responder to mirror them. “If you speak English only, they don’t feel like you can understand their problems,” Olode explained. “But once you switch to the local language, then they want to have sincere conversations.”

As Doorcas expands to Northern Nigeria, language becomes even more complex. Their Kaduna-based vet speaks Hausa, yet still struggles with deeply indigenous dialects. “She told us the Hausa there is so deep, she must listen very attentively to understand,” Olode says. Many times, they’ve had to bring in local translators to ensure that context is not lost during conversations. In Hausa or Yoruba, words can be spelled the same, but carry entirely different meanings depending on pronunciation.

The company also uses a reminder system which helps farmers vaccinate at the right time, Olode adds, despite many farmers not believing in vaccines.

Set up a quick shop with Ghala 🔗

For many business owners in East Africa, WhatsApp is a checkout platform, says Daniel Kalebu, founder of WhatsApp-based e-commerce shop, Ghala. “Social platforms help attract buyers, but the actual sale nearly always moves to WhatsApp,” he states. “To us, this is where negotiation happens, trust is built, pictures are shared, and orders are confirmed,” he explains. But despite this massive behaviour shift, WhatsApp commerce remained painfully slow. The startup currently serves all types of small online businesses and all orders, questions, and verifications had to be handled manually. “This process didn’t scale well with marketing and eventually, merchants simply couldn't keep up the traffic.”

Ghala introduced an AI layer to replicate what a human seller typically does: answer questions, recommend products, build carts, confirm payments, reconcile orders, etc, but at an infinite scale. Their system now automates about 98% of customer interactions, and only triggers an escalation when human attention is genuinely needed. “If there’s something that requires the merchant’s eyes (a complaint, an angry customer, or a very custom order), the system notifies the business owner to jump in,” says Kalebu.

“Social platforms help attract buyers [...] Whatsapp is where negotiation happens, trust is built, pictures are shared, and orders are confirmed” - Daniel Kalebu, Founder of Ghala

The company has integrated features like WhatsApp Flows, which allows them to render complex forms and menus. In fact, by using Flows for a ticketing client, they were able to reduce the entire booking time from ten minutes to about two. Kalebu likens it to an emerging “Play Store of the future”. The Ghala Merchant App extends this further by giving sellers analytics, chat monitoring, and even in-store POS functionality.

Whatsapp for conversational payments in fintech 🔗

WhatsApp-based services are even more strengthened within the fintech sector, where users expect services to be instantaneous and confidential:

1. Semoa, a Togolese fintech, developed Express Cash by Semoa on top of WhatsApp to turn simple chats into full banking processes for Ecobank customers in Togo. It also operates in the wider West African Economic and Monetary Union (WAEMU) region. Customers text a WhatsApp bot called Dédé to generate tokens with which they can withdraw cash at ATMs, pay bills, or transfer money across borders.

2. In partnership with Clickatell, Yabx is a digital lending company providing WhatsApp-based microloans to Africans. It uses a simple chat flow through which customers can request, receive, and manage credit in real time from WhatsApp. There's no need to download another app or fill difficult web forms. In regions with little access to formal credit systems, this chat-first lending model makes short-term borrowing seamless.

3. OWO, built by Nigerian open-banking company Mono, uses WhatsApp as a payment pillar for everyday transactions in Nigeria. Users link their bank accounts once; then they can send money, pay bills, and do business from WhatsApp with text, images, or even voice notes, with OWO converting those messages into secure transfers. Tech Cabal reports it has already processed over ₦1 billion in volume. In the same article, Mono’s CEO Abdulhamid Hassan shared that it's a way to tap into the needs of tens of millions of Nigerians who already discuss money on WhatsApp but don’t want another banking app.

4. South Africa's Mama Money extends its low-fee international remittance service into WhatsApp. Low-income users can register, send money, manage a Mama Money Card, and handle support via dedicated WhatsApp numbers instead of relying solely on an app or branch. The company has collaborated with Access Bank and Paymentology to let users transfer funds internationally, buy electricity and airtime, and check balances inside the chat with their WhatsApp-powered card.

📦 WhatsApp’s features are reshaping product design 🔗

Founders Olode and Kalebu both say it's easier to build around established behavioural cues than to create new ones. Nothing is more established across Africa than the muscle memory that comes with using WhatsApp. This is why product teams are now building solutions that feel chat-based, mimicking WhatsApp’s flow, and centering conversational interfaces instead of traditional screens and menus.

One example is Kowri's voice pay option, where users can pay for bills and send money using voice commands. This works not only in English but also in two other local Ghanaian languages: Twi and Hausa.

In francophone West Africa, Julaya leans heavily on conversational design for merchant onboarding. It replaces long form text sequences with short, question-and-response ones, as you'll see on WhatsApp.

Ghana’s ZEED and Nigeria’s Bumpa have similarly structured merchant actions (think inventory updates to sales confirmations) as chat bubbles that slide up the screen instead of typical modal windows.

Even mobility and logistics apps are following suit. MAX, a Nigerian mobility platform, redesigned its driver app to function like an active chat window: real-time updates about rides appear as stacked message blocks, while driver support and safety alerts are delivered through a WhatsApp-like conversation thread.

Voice notes are taking over long input fields. Single-screen conversational flows are replacing multi-page onboarding. Buttons are getting smaller, rounder, and more “WhatsApp-shaped.” Even features like inline images, quick-reply chips, and tap-to-share locations are becoming standard, regardless of industry

🤔 Is it worth building around a WhatsApp culture? 🔗

Short answer is yes. WhatsApp has set the behavioural baseline for how Africans expect to interact with digital services: simple chat-flows, minimal typing, fast media sharing, clear prompts, familiar layouts, and immediate human-like responses.

Any product that ignores this risks heavy user drop-off, costly onboarding, and low trust. To mimic WhatsApp’s interaction style is to gain instant usability, faster adoption, and access to millions of users who prefer chat-based navigation over traditional app interfaces. Digital literacy varies widely across countries, but data costs remain high-end consistently. A WhatsApp-like design can prove highly efficient.

👉 How to start localizing for WhatsApp-first African markets 🔗

Here are some important points to consider when building for a WhatsApp culture:

1. Interface flows should mirror chat over traditional apps 🔗

African users prefer conversational navigation. Consider replacing long forms with question-and-answer flows, status updates with message bubbles, and dashboards with simplified threads.

2. Localize language, but also tone 🔗

African customers judge products heavily by how natural they sound. A Hausa prompt that’s too formal or a Twi instruction that uses a wrong tonal mark can immediately break trust and question brand authenticity. Tone-aware localization is non-negotiable here.

3. Prepare for code-switching as the norm 🔗

Many African users will switch between languages (and even sometimes dialects) mid-chat. Products must be ready for multilingual UI support.

African users value conversational navigation and highly localized interactions. They also code-switch frequently. You need to consider these preferences when building for them

4. Use localization tools early in product design 🔗

Instead of bolting translation on at the end, foreign innovators need to design language-first workflows that enable them to upload text prototypes, test UI tones across multiple markets, and refine the interface before shipping through localization testing.

5. Make trust the core of expansion strategy 🔗

WhatsApp works in Africa because it feels personal, informal, and direct. As a foreign innovator (introducing a foreign product), you will need to recreate this emotional familiarity, not just functional parity. A trustworthy localization tool will be central to achieving this trust at scale.

💙 How can Localazy support startups building for WhatsApp-first localization? 🔗

Localazy offers a range of contextual tools that can position you as a human-front service even when you only automate. Here are some features I've noticed that can help whether you localize for WhatsApp or not:

1. Static UI text localization 🔗

These are the buttons, menus and labels inside chat-like interfaces that give your users a dynamic communication experience: “Send Message,” “Order History,” “Mark as delivered.” Localazy can handle these by providing consistent translations across Yoruba, Hausa, Swahili, Xhosa, Zulu, Amharic and more, ensuring the UI matches local communication norms and that different word lengths don't break the design (for example, via their Figma plugin).

2. Quick replies and predefined prompts 🔗

WhatsApp-like interfaces depend on ready-made chat snippets such as: “Welcome to [company name] support, how can we assist?" or "Would you like pay with [Apple Pay] or [Visa]?" Localazy allows teams to create a Glossary for their brand that ensures these terms are not translated and kept in context.

📩 If you prefer using helpdesk platforms instead of building your own chat-like UI, you can also localize your user comms with Localazy's Intercom and Zendesk integrations

3. Multi-language chat flows 🔗

If you're building a chat-based interface similar to WhatsApp Business, like step-by-step onboarding, or basic Q&A prompts and structured requests, Localazy can help you build a consistent flow. It helps developers set the intended tone (friendly, neutral, concise, professional) via Style Guide, with Localazy AI preserving it across all target languages.

5. Context-aware localization 🔗

Localazy’s context features, like translation notes, comments, or screenshots, allow startups to show where text will appear: on a chat bubble, as a quick reply, or in a confirmation message. Users don't want literal translations that ignore tone, dialect or their previous chat behaviors.

6. Industry-specific terminology 🔗

Lastly, every industry has its unique jargon/lingo. Again, Style Guides and Glossary help here by ensuring the correct terms are used consistently and contextually, even when users switch languages mid-conversation.

☝️ Before you start 🔗

Articulate Rise 360 uses a specialized XLIFF format. If your upload fails or import doesn't work, check if you’ve selected the correct format variant, as XLIFF detection isn't always automatic. If the format is not the issue, contact our support and we'll help you identify the real cause.

Step 1: Duplicate your course in Rise 360 🔗

Each language requires a separate Rise 360 course because the platform doesn't support multiple languages within a single course file.

Rise 360 treats each language version as an independent course with its own XLIFF export. Before exporting:

1. Open your source course in Rise 360.
2. Duplicate it for each target language (e.g., "Course_DE", "Course_FR").
3. Keep the original course structure unchanged.

Step 2: Export XLIFF files 🔗

Now, export both content and labels separately. Rise 360 stores course text and UI elements in different files, requiring two exports per language to capture all translatable content.

Open the duplicated course and:

1. Go to Settings > Translations tab.
2. Click Export XLIFF file.
3. Enable Include HTML formatting (recommended).
4. Save to your computer.

In the same course, click Settings and:

1. Select the Labels tab.
2. Click Export labels as XLIFF.
3. Save separately.

You'll get two files per course: content.xliff and labels.xliff.

Repeat this export process for each target language duplicate. Each course must go through its own export-translate-import cycle because Articulate Rise validates that imported XLIFF files match their original source. Even though your duplicates are identical in content, their XLIFF files have different keys, which will cause a mismatch with Rise's import system.

This means you'll create separate Localazy projects for each target language. To share glossaries and translation memory across your projects and avoid duplicate setup work, you can use Localazy's Connected Projects feature.

Step 3: Upload to Localazy 🔗

The process is easy:

1. Sign up or log in to Localazy.
2. Create a new project.
3. Upload both XLIFF files (content + labels).
4. Add target language.

Localazy will parse the files, extract translatable strings, and prepare them for translation while preserving Rise 360's structure and formatting. Remember to pick the Articulate Rise 360 XLIFF format from the file format dropdown.

Step 4: Add context & translate 🔗

Before you translate everything, it is highly recommended you fill in they project's Context assets.

• Style guide tells your translators and Localazy AI how your content should feel.
• Glossary terms to maintain consistent terminology. This is especially important for courses!

When your context is prepared, it's time to use Localazy's translation features.

You can translate on your own, or with help from your team using the interface, but there are some helpful approaches to consider as well:

• Localazy AI for context-aware automated translations.
• Professional human translation can be ordered directly on the platform as well.
• Translation Memory to reuse existing translations across multiple courses.

When your courses are translated using the method/s you prefer, Localazy will validate the XLIFF structure automatically. Fix any flagged validation issues before downloading to ensure a successful Rise 360 import.

Step 5: Check validity before download 🔗

Before downloading, verify that all translations pass XLIFF validity checks. Rise 360 rejects files with structural errors, so catching these issues in Localazy saves time and prevents failed imports.

For this, go to the language table view and:

1. Use the filters and select Invalid translation to display results with a detected issue.
2. Fix flagged problems (usually HTML tag mismatches or missing placeholders).
3. Make sure that all translations are complete.

The most frequent problem with translated Articulate Rise XLIFF files involves broken or mismatched XML/HTML tags. Rise exports often contain nested <g> (group) elements with various ctype attributes representing different HTML structures.

Example of a typical Rise XLIFF structure:

<g ctype="x-html-DIV" id="3kRw9m2XLbcfjtNQ" xhtml:content-editor-id="f8e7a4d2-129b-4c6e-b892-543f89cd21a5" xmlns:xhtml="http://www.website.org/2026/xhtml">
  <g ctype="x-html-P" id="yHPQ4rWKNtx8DZaL">
    <g ctype="x-html-STRONG" id="9F7NK43_pAAwd5tu">
      Customer onboarding: Best practices for success
    </g>
  </g>
</g>

When translating, these nested tags must remain intact and properly closed. Frequent issues include:

• Opening a <g> tag without closing it.
• Accidentally deleting closing tags during translation.
• Breaking the nesting hierarchy (closing tags in wrong order).

Localazy's built-in validation helps catch these structural errors before they break your course import.

Step 6: Download translated files 🔗

Once translations are complete and validated, download the XLIFF files from Localazy. The exported files maintain Rise 360's required structure and are ready for direct import back into your duplicated courses.

1. Go to File management in Localazy.
2. Click Export & download.
3. Save the translated XLIFF files to your computer.

Step 7: Import back to Rise 360 🔗

Import the translated XLIFF files into the duplicate courses you created in Step 1. Rise 360 will populate the course structure with translated content, creating fully localized versions ready for publishing.

Open the duplicate course created in Step 1:

1. Go to Settings > Translations tab.
2. Click Import translated text.
3. Select your translated content file.
4. Rise will process and apply translations automatically.

If import fails with validation errors, return to Localazy to address any remaining HTML tag issues flagged in the validation panel, then re-download and try again.

After importing content, import translated Rise's UI elements (buttons, navigation, etc.):

1. In the same course, go to Settings > Labels tab.
2. Select your target language from the dropdown menu.
3. Rise automatically applies standard label translations.
4. Review and customize labels if needed.

If certain text blocks still appear untranslated after import, they likely weren't included in the original XLIFF export. Custom blocks (currently in beta) and some embedded elements may not export to XLIFF format.

Check your Localazy project to verify if the missing text exists there. If not, simply add translations to these blocks manually in Rise.

🔄 Common workflows 🔗

One-time course translation 🔗

Follow steps 1-7 once per language. Keep exported XLIFF files as backups.

Ongoing course updates 🔗

Use Articulate Rise 360 templates and Rise examples as starting points. When updating courses, re-export the XLIFF file and upload to Localazy. Unchanged segments will reuse existing translations automatically.

Multi-course programs 🔗

Leverage Translation Memory across all Articulate Rise tutorials and training materials to maintain consistency without re-translating common content.

💡 Need more info about Localazy's e-learning localization features? Check out this guide

🖇️ Quick tips 🔗

• Always enable HTML formatting when exporting from Rise 360.
• Fix the validity issues in Localazy before downloading.
• Test import with one language before translating all languages.

💬 Need help? 🔗

If you encounter upload failures, import errors, or validity issues, contact our support team.

Happy localizing! 📚💙

In this third and final part of the series, you will connect your Angular app to Localazy, upload your base English translations, and pull in additional languages like French. You’ll also add a pseudo-locale to visually test missing or truncated text, and use ICU messages to handle plurals and gender variations seamlessly.

By the end of this guide, your app won’t just be multilingual but it will also be localization-ready, QA-proof, and production-strong.

🧩 Integrate Localazy into your Angular project 🔗

Now that runtime i18n is working and your JSON files live in public/assets/i18n, it’s time to connect your Angular app to Localazy so translations can sync automatically without endless copy-paste.

1. Install the CLI locally 🔗

npm i -D @localazy/cli

2. Get your project keys 🔗

Log into your Localazy account and open the Integration overview > Angular section to grab your keys.

On the next screen, you’ll see your Write key and Read key. Copy both or save them, as you’ll paste them into the Localazy config in the next step.

3. Set up the Localazy integration 🔗

You’ve got your keys — now let’s tell Localazy where your Angular i18n files live and how to sync them.

Create localazy.json (project root):

{
  "project": "invoice-pwa",
  "upload": {
    "type": "json",
    "files": [
      { "path": "public/assets/i18n/en.json", "lang": "en", "tags": ["app"] }
    ]
  },
  "download": {
    "files": [
      { "path": "public/assets/i18n/${lang}.json" }
    ]
  }
}

This minimal integration pushes English and pulls French right back into public/assets/i18n.

4. Keep your API keys out of Git 🔗

Create a tiny keys file you do not commit:

localazy.keys.json (root)

{ "writeKey": "YOUR_WRITE_KEY", "readKey": "YOUR_READ_KEY" }

Add to .gitignore:

localazy.keys.json

You’ll use Write Key for uploads and Read Key for downloads.

5. Upload EN and download 🔗

Run this command from the project root to push your English source strings to the Localazy platform:

npx localazy upload -k localazy.keys.json

You’ll see your project with English source strings in the dashboard as seen below. From there, simply add French as a second language. This will be your first target locale.

Translating is easy: just click the Translate action in the interface to auto-translate everything in one go. You'll need to select a translation provider. Localazy currently offers:

• Localazy AI
• Google Translate
• DeepL
• Amazon Translate

In a moment, you'll be able to see your translated strings:

Once the translation is done, you can open the Review tab to go through each string and make quick edits if needed before approving them for production.

With Localazy, you can directly upload and download your source strings to the platform from the File management section:

Once FR has content, download it:

npx localazy download -k localazy.keys.json

Note that this will overide the manual strings you inserted in the first part of this tutorial.

You should now have this:

public/assets/i18n/fr.json

Verify in your Angular app. Start the dev server:

npm start

Now toggle the EN/FR button in your app. You should see the fresh strings from fr.json.

⛓️‍💥 Test using a pseudo-locale 🔗

When localizing apps, engineers often struggle to spot missing or broken translations early. Localazy solves this with a pseudo-locale (qps), which automatically lengthens text and adds markers to highlight untranslated or clipped strings.

By mapping it in your config, you can quickly switch to “qps mode” in Angular and visually test layouts before going live, a simple best practice that keeps your localization clean and reliable.

1. Select your custom locale 🔗

In the language picker, search for Custom locale and choose Custom Locale (xxc):

Then select the language:

2. Seed and map it 🔗

Now that you have added the custom locale, seed it by copying the English strings into it for testing (since Localazy won’t download an empty language):

To test your translations visually using a pseudo-locale, make the mapping explicit in your configuration:

{
  "upload": {
    "type": "json",
    "files": [
      { "pattern": "public/assets/i18n/en.json", "lang": "en", "path": "public/assets/i18n" }
    ]
  },
  "download": {
    "files": [
      { "output": "${path}/${lang}.json" }
    ],
    "langAliases": {
      "xxc": "qps" // map Localazy's pseudo code to your local "qps"
    }
  }
}

3. Add it to your project 🔗

Run this command to download the custom locale to your project:

npx localazy download -k localazy.keys.json

You should now have:

public/assets/i18n/qps.json

This writes public/assets/i18n/qps.json thanks to langAliases.

Now, allow it in the language service. First, widen your accepted languages so qps is treated like any other locale in src/app/core/language.service.ts:

type Lang = 'en' | 'fr' | 'qps';          
private readonly supported: Lang[] = ['en', 'fr', 'qps'];

Then expose it to the app shell so the header can switch to qps.

Also update it in app.ts:

import { Component, signal } from '@angular/core';
import { RouterOutlet } from '@angular/router';
import { LanguageService } from './core/language.service';

...

export class App {
 
 ...

  // Public API for the template
  setLang(code: 'en' | 'fr' | 'qps') 
    this.lang.use(code);
  }
}

Finally, add a tiny “QA” toggle in the header:

<button type="button" class="btn-secondary" (click)="setLang('qps')">QA</button>

4. Test it 🔗

To test your pseudo-locale visually, open your Localazy dashboard, pick the custom locale you created (xxc → qps), and edit one of the strings; for example, change “Install app” to something playful or slightly distorted like “Ĭńşţāĺľ āƥƥ [QA]" and download.

When you run your app, this will make it easy to spot pseudo-localized text in the UI, stretched, accented, or bracketed. It helps you quickly identify layout issues, missing translations, or clipped text that might not be obvious with regular English or French.

Another example on the usefulness of this method is German translations, which are usually longer and might stretch or distort your UI. Instead of waiting for actual translations, you can spot problems like overflowing text or clipped buttons by switching to a pseudo-locale such as qps. It automatically adds accents, brackets, or longer versions of your English text, helping developers and designers ensure that every label, form, and button stays readable and responsive across all languages.

When it's time to test the content, just run npm start, switch between EN / FR / QA, and make sure the QA text looks weird (accents/brackets) to confirm that pseudo-locale is working.

Your next move is to enable ICU syntax so your app can handle real-world plural and gender cases cleanly with ngx-translate.

👭 ICU for plural and gender support 🔗

With a tiny tweak to your Angular config, ngx-translate will be able to understand ICU syntax, so instead of awkward “1 items” or “0 invoice,” your app will speak like a real person. After this change, your JSON files will handle smart plural and gender rules automatically with no extra logic needed. Let's see how.

1. Add imports 🔗

Add these imports at the top of src/app/app.config.ts:

import { TranslateCompiler } from '@ngx-translate/core';
import { TranslateMessageFormatCompiler } from 'ngx-translate-messageformat-compiler';

// Then, in your providers array, drop this in (keep everything else as-is):
{ provide: TranslateCompiler, useClass: TranslateMessageFormatCompiler },

Now your translations can do smart things like this:

{
  "itemsCount": "{count, plural, =0 {No items} one {# item} other {# items}}"
}

Let’s put it to work. Add this new ICU message to your English file:

public/assets/i18n/en.json

{
  "dashboard": {
    "resultsPlural": "{count, plural, =0 {No invoices} one {# invoice} other {# invoices}}"
  },
  "invoice": {
    "view": {
      "itemsCount": "{count, plural, one {# item} other {# items}}"
    },
    "due": {
      "relative": "{state, select, today {Due today} future {Due in {count, plural, one {# day} other {# days}}} past {Overdue by {count, plural, one {# day} other {# days}}}}"
    }
  }
}

2. Enable plural_icu 🔗

Localazy supports several plural formats and needs to know which one you are using. By default, Localazy treats JSON keys as plain strings. To make it detect ICU plural patterns like:

{count, plural, one {...} other {...}}

You must enable the plural_icu feature in your localazy.json:

{
  "upload": {
    ...
    "features": ["plural_icu"]
  }
    ...
}

3. Push the source and add translations 🔗

Push your English source to Localazy:

npx localazy upload -k localazy.keys.json

That seeds Localazy with public/assets/i18n/en.json.

Now open your Localazy project, search for the resultsPlural, itemsCount, and relative and add the corresponding French strings:

Then pull the translation back:

npx localazy download -k localazy.keys.json

You should now have fresh files like:

public/assets/i18n/fr.json
public/assets/i18n/qps.json

4. Test it 🔗

Now let’s fire up the app and make sure the ICU plurals, relative due labels, and all the counts behave as expected across screens. We’ll look for natural copy (“0/1/N invoices”), correct item counts on the Invoice View, and clean “Due today / in # days / # days ago” messages, so you should not see any awkward or clipped text.

Drop this in src/app/features/invoice-view/invoice-view.html under the table, before “Notes + totals”:

<!-- Items count (ICU plural) -->
<div class="mt-3 text-sm text-gray-600">
  @if (invoice(); as inv) {
    {{ 'invoice.view.itemsCount' | translate : { count: inv.items.length } }}
  }
</div>

Add a date helper plus two small methods to turn it into a readable label.

Create the date util src/app/core/utils/date.ts and paste the code below:

export function daysDiffFromToday(isoDate: string): number {
  const d = new Date(isoDate);
  if (isNaN(d.getTime())) return 0;
  const today = new Date();
  // compare at local midnight so timezones don’t skew the count
  const start = new Date(today.getFullYear(), today.getMonth(), today.getDate()).getTime();
  const end   = new Date(d.getFullYear(),     d.getMonth(),     d.getDate()).getTime();
  const msPerDay = 24 * 60 * 60 * 1000;
  return Math.round((end - start) / msPerDay); // >0 future, 0 today, <0 past
}

Use it in the dashboard component src/app/features/dashboard/dashboard.component.ts.

import { daysDiffFromToday } from '../../core/utils/date';

Add inside the class:

dueState(inv: Invoice): 'today' | 'future' | 'past' {
  if (!inv.dueDate) return 'future'; // missing dueDate = no warning
  const d = daysDiffFromToday(inv.dueDate);
  return d === 0 ? 'today' : d > 0 ? 'future' : 'past';
}

dueCount(inv: Invoice): number {
  if (!inv.dueDate) return 0;
  return Math.abs(daysDiffFromToday(inv.dueDate));
}

Render the label in each row on src/app/features/dashboard/dashboard.component.html inside each list item, right under the top row’s <div class="flex items-center gap-3">…</div>):

<div class="mt-1 text-xs text-gray-500">
  @if (inv.dueDate) {
    {{ 'invoice.due.relative' | translate : { state: dueState(inv), count: dueCount(inv) } }}
  }
</div>

Restart the app and check the Dashboard.

In our test, the total count reads naturally “Aucune facture / 1 facture / N factures” in French, or "No Invoice / 1 Invoice/ N Invoices" in English. Each row should show a clear due label (“Échéance aujourd’hui / dans # jour(s) / en retard de # jour(s)”), and on the Invoice View, the items counter reflects the right plural (“# élément(s)”).

An important point I want to mention is that you should be extremely careful when translating ICU plurals. I accidentally removed the other branch from the outer select. The build blew up with: “No 'other' form found…” from ngx-translate-messageformat-compiler.

And my frontend shows this:

The fix was simply to add an other fallback (even empty) and ensure braces are balanced.

？ FAQ 🔗

How do I switch languages at runtime? 🔗

We use ngx-translate with an HTTP loader and a tiny LanguageService that calls translate.use(lang) and persists the choice in localStorage. No rebuilds needed.

Why not Angular built-in i18n? 🔗

Angular i18n is great for compile-time translations, but it requires rebuilds. ngx-translate enables runtime language switching and works smoothly with the Localazy sync. Also, Angular built-in i18n uses XLF, and here we choose JSON + ngx-translate for runtime switching.

How does Localazy fit in? 🔗

Localazy manages source strings, machine/human translation, reviews, and pushes/pulls JSON via CLI. We upload en.json, translate fr, (optionally) add a pseudo-locale, and then download into public/assets/i18n.

What’s the "pseudo-locale (qps)" for? 🔗

It exaggerates text length and adds markers so you can spot clipped or untranslated strings. It's super helpful for stress tests without having to wait for real translations.

Do I need to list "languages": [...] in localazy.json? 🔗

No. Omit it to download all available locales. Add it only if you want to limit downloads (e.g., ["fr","qps"]) for predictable outputs.

How do ICU plurals/gender work here? 🔗

Enable the messageformat compiler and write ICU messages in your JSON (e.g., {count, plural, one {# item} other {# items}}). This keeps grammar natural across languages.

Will translations work offline in the PWA? 🔗

Yes. Production builds cache /assets/i18n/*.json via Angular Service Worker, so language files remain available offline.

Why a signal-based store instead of NgRx? 🔗

Signals give you lightweight reactivity for CRUD, selectors, and local persistence without a boilerplate. You can always upgrade to NgRx if the app grows.

How do I export/import data safely? 🔗

Use Export JSON for backups and Import JSON to replace/merge (sanitized via serializers). Export CSV gives you invoices and line items for spreadsheets.

Any Tailwind 'gotchas' with localization? 🔗

Prefer fluid layouts (flex, grid, gap, min-w-0, break-words) and avoid hard width caps on labels/buttons. Pseudo-locale is your friend for catching overflow early.

Can I deploy under a sub-path (e.g., /invoice-pwa/)? 🔗

Yes. The HttpLoaderFactory (for @ngx-translate/http-loader) uses document.baseURI, so translation files resolve correctly when your app is served under a <base href="/subpath/">.

📚 More resources 🔗

This marks the end of our tutorial. If you haven't read the previous articles, check out the first part, where we built a minimal Angular app, wired runtime i18n with ngx-translate and added Tailwind styling; and the second installment, where we  set up the app logic before translating.

I also recommend checking out the references below:

• Anatomy of a component (angular.dev)
• Routing (angular.dev)
• Service worker intro and provideServiceWorker (angular.dev)
• ngx-translate library: core, http loader and message format compiler (Github)
• Starter installation guide (Tailwind CSS)
• Integrations: Angular (Localazy)
• How to localize an Angular app with angular-i18n and Localazy (Localazy)

Happy coding! ✌️

Is there a way to break the AI repetition loop?

🔂 The LLM repetition problem 🔗

The repeat curse in large language models has become hard to ignore – for everyday users and researchers alike. According to Weichuan Wang and Zhaoyi Li, the authors of the paper “Mitigating the Language Mismatch and Repetition Issues in LLM-based Machine Translation via Model Editing”, models used for translation frequently exhibit two patterns of errors: repetition and language mismatch. These errors badly affect translation quality and may lead to generic and flattened results.

The LLM repetition problem occurs because AI models are trained to predict results based on probability. Each word is selected according to the highest likelihood of following the previous one. When a model leans too heavily on its top-probability choices, it falls into prediction loops, creating the same polite-but-generic tone, familiar metaphors, and mirrored sentence structures.

But it gets worse. When the same probability is applied for decoding, the generated text becomes even more repetitive. The model learns what comes most often, and a decoding strategy that selects the top-probability token amplifies that tendency. Your AI outputs are once again packed with common phrases and monotonous paragraphs. This “greedy decoding” means the model remains in a narrow part of the token distribution, which is also the most crowded. It never looks at the farther tail with less common words.

And that’s not the end of the repetition story. When the models are trained on their own generated content, that repetition pattern is reinforced again. That’s where a model collapse happens, leading to reduced quality and diversity in outputs.

📉 Repetition affects your localization quality 🔗

If you’re localizing content for new markets, repetition is the last thing you want to add to your repertoire. Your users are not interested in another copy-paste article with the same metaphors, familiar word order, and uniform tone.

Leave your LLM playing the same high-probability notes, and your blog posts will constantly begin with the most dreaded “In today’s fast-paced world…”.  Ask it to translate the string “Explore how we can transform your experience” from your fitness app into Polish, and it will most likely default to “Odkryj, jak możemy odmienić Twoje doświadczenie”, a dull, generic, literal phrase that says nothing and converts no one.

And that lack of conversions is not just a gut feeling. There’s proof for that. The “AI vs Human Copywriter Performance Statistics” published by Amra & Elma Marketing Agency shows that human-written ads gained around 45% more impressions and 60% more clicks than AI-generated ads. According to their analysis, the best approach for the marketing content overall seems to be human+AI. That’s how you can move from repetitive, boring texts to content that engages and converts.

Dull, generic sentences in your localized content are easy to spot and don't convert customers. According to a 2025 Amra & Elma's report, human-written ads get 60% more clicks than AI-generated ones

Repetitions are also harmful to your SEO. Search engines reward unique, context-rich phrasing. But AI-generated content often uses the same structures, which ultimately drags your rankings down. Repetitive outputs have a negative impact on keyword variation, as well. Instead of natural local synonyms, models reuse the same English-influenced loanword that may be less relevant for the local market.

Below, you can see some real-world examples of highly repetitive texts found online.

🪄How to stop an LLM from repeating itself 🔗

AI repetition in localization is a common issue, and the online world is full of examples such as those above. One way to avoid it is by introducing an LLM repetition penalty that discourages models from replicating the same words. It modifies token probabilities and leads to more unique results. Another effective method is to penalize repetition in training data.

Such upgraded models may or may not see daylight, so instead of waiting impatiently with high hopes, there’s something else you can do right now. And it doesn’t involve dropping the AI altogether. All you need is your wizard hat and a bit of magic in the form of verbalized sampling. 🎩

Using verbalized sampling 🔗

What is verbalized sampling, and how can it help you?

According to the paper “Verbalized Sampling: How to Mitigate Mode Collapse and Unlock LLM Diversity” by Jiayi Zhang, Simon Yu, and others, verbalized sampling is an inference-time method that improves diversity in LLM outputs. It explicitly asks the model to generate multiple candidate outputs along with natural-language justifications that explain how likely each candidate is. This simple act pushes the model to investigate options it would normally ignore. And because this process happens at inference time, it restores diversity without retraining, fine-tuning, or touching the model weights.

The experiments conducted by the research authors demonstrated that verbalized sampling significantly improves performance in creative writing dialogue simulation and synthetic data generation without compromising accuracy.

It also adds more variety to translation. The model pulls out lower probability but valid choices that standard decoding would overlook. This means that your results may contain alternative sentence structures, different tones, regionally distinct phrasing, and more creative, but still faithful paraphrases.

All in all, using verbalized sampling for localization and translation can lead to more natural-sounding content that engages and converts.

A quick example 🔗

Let’s see it in action. For the following prompt:

Provide 4 alternative translations from Polish into English of the text below. 

For each version, write a short explanation of how likely that translation is (high / medium / low probability) and what linguistic factors influence that probability (syntax, tone, idioms, regionality, etc.).

Source: “Odkryj świat, w którym granica między rzeczywistością a fantazją nie istnieje”.

GPT 5.1 presented the following results:

As you can see, the model went below the safest choice and generated less probable but more creative translations. My personal favorite is no. 3, and yes, no. 1 is the most literal, word-for-word translation that you’d receive from most machine translation engines or AI without tailored prompts. In other words, that’s the result you probably want to avoid.

📬 Tips to get better outputs without retraining AI 🔗

Verbalized sampling is not the only cure for the natural language generation repetition. To take the repetition spell off your model, you can call on these superpowers as well:

1. Use role prompts 🔗

When life gets boring, role-playing may come to the rescue. The same applies to AI. According to the paper by Zhang and Yu, repetition often stems from typicality bias.

The model (and its human trainers) prefer outputs that sound “familiar” or “safe.” When you assign a specific role (“You are a cultural strategist,” “You are a brand tone coach,” “You are a localization strategist”), you encourage AI to sample from a different internal distribution. This small change helps the model access less typical, more contextually diverse responses.

2. Adjust temperature 🔗

Default settings create comfort, and comfort quickly turns into monotony. The same goes for low temperatures: they keep your model cautious and predictable. To spice things up a bit, move the temperature upward and let the model look into alternative completions. Higher temperatures lead to less likely and often more unique results.

3. Add constraints to your instructions 🔗

Freedom without limits might be destructive. Your AI model needs some constraints as well to mitigate the LLM repetition problem and stop damaging your content.

Research on creativity in LLMs shows that explicit restrictions push the model to explore its internal diversity instead of defaulting to the safest phrasing. This strategy limits LLM’s ability to copy text from its training data and breaks the repetition loop.

In localization, this means that you’ll need to tell an LLM what dimensions to vary, e.g., tone, format, region, or emotion. In this way, the model can spread its responses across those new axes rather than collapsing onto one “typical” answer.

4. Provide iterative feedback 🔗

If you keep doing the same and hope for a different outcome, you’re essentially running in circles. And no one enjoys that, especially when interacting with AI. The model keeps behaving the same, your prompts stay the same, yet you still expect something new to happen. At some point, someone has to step off the treadmill.

That’s where feedback comes in. Your AI model doesn’t “know” it’s stuck in the same place. You need to enlighten it.

Iterative feedback is a powerful strategy both for agentic and generative AI. It acts as a micro version of verbalized sampling: you push the model to re-sample from its wider range.

With these powerful techniques, you can move the model out of its highly probable comfort zone and into uncharted terrain. And that’s the perfect space for AI exploration and human imagination to work together. Unique, creative, and full of unexpected twists.

Between the event hopping we've done, our two hackathons, new product updates, and welcoming new faces to our growing team, we've been busy. Let's catch up on the product wins, team growth, life behind the desk and away from it, and what we're building next.

⚡ TL;DR 🔗

🤖 Localazy AI & Style Guides launched: context-aware translations become more accurate / 🎨 Major UI improvements: Dark mode and revamped translation interface / 🔌 Webflow & Strapi v5 integrations / ⚙️ Automations went live: Rule-based workflows for all Autopilot tier customers / 🎙️ 18 podcast episodes across two seasons covering everything, from AI to accessibility / 🎪 Multiple SaaS events & two hackathons  / 👥 Two amazing new team members, Dorian and Michaela / 🤲 Professional translation support expanded

📊 Our 2025 in numbers 🔗

This year, we've served thousands of projects across hundreds of languages, achieving over 200 million processed translations for 38,000 projects through our platform. Our community has been incredible, from solo SaaS founders to enterprise teams, and we've been fortunate to connect with many of you through podcasts, events, and countless support conversations.

The most popular target languages 🔗

Our team is deeply focused on product work, so we haven't had much time for analytics. Last year's recap was light on data, but David, our full-stack magician & AI engineer, has been working on QA improvements this year that required crunching numbers, and the results are here!

When we look at a small sample of translations flowing through our platform in 2025, the data tells a clear story about where teams are expanding now, and where they're heading next.

European languages dominated at 47% of all translations. It turns out that expanding into Germany, France, and Spain is still the go-to move for most teams launching internationally.

The top 5 languages by translation volume so far are:

1. 🇫🇷 French - 28% market share
2. 🇩🇪 German - 9.8%
3. 🇪🇸 Spanish - 8.6%
4. 🇳🇱 Dutch - 3.1%
5. 🇮🇹 Italian - 3.4%

Not very surprising, perhaps. But it gets interesting when you look at the rising stars:

• 🇸🇦 Arabic jumped to 2.9% market share, signalling serious Middle Eastern expansion plans
• 🇵🇱 Polish hit 2.8%, confirming what we've been seeing all year: Central Europe is heating up
• 🇯🇵 Japanese reached 2.6%, showing that Asian markets are becoming harder to ignore
• 🇨🇳 Chinese Simplified held steady at 2.7%
• 🇮🇳 Hindi claimed 2.2% of the pie, as India moves up the priority list

The shift is unmistakable: even though Europe is a major market, teams are looking outside of it as well. If you're still only translating to French, German, and Spanish in 2026, you might want to reconsider your strategy.

🤓 Throwback: Back in 2023, the most popular languages on Localazy were German, French, Spanish, Arabic, and Italian, in that order. French has since taken the crown.

Industries we served in 2025 🔗

Looking at a small diverse subsection of companies using Localazy this year, here's how they break down by industry:

1. 💻 Software / IT Services - 39.97% (by far our largest segment)
2. 💼 Finance / Legal / Business Services - 16.46%
3. 🛒 E-commerce / Retail / Consumer - 10.49%
4. 🎨 Creative / Design / Digital Media - 10.01%
5. ⚙️ Industrial / Engineering / Energy - 8.01%
6. 🎮 Entertainment / Gaming / Culture - 6.48%
7. 🏥 Healthcare / Life Sciences - 4.51%
8. 🚗 Automotive / Transport / Logistics - 4.07%

Software dominated at 40%, and for good reason. Digital products need localization from day one to scale beyond their home market.

The rest? Fintech companies and banks (16.5%), where getting "confirm payment" wrong costs companies real money. Online stores (10.5%), where users like Digismoothie found out that checkout buttons need more than word-swapping. Gaming companies (6.5%), where bad translations tank your app store rating. And healthcare apps (4.5%), where projects like iFightDepression learned you can't run medical content through Google Translate and call it a day.

HR platforms like Bryq and CrewPlanner also proved localization makes it much easier to provide fairer candidate assessments and efficient team management across 20+ locales.

🔖 Want to read the full stories? Head over to our case studies section.

Product updates 🔗

We shipped a lot of small and big improvements (you can quickly check all the release updates of the year here). Here's a recap if you missed them!

🤖 AI & Translations 🔗

• Style Guides. Remember when you had to email translators a 10-page brand voice doc that they'd ignore half the time? Not anymore. Set your tone, formality, and rules once. They'll show up automatically for translators and feed straight into Localazy AI.
• Localazy AI with brand context. AI that actually understands your brand, not just word-swapping. It reads your style guide, follows your glossary, and learns from your existing translations. Not a MT that translates in a robotic tone without considering the context. $0.005 per word for Professional, Autopilot and up.
• Machine translation credits. Goodbye, mysterious MT caps. Hello, clear credits. You finally know what you're using and what it costs.

⚙️ Automation & Workflows 🔗

• Automations. Set rules, walk away. Pre-translate new strings, copy between languages, auto-tag content, delete deprecated keys. Available on Autopilot and up. Because why do it manually when a simple automation does it for you?
• Translation priority and tags. Tag strings, set priorities, filter for focused sessions. Works with Automations so critical updates get fast-tracked while everything else runs in the background.

🔌 Integrations 🔗

• Webflow. Finally, we built an integration that connects to Webflow. You can now translate your Webflow site directly without copy-pasting or breaking your Collections structure.
• Strapi v5. Plugin updated for teams running Strapi's latest version.

🎨 Localazy UI improvements 🔗

• Dark mode. Perfect for winter workdays and night owls. For a product built by devs and for devs, we sure took our time shipping this one, but now it's here. 😬 The interface is now comfy on your eyes for late-night translation sessions.
• Navigation redesign. Less blue header, more breathing room for what matters: your actual translations. And we're soon shipping another major redesign to make the interface more intuitive.

• Better progress tracking. We’ve added some useful language bars that show word counts on hover, and clearer bulk action results. The small stuff that adds up when you're managing 15 languages.

🏷️ Organization 🔗

• Ambassador program. You can now earn points for sharing your user experience (through G2 reviews, LinkedIn posting, case studies, starring our GitHub repos, subscribing to our newsletter, etc.). Trade them for premium features, donate them to projects you care about, and soon you'll be able to use them to get free translation credits too. We figured, why not reward people who take the time to share their experience with Localazy?

🌍 Professional translation improvements 🔗

We've expanded our human translation services with four more languages this year: Somali, Tigrinya, Punjabi, and Bengali. Not the usual suspects for localization platforms, but that's exactly why they matter. Companies expanding into East Africa and South Asia now have native translators ready to go.

Between human translators covering more languages and a smarter AI that references your brand guidelines, getting quality translations across multiple markets will take you less and less time.

🎪 Event hopping 🔗

Petr unofficially has accepted his fate as the brand's face, and you'll see him popping up at events more often. In November, we sent him to AppParade vol. 37 in Prague, a community event all about practical AI applications. He showed how our AI handles translations from start to finish, met other app founders figuring out localization, and naturally, we have a picture to prove it happened.

We also sent him to a SaaS meetup in Brno, in an event on localization by the Czech Innovation Platform. When we attended DigiFest.cz, he was supposed to present on ditching Excel and ChatGPT for proper localization tools but caught a cold. Luckily, our Solutions Architect Dan took the stage and delivered the presentation... with a racing heart. There's no better proof of how passionate we are about the work we do that his heart rate during that presentation. 😌

But that wasn't all. We also had two amazing hackathons that were not only fun but also a great time to talk about the product vision in person. The first one was in April at a mountain cottage in Kolštejn, tucked under the Ramzovský saddle in the Jeseníky Mountains. Board games, brainstorming sessions, and plenty of chatting about where Localazy is headed. David couldn't resist a bike ride and Jan, being the runner he is, couldn't help going for a mountain jog, so a few of us tagged along for an intense exploration of the trails nearby too.

The second hackathon happened in November at Vlaštovička in Sobotín. Petr showed up with an entire board game arsenal: Wingspan, Crown of Ash, Dune: War for Arrakis, and backups (he takes his board games seriously).

Between games, we realized our About Us page wasn't good enough. It needed a full revamp, better team intros, Localazy's origin story, updated stats. We left with a plan to make it happen, and now it's about to go live soon.

👥 Team updates: Welcome aboard, Dorian & Michaela! 👋 🔗

Our team grew by two exceptional people in 2025.

We’ll start with Dorian Maršálek, Account Manager & Content Marketing Specialist. Dorian's path to Localazy sounds like that of someone who kept saying "close, but not quite" until the right door opened. He studied English literature and music at Masaryk University in Brno, somehow ended up in sales at BVV Trade Fairs, then worked for two localization agencies before landing at Survio as a content and localization specialist.

Five years later, this September, he shook hands with Vašek and Jakub to join Localazy. When we asked for a photo, he sent two: one with his family, one playing music. "These are what I love the most," he said. Makes sense: he's been playing piano since age 5 and his rock band is about to hit its 20th anniversary. He also loves inline skating, tennis, swimming, biking, and skiing, though he admits family activities are now taking over his sports schedule (half the team nodded in solidarity when they read this. We're a family-oriented bunch, what can we say 🫣).

"Switching to Localazy simply felt like putting on a new coat. The product is great and what makes working at Localazy truly a joy is its team. We work hard but also celebrate wins as friends. I can build on my skills and experience while taking on new challenges that keep broadening my horizons. Everyone is helpful and open to sharing what they know, which makes the work both interactive and enjoyable." Welcome, Dorian!

Michaela Havlíková, Front-End Developer, joined us this year too. How she got into this field makes for a nice story: she started with making jewelry and sewing home accessories 🧵, creative outlets that eventually led to building her first websites. What began as personal projects turned into a self-taught journey through web development, courses, and more self-learning. She loved working with visuals, details, and user experience, and that naturally pulled her toward front-end development.

When we asked what she values most about working at Localazy, she didn't hesitate:

"At Localazy, I work closely with several colleagues and truly value the open and friendly communication. My teammates are supportive, helpful, and always willing to share their knowledge, which makes the work both effective and enjoyable. The work itself is diverse, engaging, and meaningful to me."

She also mentioned our last hackathon in November 🏔️ (the one where Petr brought his board game arsenal). "It was a particularly memorable experience. I met most of my colleagues in person for the first time, and it only confirmed what a human, supportive, and open team we are."

Outside of work, Michaela reads constantly 📚 (you'll almost always find a book with her), loves traveling, and takes full advantage of remote work. During summer, she often works from Bulgaria by the sea. She also attends tech events and meetups to follow new trends and connect with people who share a passion for technology. Welcome, Michaela! 😄

📖 Word of the year 🔗

Context (n.)

a. the circumstances that form the setting for an event, statement, or idea

b. the parts of something written or spoken that immediately precede and follow a word or passage and clarify its meaning

c. the interrelated conditions in which something exists or occurs

d. Information […] that helps […] produce accurate and meaningful translations.

If 2025 had a theme, this was it. From Style Guides that give translations brand context and podcast discussions about better localization quality to notes about our vision, everything came back to this word. And we bet it's gonna keep being relevant for a long, long time.

🎉 Meanwhile, in real life… 🔗

Between shipping features and attending events, the team hit some personal milestones. Two weddings, one baby, some travels — the usual stuff when a year flies by.

Vašek got married 🔗

Our CEO got married on July 5th, and of course, the entire team was invited, even though they couldn't all make it. It was a special type of celebration mixing Czech wedding traditions with summer welcoming celebrations: lunch with family, swimming (people brought swimsuits), beach volleyball, activities for kids... There was no formal dress code or making sure we kept a straight face for the sake of it. We're all about substance and less about making it look good. Instead of stressing over gifts, Vašek just asked people to show up and celebrate. That was the main thing. Classic Vašek, practical even on his wedding day.

And oh, Marta, being one of the artists on the team, sang the first dance song, which made the special day even more special. 😄

More weddings, births, and adventures 🔗

This was a good year; so good we didn't stop at one wedding. 👀 Our Product Manager Jan also got married, and we were happy to celebrate with him. It was an eventful year for Jan. He got an offer to join Snowflake as Product Manager, and the team could not push him to take it. We'll miss him at Localazy, but it's not a forever goodbye. He's part of the team as a friend, not just a colleague, and he'll still show up at our informal events (and hopefully our hackathons, too!).

Jan spent five years at Localazy, and was with us from the very first line of code, helping make the product decisions that made Localazy the powerful platform you use today. Among his final contributions, he left us with data infrastructure we couldn't be prouder of. Good luck at Snowflake, Jan. 🎉

And then Dan became a dad for the second time. Our Solutions Architect welcomed a baby boy this year. Tomášek came a few days earlier than expected and made his presence known immediately with a "a mighty roar," according to his dad. The team sent love, congratulations, and zero useful advice about sleep.

And the rest? Our CMO spent the year building his own house (literally). Dan rented an excavator for reasons we're still not entirely clear on. Ondra moved around Europe and attended the Estonian Song and Dance Celebration (Eesti Laulupidu) in Tallinn, that occurs once in five years. Tibor came back from his long adventure in Vietnam. Jan and David hiked in Austria. Gled flew in from Albania to join our hackathon and explore Czechia and Austria. Avi went to Japan. Marta premiered her own music project and played enough concerts this year to make the rest of us look lazy (she took the "loca" in Localazy a bit too seriously, especially after she also went LinkedIn-viral on accident.🫣)

Some other fun stuff along the same lines: Ondra did his third halfmarathon in Tartu! And Vašek completed a Gladiator race.

💬 Top Slack moments from 2025 🔗

Slack is our big digital roundtable where almost all the conversations about product and life happen. Normally, you can find everything in there, from language-related memes to news articles and research papers. But here are five moments from 2025 that gave us a good laugh. 🤭

1. The translation fail that keeps getting worse 🔗

At the start of 2025, Jakub wrote a heartfelt post in Czech thanking people who helped him through a rough year. When non-Czech-speaking teammates went to read it, they found that LinkedIn auto-translated a part of it initially as: "It is important to have your Philip, as they say. Heaven itself sent you to me. I hope to pay you back all this one day, including interest. Your insight, a pat on the back when we f*cked." That was supposed to be "when I messed up". 😆

At the moment of writing this article, we thought LinkedIn might have fixed it. Nope! It got worse. The new version reads: "I've only been sent to heaven by you" and "a pat on the shoulder when we farted." 🤣

If this isn't enough proof of why professional translations matter, we don't know what is. Imagine Filip was your client and you translated a piece of communication like this and sent it to him. Yeah, not ideal for business. 🫣

2. The "Kuba" AI benchmark 🔗

After this blooper, Václav dropped a new AI benchmark in Slack. And it's totally valid. We have yet to find a LLM that replicates Jakub's style of writing. His neurodivergent thinking remains unmatched.

3. Jan's data-driven wedding planning 🔗

Jan shared a weather analysis graph comparing July 12th vs. 19th temperatures and precipitation from 2014-2024. Because why trust intuition when you have historical climate data? Best part? It rained for a while during the wedding despite what ten years of patterns predicted. 😂

4. Our CEO became a spam magnet 🔗

Vašek's inbox had a wild year. But we'll show you three handpicked examples: an AI-generated sales email asking if Localazy supports "Esperanto" before pivoting to processor penalties and card disputes. 😳

Then someone tried impersonating him to convince an investor to send free AWS credits. At least spam is getting creative? Yet, these AI generated versions aren't yet there. We'll see what 2026 brings.

5. Marta went to prison 🔗

Marta casually mentioned she went to prison in May. The team had questions. Many questions. Turns out she went there with her gospel choir to perform for the inmates. Getting clearance, going through registration, and preparing for the visit took longer than the actual performance itself. 😅 But standing on that stage and singing for people who rarely get those moments? That made the entire process worthwhile and meaningful.

To wrap these Slack moments up, we sure have to mention some of the recaps from other tools we're using. Firstly, we have Riverside, home to all our video assets. 😌 Ondra was the star of the recap as you can see:

Then, Granola surprised all of its users with their spicy Granola Crunched. Many were impressed. And we were no different. These were some notable recaps. 🤭

📚 Our favorite content of 2025 🔗

We spent a lot of time on Riverside this year. Eighteen podcast episodes later, we're still surprised at how much we actually published. You'll surely find something to listen on the full episode list, from AI translation hype to localization metrics and remote work tips, but a few episodes sparked the most internal debate:

• S02, EP10: Automation should work with your team, not against it - How to effectively automate workflows without messing your teams' work.
• S02, EP08: Most localization teams aren't ready for AI workflows - The uncomfortable truth about AI adoption in localization from the perspective of a software engineer and localization specialist.
• S01, EP03: Can LLMs replace translators? - The question everyone's thinking about as AI's capabilities grow further.

Between recording sessions and improving our product, we also collected some solid reads that ended up in our #reading_club Slack channel. The AI messaging study from Kyle Poyar touches on the AI bubble and why customers don't care about your AI feature as much as you think they do. We also nerded out over research papers on multilingual AI, machine translation evaluations, and cross-lingual models. The economic potential of generative AI from McKinsey required multiple breaks to finish, and AI-2027 predictions were either terrifying or exciting depending on who you asked in Slack.

Jan's team productivity deep dive about what to do when nothing seems to get done was a much needed reflection. Probably because we've all been there. Jevons Paradox made us rethink efficiency in ways we didn't expect. George Mack's essay on high agency became required reading; the kind of piece you bookmark and return to when you need a reminder that constraints are often self-imposed. And Jasmine Bina's 90-slide report on psychotechnology is simply a must-read musing on how to think about brand strategy in such unpredictable times.

Our own hits 🔗

We published 70+ articles this year, but we'd like to highlight only a few. How multilingual content improves share of voice in generative search touched on GEO (Generative Engine Optimization) and why localization matters more than ever in AI-powered search. The biggest localization myths developers believed was a realistic confession of our founder. Our locale guide series expanded with more expansion advice pieces for markets like Vietnam, Japan and Poland, just to name a few; and the future of localization is lightweight laid out why less is often more when it comes to translation tools.

Useful (and ridiculous) tools we found 🔗

Not everything has to be serious. We came across some fun and some useful websites this year: Kick Ass lets you literally destroy websites (therapeutic after debugging), Emoji Translate turns text into emoji madness, and the CMO Translator decodes marketing jargon. Could these be the productivity tools you were missing? Debatable. Worth bookmarking? Absolutely.

Bonus: Old-school commercials that slap 🔗

We're all obsessed with language and translation, so when Jakub and Petr found these vintage commercials (plus a good ol' Vine) in the wild, we couldn't resist sharing them. A bit harsh for today's marketing culture, maybe. But totally memorable! 😁

• Commercial 1
• Commercial 2
• Good Ol' Vine

🤔 What's in store for 2026? 🔗

This year we shipped Style Guides, context-aware AI, and better automations. We welcomed Dorian and Michaela, attended events, ran two hackathons, and published 70+ articles plus 18 podcast episodes.

But we're far from slowing our pace. Because our users needs are evolving and Localazy keeps evolving with them too. Besides focusing on faster translations and stronger integrations, we are refining translation accuracy and our QA systems. There's a lot coming in 2026, and with an airtight data infrastructure, growing team, and clearer vision, we're confident we'll ship more features worth the wait.

"With LLMs, good translations got cheaper. More teams went multilingual. Good for users, good for revenue. But the process is still tedious work, and achieving translation quality at scale is not easy. In 2026, we're laser focused on our mission: help teams ship multilingual products with confidence", says our founder, Václav Hodek

For now, here's something we held back from last year. David surprised the team with this Christmas gift: Localazy lighting up Times Square. We didn't use it then, but it feels right to close this recap with it now. Here's to 2026. 🎉

• You spend hours refining prompts with your glossary terms... only to have the model ignore half of them.
• Translation quality varies across batches because you're writing a new context prompt each time.
• You end up managing prompt engineering on top of localization, and the cost savings disappear when you factor in the time spent maintaining your integration.
• You're constantly looking out for mistakes and don't have an easy way to fine-tune the results later.

The solution doesn't lie in trying a different AI model when the results don't work as expected. What makes the difference is the infrastructure built around it.

Our team has spent the past year researching what makes AI a reliable companion in localization. Instead of immediately translating text like a direct API call to an LLM, it reasons first. Before touching a single word, it collects context from your project, processes that data to understand your specific needs, and then plans the translation approach. And it is an integral part of the translation management platform, so you are always in control of the results and can intervene at any point.

Read on to learn how to use Localazy AI effectively as a part of your translation process.

👑 Context is still king 🔗

The quality of translations depends on how well the translator understands the source text before they begin. Localazy AI is no different from a human in this regard — both need context to increase the accuracy and quality of the resulting translation.

Localazy AI uses your glossary, style guide, key names, translation notes, comments, and previous translations to reason about what you're translating and how it should sound. Before you translate your strings using it, prepare at least the glossary and style guide to improve results.

Start with a glossary 🔗

Add your product-specific terms and how they should be translated in each language. But don't just list translations. Include descriptions that give the AI and humans a deeper context.

📝 What can you include? Brand names, abbreviations, feature labels, or industry-specific terms. The glossary lets you define these terms, whether they should be translated or kept as they are, and their target translations in multiple languages.

The AI uses this information during its reasoning to avoid misinterpreting your terms and to maintain consistent translation.

Add a project style guide 🔗

Tell the AI whether you want a formal or informal tone, how to handle gender, and what level of technical vocabulary to use. During the reasoning phase, the AI will consider your style requirements alongside the text itself.

Your French marketing copy probably needs a different voice than your German button labels. The Style guide helps Localazy AI plan the right approach for each piece of content before translation.

👇 Watch the video below to learn how to set up your style guide.

Key names and translation notes 🔗

A key named reservation-button tells the AI this is a button for reservations before it even looks at the text. That implicit context helps it reason correctly. If your key is just book, the AI has nothing to work with.

Add notes when specific strings need special handling, like: "Use imperative form" or "This appears on the checkout page, keep it short and action-oriented." These notes inform the reasoning process, helping the AI understand not just what to translate but also how the translation will be used.

Conversations in comments 🔗

When your team discusses a translation, those conversations also become part of the reasoning context. If someone asks, "Is this a verb or a noun?" and you clarify, "infinitive verb, please," the AI takes that into account when handling similar strings.

💡 How to use Localazy AI in your project? 🔗

When your context is ready, you can start using the Localazy AI in your translation workflows.

There are currently two ways to do it, and you might want to use both of them in different contexts. But first, you should top up some Localazy credits.

Top up credits 🔗

Each subscription plan includes a monthly credit allocation that resets at the start of your billing cycle. The credits included with your subscription help you with day-to-day updates of strings, but if you expect to translate a whole new language or start a new project from scratch, you might want to top up additional credits to cover all of the new words and languages.

Navigate to the billing section in your organization settings and add credits to your account (Services > Overview > Available credits > Increase). The credits are used to pay for professional, machine, and AI translations altogether.

Start with $100 if you're testing (that's about 20,000 words), or add more if you're translating larger projects. Purchased credits don't expire and work across all your projects.

Translate in bulk 🔗

Once you have credits, navigate to the Translations screen, select the language you want to translate, and choose "Use Machine Translations" from the context menu.

Select Localazy AI as your translation method, and the system will process everything with the context you've configured (glossary, style guide, notes).

This is useful when you're adding a new language to an existing project, translating a batch of new features, or doing your initial translation run.

Automate it 🔗

AI translations are most valuable when they happen automatically. Set up Automation rules: when new source strings appear, translate them immediately into your target languages. When a source string changes, retranslate it.

This pairs naturally with the CI/CD integration:

1. Your developer merges code with new strings.
2. The CI/CD pipeline uploads them to Localazy.
3. Localazy AI translates them within the available context.
4. The translations get pulled back into your build and can be optionally flagged as "Needs improvement" so a human can review them.

The whole process runs without anyone thinking about it.

You can also set up automations that route specific languages to professional translators, while the rest is handled by AI. Maybe your English-to-Spanish content always goes to humans, but English-to-German uses AI. The Automations handle everything according to your rules.

👀 Review what actually needs review 🔗

Localazy AI handles the bulk of the work. Your thousands of strings get translated with consistent logic applied across all of them. Translation memory suggests existing translations for similar content. The AI maintains consistency automatically.

Use priorities and tags 🔗

You can set priorities for your strings based on where they appear, leaving you to review what actually needs attention: customer-facing marketing copy, onboarding flows, and anything where brand voice matters significantly. Technical strings like error messages often ship fine with just AI translation and QA checks. Your "File not found" error doesn't require the same level of review as your landing page headline.

Set up language permissions 🔗

You can also set language permissions so your French expert reviews only French, your German expert reviews only German, and so on. They see the source text, the AI translation, relevant context (screenshots, notes, key names), and glossary terms. They can quickly approve good translations and address any adjustments needed.

Review inside Localazy 🔗

The review interface shows which strings changed recently, which ones have issues flagged by QA checks, and which ones have comments from other team members. You're working through a focused queue of content that needs your attention, not sorting through everything.

✅ Ready to try it? 🔗

I hope this practical guide helps you understand why Localazy AI is different and how to integrate it into your current localization workflows. Go ahead and try it with your content! Remember to set up your style guide and glossary first, so you can see the localization reasoning in action, and let us know what you think.

We want to hear from you:

What's working well? Where are you still spending too much time reviewing? What context would help the AI make better decisions? Your feedback helps us improve Localazy AI for everyone. Reach out through the support chat or share your thoughts at team@localazy.com.

🤔 FAQs 🔗

How much does Localazy AI translation cost per word? 🔗

The pricing uses a sliding scale where the cost per word decreases as the string gets longer. The price per word is determined by the number of words in the translated strings. A 1-word string would cost $0.008 to translate, while strings of 100 words or more cost as low as $0.0035 per word.

What is the cost comparison with other translation methods? 🔗

For context, professional translation via Localazy averages $0.15 per word, which is 30x the cost of AI. While machine translation providers like DeepL and Google Translate are much cheaper per word, they don't work well with software strings, so your placeholders or code markup can break much more frequently. They also can't account for your project context.

When should I use each translation method? 🔗

• Machine Translation (DeepL, Google Translate) is the fastest and cheapest option for entering new markets or testing localization. It's useful for assessing whether a market is worth pursuing before investing heavily. The translations need significant post-editing because MT doesn't understand context, breaks placeholders, and produces inconsistent results. But for a first iteration or testing, it gets content out there cheaply. Be prepared for feedback and iterate often. If you are not afraid of the potential risk of misunderstandings, you can just fix the validation issues and ship quickly by using machine translation.
• Localazy AI is what you use for initial iterations and for testing new markets when you want higher quality than basic MT. It reasons through context, preserves placeholders, applies your glossary and style guide automatically, and includes QA checks. Humans can fine-tune the results, but they won't have to fix nearly as many mistakes as with traditional machine translation. The translations come back consistent and context-aware, so your post-editing effort drops significantly. Use this for 80-90% of your content.
• Professional human translators are recommended when quality is critical. Use them for customer-facing marketing copy, important landing pages, established markets where brand voice matters, or content where mistakes have consequences. Humans are also still better at understanding cultural nuances and creative wordplay that AI doesn't fully grasp.

Remember that you can mix methods within Localazy. Set up automations that route specific languages or content types to professional translators, while the rest is processed by AI. Automation filters handle routing according to your rules.

Can I bring my own token? 🔗

Currently, you can’t connect your own OpenAI or other LLM provider keys to Localazy AI. The system is built as an integrated service, not an API wrapper.

If you connected your own tokens, you'd encounter unexpected errors and unpredictable behavior:

• Rate limits vary by tier. Your OpenAI account might be on a tier with strict limits. Rate limits change between tiers, between models, and based on your usage patterns. This doesn’t apply to Localazy AI.
• Models disappear or change. If OpenAI deprecates or changes a model's behavior, your integration could break. You will need to update the model manually, regenerate the token, etc. With Localazy AI, we handle model updates and ensure translations remain consistent when underlying models change.

In addition, Korea has attracted significant attention from global companies, especially online services. The country has a population of 51 million, with 99% of it using smartphones, according to Gallup Korea. Another study by the Korean Press Foundation reports that 28.5% of children begin using smartphones at age five or older. This alone shows how early Koreans are exposed to online services, making the country a highly digital-native society. Many of my foreign friends often comment on how fast our internet is; perhaps the smartphone penetration and early exposure explain why.

However, despite the beauty of Korean culture and the country’s active technological environment, entering the market comes with major challenges. Korea has been a largely homogeneous society for a long time, and despite the number of foreigners hitting an all time high, Korean society is still learning to accept diversity as part of everyday life.

After helping dozens of global web and SaaS companies enter the Korean market, I’ve come to realize that most companies treat translation and localization as the same thing in the Korean market. But it’s not because of a lack of respect for their users: it is due to limited market knowledge, lack of resources, or an unclear localization strategy.

So what should you do to avoid turning potential fans into enemies?

🇰🇷 A brief note about the Korean language 🔗

Before diving into the localization tips, let me quickly summarize some basics about the Korean language.

Modern Korean originated in the 15th century, when King Sejong created Hunminjeongeum, a scientific writing system designed to increase literacy among common people. Over time, this system evolved into Hangul, the script used in Korea today.

Korean is the official language of both North and South Korea, but the two versions differ, especially in vocabulary. South Korean Korean (Hanguk-o) frequently uses English loanwords, while North Korean Korean (Chosŏn-o) replaces them with purely Korean alternatives. A simple example is 🍦 ice cream: 아이스크림 in South Korea vs. 얼음보숭이 in North Korea. It's also important to note that, in South Korea, there are several regional dialects, but the Seoul (Gyeonggi) dialect is the standard for business and formal communication.

The most common type of Korean used for commercial relations with the South is Hanguk-o, specifically the Gyenonggi dialect from Seoul

Another key concept is Konglish, or Koreanized English (some examples of its use here). These are English-like words used only in Korea, often seen in business settings, especially in job titles such as 프로젝트 매니저 (project manager) or 소프트웨어 엔지니어 (software engineer). While familiar to Koreans, these terms may not translate directly back into English, which can lead to confusion if not handled carefully.

Korean is culturally rich but layered with dialects, loanwords, and honorifics. This complexity is exactly why localization (not just translation) is essential for foreign companies entering Korea. Once you understand the patterns behind how Korean adapts foreign words and expresses hierarchy and context, creating a polished, natural local experience becomes much easier.

Now, let’s move on to five common localization mistakes foreign companies make when entering Korea.

💬 The 5 Korean localization mistakes I see the most‌‌ 🔗

1. Leaving English text unlocalized 🔗

In Korea, using English is just not enough. It is important to remember that English is not an official language in the country, so it is very dangerous to assume that every Korean user will fully understand it. ‌‌‌‌In addition, Korean users tend to be highly influenced by early feedback and reviews. If your product is entirely in English, chances are you will not only experience a high churn rate but also receive a significant amount of negative feedback. And once your first few reviews are negative, turning those detractors into fans becomes extremely difficult.‌‌‌‌

I've experienced this myself. The CEO of a Korean reward app once called me at 8 p.m. because they got too many complaints that their products were not fully localized. Despite having translated most of the basic information, we had left some sections unlocalized, including the original game title. This was not acceptable to the client: they communicated that they would end the contract if the problem was not fixed within that day. As a result, I ended up staying up until 3 a.m. to correct every issue. 📝

In my experience, companies with properly localized services generate up to 10x more revenue in Korea than those that do not offer them

‌‌Take another example. One of the companies I worked for managed several Korean advertising campaigns, and I remember one specific product based on a famous American animation IP that performed exceptionally poorly. When I looked into the product, I realized the problem immediately — the texts were not localized at all. The fame of IP could not stop users from leaving, and this particular product had a 90% churn rate within two weeks.

This 90% churn rate and termination of contract could be your data if you don't take Korean localization best practices into account, or if your localization is not done at all (or done poorly).

While this is less common, some companies offer Korean services with Japanese text. 🤯 Above these lines you can see an example from the fintech app Wise. This screenshot, taken by a Korean user based in Korea, shows that the interface appears in Japanese. It is crucial to remember that Japanese and Korean are very different languages. Obviously, if the app that is targeted toward Koreans is in Japanese, Korean users will leave as soon as they open it.

These shows how poor localization can directly impact your reputation in the market. And in my experience, companies with properly localized services generate up to 10x more revenue than those that do not.

2. Wrong or inconsistent honorifics 🔗

Honorifics are one of the most common issues I see when English content is localized into Korean. Because English has no grammatical markers for honorifics, the same sentence, like “How are you?”, can be used both for a close friend or a senior manager. But in Korean, this distinction is essential. The tone you use for a friend must not be used for your boss, and being too polite can be just as unnatural as being too casual.

‌‌The same applies to user messaging. Unless you’re targeting teenagers or trying to give a next-door friend vibe, it is safer to go with a formal version. Let’s say that you are a UX copywriter for an e-commerce app targeted toward women in their 30s‌‌. Generally, if you’re dealing with adults it is always best to choose the formal register. For example, if you have to translate: "Want to get this later? Save it on your list!", this would be the wrong way to do it:

❌ Want to get this later? - 나중에 사고 싶어? (casual)
Save it on your list! - 리스트에 이것을 저장하세요! (formal)

Why? Because while this targets adults, it uses an informal tone that is not appropriate in the context. How can we make this sound more natural?

✅ Want to get this later? - 나중에 구매를 원하시나요? (formal)
Save it on your list! - 리스트에 저장하세요! (formal)

In this case, the formality is consistent - which makes the whole UX flow more naturally.

Now let’s look at this real world example from a reward app’s sign-up page:

❌ 거의 다왔어 - Almost there! (casual)‌‌
당신은 어떤 성별로 생각하시나요? - What do you think your gender is? (formal)

Just like in the example above, in this instance honorific levels don’t match. This inconsistency immediately signals to Korean users that the product wasn’t created by a Korean team, and it creates discomfort at the earliest stage of the UX flow.

How could we fix this?

✅ 거의 끝났어요 - Almost there! (formal)‌‌‌‌
당신의 성별은 무엇인가요? - What do you think your gender is? (formal)

The good news is that honorifics in Korean UI writing have a formula. In most app contexts, you can safely follow these patterns:

• Commands: ~하세요‌‌‌‌
• Questions: ~할까요?, ~하시겠습니까?, ~한가요?‌‌‌‌
• Statements: ~합니다, ~해요‌‌‌‌
• CTA buttons: Verb-noun forms like 시작, 가입, 홈으로 이동, etc. ‌‌

Here’s a well-done example from MyRealTrip, a Korean travel app similar to Agoda or Booking.com. The microcopy below the palm trees ends with -요, creating a tone that is polite yet friendly, perfect for consumer apps. Meanwhile, the CTA avoids a literal “go home” translation (집으로 가세요) and instead uses noun forms like 홈으로 이동 ("move to home"), which sound much more natural in Korean UI design.

3. Awkwardly translated subjects (especially "you") 🔗

Subjects are one of the most mishandled parts in Korean localization, partly because of the level of importance a subject holds in a sentence. In English, you need a subject to form a sentence. In Korean, however, the subject is often implied. One of the most common mistakes I see is translating you as 귀하. While politeness matters, being too polite often creates awkwardness. 귀하 is used only in official documents, such as terms and conditions. Apps, however, are not meant to sound official; they’re meant to interact naturally with users.

So how should you approach translating you into Korean without sounding awkward? Two common options:

1. Skip the subject entirely‌‌‌‌.
2. Replace “you” with a user-appropriate role (ex. 고객님, 멤버님, 이용자님).

Let's take the example below, which is another app sign-up page:

Do you see the text “귀하의 이메일”? This is meant to be “your e-mail”. In Korean, a more natural way to phrase this would simply be “이메일”, which translates to “e-mail”. It is already clear that the app is asking for the user’s e-mail address, so explicitly saying “your” is unnecessary.

The next example shows a better approach from LinkedIn. Here, “you” is translated as 회원님, meaning “member,” which fits the platform and sounds natural:

At the end of the day, translating “you” into Korean involves understanding how Koreans communicate, even if you have accurate grammar. If you get this small nuance right, your entire product suddenly feels much more welcoming and familiar to Korean users.‌‌

4. Incorrect terminology / lack of transcreation 🔗

This is another reason why I strongly discourage companies from solely relying on AI for translation. While many terms can be directly translated, many others cannot. In Korean, companies often use abbreviations of English words (e.g., CTA), transliterate the English term into Korean (e.g., 캐주얼 게임 for “casual game”), or create entirely new terminology for branding purposes. Tying this back to what I mentioned earlier, what you find in a dictionary is often not what is commonly used in real-life contexts. And AI cannot reliably catch these nuances. This becomes even more complicated when the content is an internal document, where only an expert can judge which terminology is appropriate.

Korean terms found in dictionaries are often different from what's used in real-life contexts. You cannot trust AI to catch this: the best solution is to consult a native expert or work with a linguist

Let’s assume you are translating a sentence for an HR company and encounter the term 🧑🏻‍💼 “career coach”. Many times, I see this translated as “경력 코치”. Is it technically wrong? No. But is it widely used? Also no.

Then, how can you make sure your internal terminology is correctly localized? Unfortunately, there is no one-size-fits-all answer because each company has different branding, tone, and market context. In these cases, it’s essential to work with a linguist or native expert who has strong industry knowledge and can guide you toward consistent, natural terminology.

5. Abuse of puntuaction marks 🔗

Korean writing uses punctuation just like English, but not all punctuation marks appear with the same frequency. Two marks that are relatively uncommon (especially in UX or app environments) are exclamation marks and semicolons. Semicolons rarely appear in Korean interfaces, so let’s focus on exclamation marks.

I generally recommend that non-native Korean writers avoid overusing exclamation marks. They are not “incorrect”, but they must be used sparingly to avoid sounding overly emotional, unnatural, or foreign. Korean text is highly context-sensitive, and when an exclamation mark is used in the wrong situation, users can immediately sense that the UX was not designed with the Korean market in mind.

Korean companies do not use exclamation marks nearly as often as Western companies. Abusing them in your product's UX can sound unnatural

Below is an example from the Just Dance app:

Take a look at the two texts with exclamation marks: ‌‌

❌ 위대한 댄스기빙! - Great Dance-giving!
추수감사절과 블랙 프라이데이를 즐겨봐요! - Enjoy Thanksgiving and Black Friday!

In English, this sounds perfectly fine. In Korean, however, it feels awkward. Why?

First, Korean companies do not use exclamation marks nearly as often as Western companies. If I had to quantify it, the ratio of sentences with exclamation marks versus those without is roughly 1:9. Exclamation marks may appear at the end of a sentence, but even then, they are not common. Given this, the “Great Dance-giving!” line would have been more natural without the exclamation mark:

✅ 위대한 댄스기빙 - Great Dance-giving
추수감사절과 블랙 프라이데이를 즐겨봐요! - Enjoy Thanksgiving and Black Friday!

‌Another example comes from the global fintech app Payoneer. Take a look at the CTA “시작합니다!”, which corresponds to “Start!” or “Get Started!":

Again, the translation is not incorrect. But, as mentioned earlier, CTA buttons in Korean typically end with noun forms, and exclamation marks are generally avoided. In this case, “시작하기”, which means “Start”, would sound much more natural without the exclamation mark.

The use of punctuation in Korean is highly nuanced, as shown in these examples. This is why, again, it is crucial to consult with Korean linguists who can provide guidance on when certain options should or shouldn't be used.

🫰Nail your messaging to succeed in Korea 🔗

Korean is indeed a very beautiful and culturally rich language, with so many options to express the same concept. At the same time, it is also a highly nuanced tongue, which means that some might find it daunting. However, Korea is one of the most digitally native countries in the world. If you get the translation right, you are already one step closer to succeeding there.

This article mainly discussed some dont's for Korean localization of apps and websites, but in an upcoming article, we'll take a look at some do’s for Korean SaaS localization and discuss the importance of UX in your strategy, including the use of Naver and other popular digital platforms.‌‌‌‌ For now, if you want to get your messaging right, I highly suggest taking a look at Localazy’s professional translation services. You can directly order help from a native Korean linguist within their UI, and the rest of the localization workflow can be handled all within the platform, which I find super convenient.

🧑🏻‍💻 How I accidentally became a localization engineer 🔗

My career as a localization manager started at Red Hat, where I coordinated translators and managed vendor relationships. Their culture demanded technical fluency: everyone had Linux backgrounds, open-source mindsets, and at least some scripting ability. I'd already been writing bash scripts and tinkering with HTML and PHP, so when technical challenges came up that required coding, they landed on my desk.

In fact, I didn’t set out to become a localization engineer. The role found me as I ended up straddling two worlds: classical localization management on one side, engineering and automation on the other. My official title never changed, but my actual work shifted dramatically. Instead of assigning translation tasks, I was building CI/CD integrations. Instead of reviewing translator output, I was training machine translation engines and writing scripts to sync content across platforms, and so on.

At the moment, I see myself professionally sitting between classical localization management and IT engineering. When you’re processing millions of words across large projects, you can prompt AI quite efficiently to use glossaries and make it translate the way you want. For automation, you need someone who can write scripts to integrate localization tools with code repositories, publication platforms, and dev pipelines. And honestly, I think this blend of localization expertise and engineering mindset is the future of how most localization teams will operate.

🛰️ Localization is splitting under the radar 🔗

Nowadays, we seem to be doing less and less of the usual localization management we used to deal with. Vendor coordination, human translator assignments, quality checks on every string… The traditional workflow is increasingly reserved for specific content types that genuinely need it.

Marketing campaigns, brand messaging, content that requires transcreation and deep cultural adaptation — those do need seasoned localization managers who know their translators and can guide nuanced creative work. But product documentation, support knowledge bases, or mobile app UI strings that update daily end up being handled by automation. It simply wins on every metric that matters: speed, cost, and scalability.

We're doing less and less of the usual localization management we used to deal with. Traditional workflows are increasingly reserved for specific content types that genuinely need it. Product documentation, knowledge bases, or mobile app UI strings end up being handled by automation

The industry is quietly splitting into two camps, and most people haven't noticed yet. One camp still needs comprehensive TMS platforms with extensive vendor management. The other thrives on lightweight and API-first tools that integrate seamlessly with development pipelines. I've worked in both, and the engineering approach is spreading fast.

😬 Why ‘heavy’ tools started driving me crazy 🔗

A short recollection of Memsource, now Phrase. When I first started using it, I loved it. Clean interface. A well-documented API that looked like a customizable sandbox for my own use case. A simple spreadsheet view with source strings on the left, target strings on the right. Lightweight, fast. Exactly what I needed.

Then came the evolution. Plugins, proprietary machine translation, integrated AI. Each addition made the platform more "complete" and significantly more expensive. They forced customers toward their own MT engines, limiting access to alternatives, and every new feature came with hidden costs and opaque pricing.

The pattern repeats across the industry: tools add integrations to create value, but each integration becomes a potential failure point. And here's the thing that drove me up the wall: there are always edge cases where integrations don't work.

That's why I prefer to write my own integrations now. I'll make exceptions for truly excellent connections, such as Localazy's Figma plugin or Crowdin's GitHub integration, both working beautifully in my experience. But for custom CMS connections or publication workflows? I'd rather control it myself.

Localization tools tend to add integrations to create value that become potential failure points. They also make their platforms more "complete", opaque and expensive, adding features with hidden costs

🪶 ‘Lightweight’ in localization properly defined 🔗

So, as a localization engineer, what am I actually looking for in a localization tool?

• Documented APIs: If I can't programmatically connect your tool to my development workflow, it doesn't matter how many features you have. API-first architecture is non-negotiable.
• Selective integration: Do a few things exceptionally well rather than attempting to support everything mediocrely. The best lightweight tools excel at core workflows, not everything imaginable.
• Transparent pricing: I need to know what I'll pay when processing millions of words across 20 languages. No surprise costs for volume. No forced bundles of proprietary engines.

Here's what changed my thinking: AI reduced our dependency on traditional TMS features. You can now prompt AI tools to use glossaries effectively and you’re done. Previously, it required sophisticated term bases and translation memory systems. Now, a well-structured prompt achieves the same result.

In addition, vibe coding made programming available to anyone with a basic technical skillset. You can now build your own basic integration, write a Python script to process large data sets, or create a bash script for a server to communicate with your Slack channel.

TMS tools, however, are still essential when you need to collaborate with human translators. At Reservio, even though AI handles initial translation, our TMS provides the interface for human QA. Translators see strings in context and can correct them directly. That workflow still needs a proper platform.

The tools that actually work 🔗

To me, the lightweight philosophy is embodied perfectly in Localazy, together with a couple other tools, like Crowdin, that excel at what matters: documented APIs that let engineers build custom integrations, selective excellence in core workflows rather than mediocre support for everything, and transparent pricing that makes sense at scale. And implementation is fast. If you need to switch tools or add a second platform, it's a week of engineering work, not a migration project.

👉 My choice: a split strategy 🔗

My advice is that you don't have to choose one approach for everything. I use lightweight tools for product documentation and UI strings and traditional workflows for marketing campaigns that need transcreation. The content type usually dictates the treatment.

Before choosing tools or workflows, it is important to answer the following questions:

What's your primary content type? 🔗

Technical documentation, knowledge bases, and UI strings? Go lightweight. Marketing campaigns, brand-critical creative content, or highly specialized fields like legal or medical? Traditional workflows will likely serve you better.

What's your update frequency? 🔗

Daily deployments? Real-time AI makes sense. Monthly releases? You have time for human cycles.

What's your volume? 🔗

Millions of words across dozens of languages? Automation becomes economically necessary. Tens of thousands of words in 3-4 languages? Human translation and/or review remains cost-effective.

What's your team composition? 🔗

Engineers managing localization? Lightweight tools align with their workflows. Traditional localization managers? They'll need comprehensive platforms.

💪 Build systems that scale, not just survive 🔗

A common pattern I see is treating localization as a translation problem when it's actually a system problem. Your localization workflow should match your actual constraints, not some idealized best practice. The hard part isn't choosing between lightweight and heavyweight tools. It's recognizing what your content actually needs and having the courage to build different workflows for different use cases.

And it’s not about doing less work, either. It's about doing the right work at the right time with the right tools, where AI acts as a force multiplier, not a replacement. Its job is to handle volume so humans can focus on nuance. It enables speed so quality assurance can happen thoughtfully rather than frantically. It reduces costs so you can afford expert review where it actually matters.

Your localization workflow should match your actual constraints, not some idealized best practice. You need to recognize what your content needs and build different workflows for different use cases

Early in my career, I thought success meant finding the perfect tool or the best translators. Now I know it's about building processes that don't break under pressure.

💙 A note about Localazy's lightweight philosophy 🔗

In the words of the Localazy CEO, Václav Hodek... ⬇️

"We build Localazy around a simple principle: AI handles volume so humans can focus on detail. A functional TMS shouldn’t be a bottleneck. It should drive the localization process forward.

The real value of localization isn’t in handling files or running automatic translations. Any modern TMS can do that. The real value is enabling collaboration between translators, developers, and reviewers to deliver translations your users can trust.

Localazy takes care of the entire localization infrastructure. Configure the workflow once, define quality gates, set translation triggers, specify who reviews what, and Localazy runs it automatically. Your localization team handles context, nuance, and quality, while you stay focused on building your product and shipping features without interruption. This gives you translation management that doesn't slow development and full control over the automation. Tools coordinate both AI and human translators without requiring your attention.

Lightweight doesn't mean fragile. It means intentional."

In this part, we’ll focus on functionality. You’ll build a complete invoice dashboard where users can create, edit, view, and delete invoices. We’ll also add handy features like printing, exporting, and importing, all while keeping the app clean, reactive, and localization-friendly.

By the end of this section, your app will display placeholders and will feel alive, interactive, and ready for multilingual support when we integrate Localazy in the final part.

1️⃣ Step 1: Build the dashboard 🔗

You’ll scaffold a dashboard screen as the app’s first view, then plug in a minimal Tailwind/i18n template.

1. Generate the dashboard component 🔗

Run this command from your project root:

npm run ng -- generate component features/dashboard --standalone

Angular CLI scaffolds the component under src/app/features/dashboard/:

dashboard.component.ts      // Component logic (TypeScript)
dashboard.component.html     // Template for layout & i18n text
dashboard.component.scss     // Local styling (will use Tailwind classes)

It also wires the component for standalone use.

2. Implementing the dashboard component 🔗

Next, let's implement the component:

src/app/features/dashboard/dashboard.component.ts

import { Component, ChangeDetectionStrategy } from '@angular/core';
import { RouterModule } from '@angular/router';
import { TranslateModule } from '@ngx-translate/core';

@Component({
  selector: 'app-dashboard',
  standalone: true,
  imports: [RouterModule, TranslateModule],
  templateUrl: './dashboard.component.html',
  styleUrls: ['./dashboard.component.scss'],
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class DashboardComponent {}

src/app/features/dashboard/dashboard.component.html

<section class="max-w-5xl mx-auto p-6">
  <header class="flex items-center gap-3 mb-6">
    <h2 class="text-2xl font-semibold">{{ 'dashboard.title' | translate }}</h2>
    <a routerLink="/invoice/new" class="btn ml-auto">
      {{ 'invoice.actions.create' | translate }}
    </a>
  </header>

  <div class="rounded-xl border border-dashed p-8 text-gray-600">
    {{ 'dashboard.empty' | translate }}
  </div>
</section>

3. Invoice Edit component 🔗

We’ll now create the Invoice Edit view, wire up its template, add the needed i18n keys, and define lazy-loaded routes for a lightweight Angular app. Generate the standalone component first, then replace its files with the code below.

src/app/features/invoice-edit/invoice-edit.component.ts

import { Component, ChangeDetectionStrategy } from '@angular/core';
import { RouterModule } from '@angular/router';
import { TranslateModule } from '@ngx-translate/core';

@Component({
  selector: 'app-invoice-edit',
  standalone: true,
  imports: [RouterModule, TranslateModule],
  templateUrl: './invoice-edit.component.html',
  styleUrls: ['./invoice-edit.component.scss'],
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class InvoiceEditComponent {}

Like the dashboard, this component uses Angular’s standalone API, importing both the RouterModule and TranslateModule directly. The OnPush change detection keeps the UI performant as the project scales with invoice forms and API data.

src/app/features/invoice-edit/invoice-edit.component.html

<section class="max-w-3xl mx-auto p-6 space-y-4">
  <h2 class="text-2xl font-semibold">{{ 'invoice.edit.title' | translate }}</h2>
  <p class="text-gray-600">{{ 'invoice.edit.placeholder' | translate }}</p>

  <a routerLink="/" class="btn-secondary inline-flex items-center">
    {{ 'nav.back' | translate }}
  </a>
</section>

4. Add translation keys 🔗

Place these in public/assets/i18n/ so ngx-translate (and later Localazy) can sync them.

public/assets/i18n/en.json

{
  "app": {
    "title": "Welcome to Your Invoice & Expense Tracker",
  },
  "dashboard": {
    "title": "Dashboard",
    "empty": "No invoices yet. Create your first invoice."
  },
  "invoice": {
    "edit": {
      "title": "New Invoice",
      "placeholder": "Form coming next."
    },
    "actions": {
      "create": "Create Invoice"
    }
  },
  "nav": {
    "back": "Back"
  }
}

public/assets/i18n/fr.json

{
  "app": {
    "title": "Bienvenue dans votre outil de suivi des factures et des dépenses",
  },
  "dashboard": {
    "title": "Tableau de bord",
    "empty": "Aucune facture pour le moment. Créez votre première facture."
  },
  "invoice": {
    "edit": {
      "title": "Nouvelle facture",
      "placeholder": "Formulaire à venir."
    },
    "actions": {
      "create": "Créer une facture"
    }
  },
  "nav": {
    "back": "Retour"
  }
}

5. Define routes with lazy loading 🔗

Create/update src/app/app.routes.ts to lazy-load screens. See Angular Router docs for reference: angular.dev > Guide > Router.

import { Routes } from '@angular/router';

export const routes: Routes = [
  {
    path: '',
    pathMatch: 'full',
    loadComponent: () =>
      import('./features/dashboard/dashboard.component').then(m => m.DashboardComponent),
  },
  {
    path: 'invoice/new',
    loadComponent: () =>
      import('./features/invoice-edit/invoice-edit.component').then(m => m.InvoiceEditComponent),
  },
  {
    path: 'invoice/:id',
    loadComponent: () =>
      import('./features/invoice-edit/invoice-edit.component').then(m => m.InvoiceEditComponent),
  },
  { path: '**', redirectTo: '' },
];

This routing setup ensures that:

• / loads the Dashboard (your main screen).
• /invoice/new opens the Invoice Editor for creating a new invoice.
• /invoice/:id reuses the same component for editing an existing invoice.
• Any undefined route gracefully redirects back to the Dashboard.

6. Run & verify 🔗

Start your local server to check that everything works:

npm start

Then open http://localhost:4200 and verify that:

• The Dashboard loads with a localized title and Create Invoice button.
• By clicking, it opens the Invoice Edit screen with the Back button styled using .btn-secondary.
• Text is updated when switching languages, confirming that ngx-translate and Tailwind have been correctly integrated.

2️⃣ Step 2: Set up the invoice models and store 🔗

Define the app’s data layer so the UI and i18n stay clean. We’ll model invoices and line items first, then wire a lightweight store next.

1. Create the models 🔗

Start by defining the core data structures that your invoice app will use: invoices, line items, and their statuses. These models form the foundation of your store and components.

File: src/app/core/models/invoice.model.ts

export type InvoiceStatus = 'draft' | 'sent' | 'paid';

export interface LineItem {
  id: string;
  description: string;
  quantity: number;
  unitPrice: number;
  taxRate?: number;
  discountRate?: number;
}

export interface Invoice {
  id: string;
  number: string;
  clientName: string;
  clientEmail?: string;
  issueDate: string;
  dueDate?: string;
  currency: string;
  items: LineItem[];
  notes?: string;
  status: InvoiceStatus;
  createdAt: string;
  updatedAt: string;
}

These models define the structure of invoices and line items, ensuring consistent data handling across components and simplifying integration with the store.

2. Create the Signal-based store with Persistence 🔗

Use Angular signals to manage the invoice state without extra libraries. This store exposes reactive selectors (via computed), persists to localStorage with an effect, and keeps your components lean.

src/app/core/stores/invoice.store.ts

import { Injectable, computed, effect, signal } from '@angular/core';
import { Invoice, InvoiceStatus, LineItem } from '../models/invoice.model';

const STORAGE_KEY = 'invoice.store.v1';

function nowIso() { return new Date().toISOString(); }
function newId()  { return (globalThis.crypto?.randomUUID?.() ?? Math.random().toString(36).slice(2)); }

function calcLineTotal(li: LineItem): number {
  const qty = Math.max(0, li.quantity || 0);
  const price = Math.max(0, li.unitPrice || 0);
  const preTax = qty * price;
  const discount = li.discountRate ? preTax * (li.discountRate / 100) : 0;
  const afterDiscount = preTax - discount;
  const tax = li.taxRate ? afterDiscount * (li.taxRate / 100) : 0;
  return +(afterDiscount + tax).toFixed(2);
}

function calcInvoiceTotal(inv: Invoice): number {
  return +inv.items.reduce((sum, li) => sum + calcLineTotal(li), 0).toFixed(2);
}

function load(): Invoice[] {
  try {
    const raw = localStorage.getItem(STORAGE_KEY);
    if (!raw) return [];
    const parsed = JSON.parse(raw) as Invoice[];
    // basic sanity
    return Array.isArray(parsed) ? parsed : [];
  } catch {
    return [];
  }
}

@Injectable({ providedIn: 'root' })
export class InvoiceStore {
  private readonly _invoices = signal<Invoice[]>(load());

  // Persist to localStorage on change
  private readonly _persist = effect(() => {
    const value = JSON.stringify(this._invoices());
    localStorage.setItem(STORAGE_KEY, value);
  });

  // Selectors
  readonly invoices = this._invoices.asReadonly();
  totalCount = computed(() => this._invoices().length);
  totalByStatus = (status: InvoiceStatus) => computed(
    () => this._invoices().filter(i => i.status === status).length
  );
  byId = (id: string) => computed(() => this._invoices().find(i => i.id === id) || null);
  totalAmount = (id: string) => computed(() => {
    const inv = this._invoices().find(i => i.id === id);
    return inv ? calcInvoiceTotal(inv) : 0;
  });

  // Mutations
  createDraft(partial?: Partial<Invoice>): Invoice {
    const id = newId();
    const created = nowIso();
    const number = this.nextNumber();
    const invoice: Invoice = {
      id,
      number,
      clientName: partial?.clientName ?? '',
      clientEmail: partial?.clientEmail,
      issueDate: partial?.issueDate ?? new Date().toISOString().slice(0, 10),
      dueDate: partial?.dueDate,
      currency: partial?.currency ?? 'USD',
      items: partial?.items ?? [this.newLineItem()],
      notes: partial?.notes,
      status: partial?.status ?? 'draft',
      createdAt: created,
      updatedAt: created,
    };
    this._invoices.update(arr => [invoice, ...arr]);
    return invoice;
  }

  update(id: string, changes: Partial<Invoice>): void {
    this._invoices.update(arr =>
      arr.map(inv => inv.id === id ? { ...inv, ...changes, updatedAt: nowIso() } : inv)
    );
  }

  remove(id: string): void {
    this._invoices.update(arr => arr.filter(inv => inv.id !== id));
  }

  // ---- Line item helpers
  newLineItem(): LineItem {
    return { id: newId(), description: '', quantity: 1, unitPrice: 0, taxRate: 0, discountRate: 0 };
  }

  addLineItem(invoiceId: string, li?: Partial<LineItem>): void {
    this._invoices.update(arr =>
      arr.map(inv => inv.id === invoiceId
        ? { ...inv, items: [{ ...this.newLineItem(), ...li, id: newId() }, ...inv.items], updatedAt: nowIso() }
        : inv
      )
    );
  }

  updateLineItem(invoiceId: string, itemId: string, changes: Partial<LineItem>): void {
    this._invoices.update(arr =>
      arr.map(inv => {
        if (inv.id !== invoiceId) return inv;
        const items = inv.items.map(it => it.id === itemId ? { ...it, ...changes } : it);
        return { ...inv, items, updatedAt: nowIso() };
      })
    );
  }

  removeLineItem(invoiceId: string, itemId: string): void {
    this._invoices.update(arr =>
      arr.map(inv => {
        if (inv.id !== invoiceId) return inv;
        const items = inv.items.filter(it => it.id !== itemId);
        return { ...inv, items, updatedAt: nowIso() };
      })
    );
  }

  setStatus(id: string, status: InvoiceStatus) {
    this.update(id, { status });
  }

  // Utilities
  private nextNumber(): string {
    const seq = this._invoices().length + 1;
    return `INV-${String(seq).padStart(4, '0')}`;
  }
}

This setup lets you handle invoices in real time while keeping data in sync across sessions.

Because it’s based on Angular’s built-in reactivity, the store stays small, fast, and ready to scale alongside your localized UI managed with ngx-translate and Localazy.

3. Add i18n keys for statuses 🔗

Before displaying invoice statuses in the UI, define their localized labels.

This ensures values like Draft, Sent, and Paid are translated dynamically in any language your app supports.

public/assets/i18n/en.json

{
  "status": {
    "draft": "Draft",
    "sent": "Sent",
    "paid": "Paid"
  }
}

public/assets/i18n/fr.json

{
  "status": {
    "draft": "Brouillon",
    "sent": "Envoyée",
    "paid": "Payée"
  }
}

4. Update the dashboard component to read from the store 🔗

Now that your store is ready, update the dashboard to pull invoice data directly from it. This step lets you display stored invoices, totals, and statuses with live updates.

File: src/app/features/dashboard/dashboard.component.ts

import { Component, ChangeDetectionStrategy, inject } from '@angular/core';
import { RouterModule } from '@angular/router';
import { TranslateModule } from '@ngx-translate/core';
import { CurrencyPipe, DatePipe } from '@angular/common';
import { InvoiceStore } from '../../core/stores/invoice.store';
import { Invoice } from '../../core/models/invoice.model';

@Component({
  selector: 'app-dashboard',
  standalone: true,
  imports: [RouterModule, TranslateModule, CurrencyPipe, DatePipe],
  templateUrl: './dashboard.component.html',
  styleUrls: ['./dashboard.component.scss'],
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class DashboardComponent {
  private readonly store = inject(InvoiceStore);
  invoices = this.store.invoices; // signal<Invoice[]>

  // demo: create a draft quickly
  createSample() {
    this.store.createDraft({
      clientName: 'Acme Corp',
      currency: 'USD',
      items: [
        { id: crypto.randomUUID(), description: 'Design work', quantity: 3, unitPrice: 120, taxRate: 10 },
      ],
      status: 'draft',
    });
  }

  total(inv: Invoice): number {
    // Avoid recomputing across the list by using store.totalAmount(inv.id) if you prefer computed-per-id
    return this.store.totalAmount(inv.id)();
  }

  statusClass(status: Invoice['status']): string {
    switch (status) {
      case 'paid':  return 'bg-green-100 text-green-700';
      case 'sent':  return 'bg-amber-100 text-amber-700';
      default:      return 'bg-gray-100 text-gray-700';
    }
  }
}

Now update the file src/app/features/dashboard/dashboard.component.html.

<section class="max-w-5xl mx-auto p-6 space-y-4">
  <header class="flex items-center gap-3">
    <h2 class="text-2xl font-semibold">{{ 'dashboard.title' | translate }}</h2>
    <a routerLink="/invoice/new" class="btn ml-auto">
      {{ 'invoice.actions.create' | translate }}
    </a>
    <button class="btn-secondary" type="button" (click)="createSample()">+ Sample</button>
  </header>

  @if (invoices().length === 0) {
    <div class="rounded-xl border border-dashed p-8 text-gray-600">
      {{ 'dashboard.empty' | translate }}
    </div>
  } @else {
    <ul class="space-y-3">
      @for (inv of invoices(); track inv.id) {
        <li class="rounded-xl border p-4 hover:shadow-sm transition">
          <div class="flex items-center gap-3">
            <div class="font-semibold">{{ inv.number }}</div>
            <div class="text-gray-600">•</div>
            <div class="text-gray-800">{{ inv.clientName || '—' }}</div>
            <div class="text-gray-500 ml-auto flex items-center gap-3">
              <span class="px-2 py-1 rounded-md text-xs" [class]="statusClass(inv.status)">
                {{ ('status.' + inv.status) | translate }}
              </span>
              <span class="text-sm">
                {{ inv.issueDate | date:'mediumDate' }}
              </span>
              <strong class="ml-2">
                {{ total(inv) | currency: inv.currency:'symbol-narrow' }}
              </strong>
            </div>
          </div>
        </li>
      }
    </ul>
  }
</section>

5. Update the root component & language switcher 🔗

Wire up the app-wide language controls so every screen (Dashboard, Invoice Edit) updates instantly with ngx-translate. This uses Angular standalone components and a small service to manage runtime i18n.

File: src/app/app.ts

import { Component, ChangeDetectionStrategy, inject } from '@angular/core';
import { RouterOutlet } from '@angular/router';
import { TranslateModule } from '@ngx-translate/core';
import { LanguageService } from './core/language.service';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [RouterOutlet, TranslateModule],
  changeDetection: ChangeDetectionStrategy.OnPush,
  templateUrl: './app.html',
  styleUrl: './app.scss',
})
export class App {
  private readonly lang = inject(LanguageService);
  setLang(l: 'en' | 'fr') { this.lang.use(l); }
}

In app.html, the header displays the translated title and language buttons, while <router-outlet> loads the active view. Each button calls setLang() to toggle between English and French.

<header class="flex items-center gap-3 p-4 border-b">
  <h1 class="text-xl font-semibold">{{ 'app.title' | translate }}</h1>
  <div class="ml-auto flex items-center gap-2">
    <button type="button" class="btn" (click)="setLang('en')">EN</button>
    <button type="button" class="btn-secondary" (click)="setLang('fr')">FR</button>
  </div>
</header>

<main class="p-4">
  <router-outlet></router-outlet>
</main>

The LanguageService registers available locales, remembers the last selected language, and updates the <html lang>attribute. This keeps translations consistent across routes and sessions.

import { Injectable } from '@angular/core';
import { TranslateService } from '@ngx-translate/core';

type Lang = 'en' | 'fr';

@Injectable({ providedIn: 'root' })
export class LanguageService {
  private readonly storageKey = 'lang';
  private readonly supported: readonly Lang[] = ['en', 'fr'] as const;

  constructor(private t: TranslateService) {}

  init(): void {
    this.t.addLangs([...this.supported]);
    const saved = (localStorage.getItem(this.storageKey) as Lang | null) ?? this.matchNavigator();
    this.use(saved);
  }

  use(lang: string): void {
    const chosen: Lang =
      (this.supported as readonly string[]).includes(lang as Lang) ? (lang as Lang) : 'en';

    localStorage.setItem(this.storageKey, chosen);
    document.documentElement.lang = chosen;
    this.t.use(chosen);
  }

  private matchNavigator(): Lang {
    const base = (navigator.language || navigator.languages?.[0] || 'en').slice(0, 2) as Lang;
    return (this.supported as readonly string[]).includes(base) ? base : 'en';
  }
}

Together, these three files finalize your localization flow. When the user clicks EN or FR, the entire interface Dashboard, Invoice Edit, and all status labels updates instantly.

6. Add locale-aware formatting 🔗

Next, create a src/app/core/locale-format.service.ts file to handle language-aware number and date formatting across the app. This service listens to the active language from ngx-translate using Angular signals, so all amounts and dates update automatically when users switch languages. It exposes two helpers: currency() for localized prices and dateISO() for readable dates, both used by the dashboard and upcoming invoice views.

import { Injectable, signal } from '@angular/core';
import { TranslateService } from '@ngx-translate/core';

@Injectable({ providedIn: 'root' })
export class LocaleFormatService {
  lang = signal('en');

  constructor(private t: TranslateService) {
    this.lang.set(this.t.currentLang || 'en');
    this.t.onLangChange.subscribe(e => this.lang.set(e.lang));
  }

  currency(amount: number, currency: string): string {
    return new Intl.NumberFormat(this.lang(), { style: 'currency', currency }).format(amount);
  }

  dateISO(isoDate: string): string {
    return new Intl.DateTimeFormat(this.lang(), { dateStyle: 'medium' }).format(new Date(isoDate));
  }
}

Now update src/app/features/dashboard/dashboard.component.ts to use this service. Import LocaleFormatService, inject it inside the class, and replace the currency and date pipes with the new helper methods. This ensures that totals and issue dates reformat automatically whenever the language changes.

import { LocaleFormatService } from '../../core/locale-format.service';

Inject the service inside the class:

private readonly fmt = inject(LocaleFormatService);

Use this.fmt.currency() and this.fmt.dateISO() to format totals and issue dates:

import { LocaleFormatService } from '../../core/locale-format.service';

private readonly fmt = inject(LocaleFormatService);

{{ fmt.currency(total, inv.currency) }}
{{ fmt.dateISO(inv.issueDate) }}

7. Run & verify 🔗

npm start

• Open http://localhost:4200.
• Click + Sample — a demo invoice appears instantly.
• All text and status labels translate dynamically through ngx-translate, confirming your Angular localization and store setup work together correctly.
• Toggle EN/FR to confirm translations and status labels updates.

3️⃣ Step 3: Refactor the store 🔗

To keep the store maintainable and modular, we’ll extract helper functions and logic into smaller dedicated files. This makes it easier to reuse utilities across the app and keeps the core store focused on state management.

1. Create an ID generator 🔗

Start by creating a small ID generator in src/app/core/utils/id.ts. This helper provides a lightweight, consistent way to create unique identifiers throughout the app.

export const newId = (): string =>
  globalThis.crypto?.randomUUID?.() ?? 'id-' + Math.random().toString(36).slice(2);

Next, open src/app/core/stores/invoice.store.ts, import the helper, and remove the inline ID logic.

import { newId } from '../utils/id';

Replace every reference to the old generator with newId(). This simple change ensures that all IDs follow a single standard:

• sanitizeItem(...)
• sanitizeInvoice(...)
• createDraft(...)
• newLineItem(...)

2. Set up a shared time utility 🔗

Now let’s move timestamp handling into its own utility. Create src/app/core/utils/time.ts with:

export const isoNow = (): string => new Date().toISOString();

Then remove the old local helper entirely:

// const isoNow = () => new Date().toISOString();

Next, import it into the store and delete the inline version to keep date logic consistent and easy to test.

Now extract all financial calculations into a reusable module.

Create src/app/core/utils/money.ts and add:

import type { LineItem, Invoice } from '../models/invoice.model';

/** Calculate a single line item total (after discount, plus tax). */
export function lineTotal(li: LineItem): number {
  const qty = Math.max(0, li.quantity || 0);
  const price = Math.max(0, li.unitPrice || 0);
  const gross = qty * price;
  const discount = li.discountRate ? gross * (li.discountRate / 100) : 0;
  const afterDiscount = gross - discount;
  const tax = li.taxRate ? afterDiscount * (li.taxRate / 100) : 0;
  return +(afterDiscount + tax).toFixed(2);
}

/** Sum all line items for an invoice. */
export function invoiceTotal(inv: Invoice): number {
  return +inv.items.reduce((s, li) => s + lineTotal(li), 0).toFixed(2);
}

The store now relies on a shared time utility, keeping the codebase cleaner and easier to maintain.

3. Centralize the store's financial logic 🔗

Let’s clean up the financial logic in the store by moving all money-related calculations into their own utility file. Start by creating src/app/core/utils/money.ts and add the following code:

import type { LineItem, Invoice } from '../models/invoice.model';

/** Calculate a single line item total (after discount, plus tax). */
export function lineTotal(li: LineItem): number {
  const qty = Math.max(0, li.quantity || 0);
  const price = Math.max(0, li.unitPrice || 0);
  const gross = qty * price;
  const discount = li.discountRate ? gross * (li.discountRate / 100) : 0;
  const afterDiscount = gross - discount;
  const tax = li.taxRate ? afterDiscount * (li.taxRate / 100) : 0;
  return +(afterDiscount + tax).toFixed(2);
}

/** Sum all line items for an invoice. */
export function invoiceTotal(inv: Invoice): number {
  return +inv.items.reduce((s, li) => s + lineTotal(li), 0).toFixed(2);
}

Next, open src/app/core/stores/invoice.store.ts and update it to use these new helpers.

Add the following import near the top of the file:

import { lineTotal, invoiceTotal } from '../utils/money';

Then remove the old inline calculation functions entirely:

function lineTotal(li: LineItem): number { /* ... */ }
function invoiceTotal(inv: Invoice): number { /* ... */ }

This refactor keeps your store lean and focused while centralizing all currency and total calculations in a single reusable utility.

4. Set up serialization 🔗

File: src/app/core/persistence/invoice.serialization.ts

import type { Invoice, LineItem } from '../models/invoice.model';
import { newId } from '../utils/id';
import { isoNow } from '../utils/time';

function num(v: unknown, fallback: number): number {
  const n = (typeof v === 'number' || typeof v === 'string') ? Number(v) : NaN;
  return Number.isFinite(n) ? n : fallback;
}

export function sanitizeItem(raw: unknown): LineItem {
  const r = (raw && typeof raw === 'object') ? raw as Record<string, unknown> : {};
  return {
    id: String(r.id ?? newId()),
    description: String(r.description ?? ''),
    quantity: num(r.quantity, 1),
    unitPrice: num(r.unitPrice, 0),
    taxRate: num(r.taxRate, 0),
    discountRate: num(r.discountRate, 0),
  };
}

const VALID_STATUS = new Set<Invoice['status']>(['draft', 'sent', 'paid']);

export function sanitizeInvoice(raw: unknown): Invoice | null {
  if (!raw || typeof raw !== 'object') return null;
  const r = raw as Record<string, unknown>;

  const itemsRaw = Array.isArray(r.items) ? r.items : [];
  const items = itemsRaw.map(sanitizeItem);

  const status = VALID_STATUS.has(r.status as Invoice['status'])
    ? (r.status as Invoice['status'])
    : 'draft';

  return {
    id: String(r.id ?? newId()),
    number: String(r.number ?? 'INV-XXXX'),
    clientName: String(r.clientName ?? ''),
    clientEmail: r.clientEmail ? String(r.clientEmail) : undefined,
    issueDate: String(r.issueDate ?? new Date().toISOString().slice(0, 10)),
    dueDate: r.dueDate ? String(r.dueDate) : undefined,
    currency: String(r.currency ?? 'USD'),
    items,
    notes: r.notes ? String(r.notes) : undefined,
    status,
    createdAt: String(r.createdAt ?? isoNow()),
    updatedAt: String(r.updatedAt ?? isoNow()),
  };
}

Then update the store to use the serializer. Replace the store file with the version below. Behavior stays the same; the only change is that parsing/validation is delegated to the serializers.

src/app/core/stores/invoice.store.ts

import { Injectable, computed, effect, signal } from '@angular/core';
import { Invoice, InvoiceStatus, LineItem } from '../models/invoice.model';
import { newId } from '../utils/id';
import { isoNow } from '../utils/time';
import { invoiceTotal } from '../utils/money';
import { sanitizeInvoice } from '../persistence/invoice.serialization';

// nstants
const STORAGE_KEY = 'invoice.store.v1';

// load
function load(): Invoice[] {
  try {
    const raw = JSON.parse(localStorage.getItem(STORAGE_KEY) || '[]');
    if (!Array.isArray(raw)) return [];
    return raw.map(sanitizeInvoice).filter(Boolean) as Invoice[];
  } catch {
    return [];
  }
}

// store
@Injectable({ providedIn: 'root' })
export class InvoiceStore {
  private readonly _invoices = signal<Invoice[]>(load());

  // throttle persistence to avoid excessive writes
  private persistTimer: any = null;
  private readonly _persist = effect(() => {
    const snapshot = this._invoices();
    clearTimeout(this.persistTimer);
    this.persistTimer = setTimeout(() => {
      try { localStorage.setItem(STORAGE_KEY, JSON.stringify(snapshot)); } catch {}
    }, 120);
  });

  // precompute totals map for O(1) lookup
  private readonly totalsById = computed(() => {
    const map = new Map<string, number>();
    for (const inv of this._invoices()) map.set(inv.id, invoiceTotal(inv));
    return map;
  });

  // selectors
  readonly invoices = this._invoices.asReadonly();
  byId = (id: string) => computed(() => this._invoices().find(i => i.id === id) ?? null);
  totalAmount = (id: string) => computed(() => this.totalsById().get(id) ?? 0);
  totalCount = computed(() => this._invoices().length);
  totalByStatus = (status: InvoiceStatus) =>
    computed(() => this._invoices().filter(i => i.status === status).length);

  // mutations 
  createDraft(partial?: Partial<Invoice>): Invoice {
    const id = newId();
    const created = isoNow();
    const number = this.nextNumber();
    const invoice: Invoice = {
      id,
      number,
      clientName: partial?.clientName ?? '',
      clientEmail: partial?.clientEmail,
      issueDate: partial?.issueDate ?? new Date().toISOString().slice(0, 10),
      dueDate: partial?.dueDate,
      currency: partial?.currency ?? 'USD',
      items: partial?.items ?? [this.newLineItem()],
      notes: partial?.notes,
      status: partial?.status ?? 'draft',
      createdAt: created,
      updatedAt: created,
    };
    this._invoices.update(arr => [invoice, ...arr]);
    return invoice;
  }

  update(id: string, changes: Partial<Invoice>): void {
    this._invoices.update(arr =>
      arr.map(inv => (inv.id === id ? { ...inv, ...changes, updatedAt: isoNow() } : inv)),
    );
  }

  remove(id: string): void {
    this._invoices.update(arr => arr.filter(inv => inv.id !== id));
  }

  // line items 
  newLineItem(): LineItem {
    return { id: newId(), description: '', quantity: 1, unitPrice: 0, taxRate: 0, discountRate: 0 };
  }

  addLineItem(invoiceId: string, li?: Partial<LineItem>): void {
    this._invoices.update(arr =>
      arr.map(inv =>
        inv.id === invoiceId
          ? {
              ...inv,
              items: [{ ...this.newLineItem(), ...li, id: newId() }, ...inv.items],
              updatedAt: isoNow(),
            }
          : inv,
      ),
    );
  }

  updateLineItem(invoiceId: string, itemId: string, changes: Partial<LineItem>): void {
    this._invoices.update(arr =>
      arr.map(inv => {
        if (inv.id !== invoiceId) return inv;
        const items = inv.items.map(it => (it.id === itemId ? { ...it, ...changes } : it));
        return { ...inv, items, updatedAt: isoNow() };
      }),
    );
  }

  removeLineItem(invoiceId: string, itemId: string): void {
    this._invoices.update(arr =>
      arr.map(inv => {
        if (inv.id !== invoiceId) return inv;
        const items = inv.items.filter(it => it.id !== itemId);
        return { ...inv, items, updatedAt: isoNow() };
      }),
    );
  }

  setStatus(id: string, status: InvoiceStatus): void {
    this.update(id, { status });
  }

  // utilities 
  private nextNumber(): string {
    const seq = this._invoices().length + 1;
    return `INV-${String(seq).padStart(4, '0')}`;
  }
}

The goal is to keep the store “loose”: state and mutations live in one place, while parsing/validation and core calculations are modular and reusable.

5. Register and connect the new repository 🔗

To finish the persistence setup, register your new repository provider inside the app configuration. Thanks to this, Angular will inject the correct implementation (LocalStorageInvoiceRepository) wherever the INVOICE_REPOSITORY token is requested.

Create src/app/core/persistence/invoice.repository.ts

import { InjectionToken } from '@angular/core';
import type { Invoice } from '../models/invoice.model';
import { sanitizeInvoice } from './invoice.serialization';

export interface InvoiceRepository {
  load(): Invoice[];
  save(data: Invoice[]): void;
}

export const INVOICE_REPOSITORY = new InjectionToken<InvoiceRepository>('INVOICE_REPOSITORY');

export class LocalStorageInvoiceRepository implements InvoiceRepository {
  private readonly KEY = 'invoice.store.v2';

  load(): Invoice[] {
    try {
      const raw = localStorage.getItem(this.KEY);
      if (!raw) return [];
      const parsed: unknown = JSON.parse(raw);

      // Accept v1 (array) or v2 ({ version, data })
      const arr = Array.isArray(parsed)
        ? parsed
        : (parsed && typeof parsed === 'object' && Array.isArray((parsed as any).data))
          ? (parsed as any).data
          : [];

      const out: Invoice[] = [];
      for (const it of arr) {
        const inv = sanitizeInvoice(it);
        if (inv) out.push(inv);
      }
      return out;
    } catch {
      return [];
    }
  }

  save(data: Invoice[]): void {
    try {
      const payload = { version: 2, data };
      localStorage.setItem(this.KEY, JSON.stringify(payload));
    } catch {
      // ignore quota/security errors
    }
  }
}

Update src/app/app.config.ts by adding the provider below your existing imports and configuration:

// ...existing imports...
import { INVOICE_REPOSITORY, LocalStorageInvoiceRepository } from './core/persistence/invoice.repository';

export const appConfig: ApplicationConfig = {
  providers: [
    // ...existing providers...
    { provide: INVOICE_REPOSITORY, useClass: LocalStorageInvoiceRepository },
  ],
};

This registration connects your dependency injection system to the repository class, allowing your store and future services to interact cleanly with invoice data through a unified interface, rather than hard-coding persistence logic.

Update the store to use the repository src/app/core/stores/invoice.store.ts:

import { Injectable, computed, effect, inject, signal } from '@angular/core';
import { Invoice, InvoiceStatus, LineItem } from '../models/invoice.model';
import { newId } from '../utils/id';
import { isoNow } from '../utils/time';
import { invoiceTotal } from '../utils/money';
import { INVOICE_REPOSITORY, InvoiceRepository } from '../persistence/invoice.repository';

@Injectable({ providedIn: 'root' })
export class InvoiceStore {
  // repo abstraction (can be swapped via DI)
  private readonly repo: InvoiceRepository = inject(INVOICE_REPOSITORY);

  // state
  private readonly _invoices = signal<Invoice[]>(this.repo.load());

  // throttle persistence via repo to avoid excessive writes
  private persistTimer: any = null;
  private readonly _persist = effect(() => {
    const snapshot = this._invoices();
    clearTimeout(this.persistTimer);
    this.persistTimer = setTimeout(() => {
      this.repo.save(snapshot);
    }, 120);
  });

  // precompute totals map for O(1) lookup
  private readonly totalsById = computed(() => {
    const map = new Map<string, number>();
    for (const inv of this._invoices()) map.set(inv.id, invoiceTotal(inv));
    return map;
  });

  // selectors
  readonly invoices = this._invoices.asReadonly();
  byId = (id: string) => computed(() => this._invoices().find(i => i.id === id) ?? null);
  totalAmount = (id: string) => computed(() => this.totalsById().get(id) ?? 0);
  totalCount = computed(() => this._invoices().length);
  totalByStatus = (status: InvoiceStatus) =>
    computed(() => this._invoices().filter(i => i.status === status).length);

  // mutations 
  createDraft(partial?: Partial<Invoice>): Invoice {
    const id = newId();
    const created = isoNow();
    const number = this.nextNumber();
    const invoice: Invoice = {
      id,
      number,
      clientName: partial?.clientName ?? '',
      clientEmail: partial?.clientEmail,
      issueDate: partial?.issueDate ?? new Date().toISOString().slice(0, 10),
      dueDate: partial?.dueDate,
      currency: partial?.currency ?? 'USD',
      items: partial?.items ?? [this.newLineItem()],
      notes: partial?.notes,
      status: partial?.status ?? 'draft',
      createdAt: created,
      updatedAt: created,
    };
    this._invoices.update(arr => [invoice, ...arr]);
    return invoice;
  }

  update(id: string, changes: Partial<Invoice>): void {
    this._invoices.update(arr =>
      arr.map(inv => (inv.id === id ? { ...inv, ...changes, updatedAt: isoNow() } : inv)),
    );
  }

  remove(id: string): void {
    this._invoices.update(arr => arr.filter(inv => inv.id !== id));
  }

  // line items 
  newLineItem(): LineItem {
    return { id: newId(), description: '', quantity: 1, unitPrice: 0, taxRate: 0, discountRate: 0 };
  }

  addLineItem(invoiceId: string, li?: Partial<LineItem>): void {
    this._invoices.update(arr =>
      arr.map(inv =>
        inv.id === invoiceId
          ? {
              ...inv,
              items: [{ ...this.newLineItem(), ...li, id: newId() }, ...inv.items],
              updatedAt: isoNow(),
            }
          : inv,
      ),
    );
  }

  updateLineItem(invoiceId: string, itemId: string, changes: Partial<LineItem>): void {
    this._invoices.update(arr =>
      arr.map(inv => {
        if (inv.id !== invoiceId) return inv;
        const items = inv.items.map(it => (it.id === itemId ? { ...it, ...changes } : it));
        return { ...inv, items, updatedAt: isoNow() };
      }),
    );
  }

  removeLineItem(invoiceId: string, itemId: string): void {
    this._invoices.update(arr =>
      arr.map(inv => {
        if (inv.id !== invoiceId) return inv;
        const items = inv.items.filter(it => it.id !== itemId);
        return { ...inv, items, updatedAt: isoNow() };
      }),
    );
  }

  setStatus(id: string, status: InvoiceStatus): void {
    this.update(id, { status });
  }

  // utilities 
  private nextNumber(): string {
    const seq = this._invoices().length + 1;
    return `INV-${String(seq).padStart(4, '0')}`;
  }
}

Then bind the repository in the app configuration:

import { INVOICE_REPOSITORY, LocalStorageInvoiceRepository } from './core/persistence/invoice.repository';

export const appConfig: ApplicationConfig = {
  providers: [
  
  ...
  
	// Repository binding    
	{ provide: INVOICE_REPOSITORY, useClass: LocalStorageInvoiceRepository },
	
 ],
};	

The store now depends on an abstract InvoiceRepository, LocalStorageInvoiceRepository implements it, and the app config provides the binding so Angular’s DI injects the correct implementation everywhere. This keeps your state layer clean, testable, and ready for future backends.

4️⃣ Step 4: Invoice editor form 🔗

Now it's time to replace the generated TypeScript file with this implementation (strongly-typed Reactive Forms, Tailwind-ready, i18n-friendly, and using your shared money utilities):

src/app/features/invoice-edit/invoice-edit.component.ts

import { Component, ChangeDetectionStrategy, inject } from '@angular/core';
import { CommonModule } from '@angular/common';
import { RouterModule } from '@angular/router';
import { TranslateModule } from '@ngx-translate/core';
import {
  ReactiveFormsModule,
  NonNullableFormBuilder,
  FormGroup,
  FormControl,
  FormArray,
  Validators,
} from '@angular/forms';

import { lineTotal, invoiceTotal } from '../../core/utils/money';

// Strongly-typed item group
type ItemControls = {
  description: FormControl<string>;
  quantity: FormControl<number>;
  unitPrice: FormControl<number>;
  taxRate: FormControl<number>;
  discountRate: FormControl<number>;
};
type ItemGroup = FormGroup<ItemControls>;

// Root form controls
type InvoiceFormControls = {
  clientName: FormControl<string>;
  clientEmail: FormControl<string | null>;
  issueDate: FormControl<string>;
  dueDate: FormControl<string | null>;
  currency: FormControl<'USD' | 'EUR' | 'XAF'>;
  notes: FormControl<string | null>;
  items: FormArray<ItemGroup>;
};
type InvoiceForm = FormGroup<InvoiceFormControls>;

@Component({
  selector: 'app-invoice-edit',
  standalone: true,
  imports: [CommonModule, RouterModule, TranslateModule, ReactiveFormsModule],
  templateUrl: './invoice-edit.component.html',
  styleUrl: './invoice-edit.component.scss',
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class InvoiceEditComponent {
  private fb = inject(NonNullableFormBuilder);

  // Build a new item row with typed controls
  private createItemGroup(): ItemGroup {
    return this.fb.group<ItemControls>({
      description: this.fb.control('', { validators: [] }),
      quantity: this.fb.control(1, { validators: [Validators.min(0)] }),
      unitPrice: this.fb.control(0, { validators: [Validators.min(0)] }),
      taxRate: this.fb.control(0, { validators: [Validators.min(0), Validators.max(100)] }),
      discountRate: this.fb.control(0, { validators: [Validators.min(0), Validators.max(100)] }),
    });
  }

  // Root form with strict types (non-nullable where appropriate)
  form: InvoiceForm = this.fb.group<InvoiceFormControls>({
    clientName: this.fb.control('', { validators: [Validators.required] }),
    clientEmail: new FormControl<string | null>(null, { nonNullable: false, validators: [Validators.email] }),
    issueDate: this.fb.control(new Date().toISOString().slice(0, 10)),
    dueDate: new FormControl<string | null>(null, { nonNullable: false }),
    currency: this.fb.control<'USD' | 'EUR' | 'XAF'>('USD'),
    notes: new FormControl<string | null>(null, { nonNullable: false }),
    items: this.fb.array<ItemGroup>([this.createItemGroup()]),
  });

  // items helpers 
  get items(): FormArray<ItemGroup> {
    return this.form.controls.items;
  }

  addItem(): void {
    this.items.push(this.createItemGroup());
  }

  removeItem(i: number): void {
    this.items.removeAt(i);
  }

  // totals
  lineTotalAt(index: number): number {
    const g = this.items.at(index).getRawValue(); 
    return lineTotal({
      id: 'tmp',
      description: g.description,
      quantity: g.quantity,
      unitPrice: g.unitPrice,
      taxRate: g.taxRate,
      discountRate: g.discountRate,
    });
  }

  grandTotal(): number {
    const v = this.form.getRawValue(); 
    return invoiceTotal({
      id: 'tmp',
      number: 'INV-TMP',
      clientName: v.clientName,
      clientEmail: v.clientEmail ?? undefined,
      issueDate: v.issueDate,
      dueDate: v.dueDate ?? undefined,
      currency: v.currency,
      items: v.items.map(it => {
        const row = it;
        return {
          id: 'tmp',
          description: row.description,
          quantity: row.quantity,
          unitPrice: row.unitPrice,
          taxRate: row.taxRate,
          discountRate: row.discountRate,
        };
      }),
      notes: v.notes ?? undefined,
      status: 'draft',
      createdAt: new Date().toISOString(),
      updatedAt: new Date().toISOString(),
    });
  }

  // actions
  save(): void {
    if (this.form.invalid) {
      this.form.markAllAsTouched();
      return;
    }
    // For now, just demo; next micro-step will persist via InvoiceStore.
    // Typed value:
    const value = this.form.getRawValue();
    console.log('[invoice-edit] value', value);
    alert('Form captured (no persistence yet). Next step: connect to store.');
  }
}

Update the src/app/features/invoice-edit/invoice-edit.component.htmltemplate, which lays out the client details, line items, and totals for the Invoice Editor using Tailwind utilities and ReactiveFormsModule bindings. It supports adding/removing items, shows each row’s computed total, and displays the grand total with simple, accessible form controls.

<form class="max-w-4xl mx-auto p-6 space-y-6" [formGroup]="form" (ngSubmit)="save()">
  <h2 class="text-2xl font-semibold">{{ 'invoice.edit.title' | translate }}</h2>

  <!-- Client block -->
  <div class="grid grid-cols-1 md:grid-cols-2 gap-4">
    <label class="flex flex-col gap-1">
      <span class="text-sm text-gray-600">{{ 'invoice.form.clientName' | translate }}</span>
      <input type="text" formControlName="clientName" class="rounded-lg border p-2" />
    </label>

    <label class="flex flex-col gap-1">
      <span class="text-sm text-gray-600">{{ 'invoice.form.clientEmail' | translate }}</span>
      <input type="email" formControlName="clientEmail" class="rounded-lg border p-2" />
    </label>

    <label class="flex flex-col gap-1">
      <span class="text-sm text-gray-600">{{ 'invoice.form.issueDate' | translate }}</span>
      <input type="date" formControlName="issueDate" class="rounded-lg border p-2" />
    </label>

    <label class="flex flex-col gap-1">
      <span class="text-sm text-gray-600">{{ 'invoice.form.dueDate' | translate }}</span>
      <input type="date" formControlName="dueDate" class="rounded-lg border p-2" />
    </label>

    <label class="flex flex-col gap-1">
      <span class="text-sm text-gray-600">{{ 'invoice.form.currency' | translate }}</span>
      <select formControlName="currency" class="rounded-lg border p-2">
        <option value="USD">USD</option>
        <option value="EUR">EUR</option>
        <option value="XAF">XAF</option>
      </select>
    </label>

    <label class="flex flex-col gap-1 md:col-span-2">
      <span class="text-sm text-gray-600">{{ 'invoice.form.notes' | translate }}</span>
      <textarea formControlName="notes" rows="3" class="rounded-lg border p-2"></textarea>
    </label>
  </div>

  <!-- Items -->
  <div class="space-y-3">
    <div class="flex items-center justify-between">
      <h3 class="text-lg font-semibold">{{ 'invoice.form.items' | translate }}</h3>
      <button type="button" class="btn" (click)="addItem()">{{ 'invoice.actions.addItem' | translate }}</button>
    </div>

    <div formArrayName="items" class="space-y-2">
      <div *ngFor="let g of items.controls; let i = index" [formGroupName]="i"
           class="grid grid-cols-12 gap-2 items-center border rounded-lg p-3">
        <input class="col-span-5 rounded-lg border p-2" type="text" placeholder="{{ 'invoice.form.item.description' | translate }}"
               formControlName="description" />

        <input class="col-span-2 rounded-lg border p-2" type="number" min="0" step="1"
               formControlName="quantity" placeholder="{{ 'invoice.form.item.quantity' | translate }}" />

        <input class="col-span-2 rounded-lg border p-2" type="number" min="0" step="0.01"
               formControlName="unitPrice" placeholder="{{ 'invoice.form.item.unitPrice' | translate }}" />

        <input class="col-span-1 rounded-lg border p-2" type="number" min="0" max="100" step="0.1"
               formControlName="taxRate" placeholder="{{ 'invoice.form.item.taxRate' | translate }}" />

        <input class="col-span-1 rounded-lg border p-2" type="number" min="0" max="100" step="0.1"
               formControlName="discountRate" placeholder="{{ 'invoice.form.item.discountRate' | translate }}" />

        <div class="col-span-12 md:col-span-10 text-sm text-gray-600 md:text-right">
          {{ 'invoice.form.item.total' | translate }}:
          <strong>{{ lineTotalAt(i) }}</strong>
        </div>

        <div class="col-span-12 md:col-span-2 flex justify-end">
          <button type="button" class="btn-secondary" (click)="removeItem(i)">
            {{ 'invoice.actions.removeItem' | translate }}
          </button>
        </div>
      </div>
    </div>
  </div>

  <!-- Totals + actions -->
  <div class="flex items-center justify-between border-t pt-4">
    <div class="text-lg">
      {{ 'invoice.form.total' | translate }}:
      <strong>{{ grandTotal() }}</strong>
    </div>
    <div class="flex gap-2">
      <a routerLink="/" class="btn-secondary">{{ 'nav.back' | translate }}</a>
      <button type="submit" class="btn">{{ 'invoice.actions.save' | translate }}</button>
    </div>
  </div>
</form>

Then replace the src/app/features/invoice-edit/invoice-edit.html with the version below. It binds a typed Reactive Form, uses Tailwind for layout, supports add/remove rows, shows each row’s computed total, and displays the grand total.

<form class="max-w-4xl mx-auto p-6 space-y-6" [formGroup]="form" (ngSubmit)="save()">
  <h2 class="text-2xl font-semibold">{{ 'invoice.edit.title' | translate }}</h2>

  <!-- Client block -->
  <div class="grid grid-cols-1 md:grid-cols-2 gap-4">
    <label class="flex flex-col gap-1">
      <span class="text-sm text-gray-600">{{ 'invoice.form.clientName' | translate }}</span>
      <input type="text" formControlName="clientName" class="rounded-lg border p-2" />
    </label>

    <label class="flex flex-col gap-1">
      <span class="text-sm text-gray-600">{{ 'invoice.form.clientEmail' | translate }}</span>
      <input type="email" formControlName="clientEmail" class="rounded-lg border p-2" />
    </label>

    <label class="flex flex-col gap-1">
      <span class="text-sm text-gray-600">{{ 'invoice.form.issueDate' | translate }}</span>
      <input type="date" formControlName="issueDate" class="rounded-lg border p-2" />
    </label>

    <label class="flex flex-col gap-1">
      <span class="text-sm text-gray-600">{{ 'invoice.form.dueDate' | translate }}</span>
      <input type="date" formControlName="dueDate" class="rounded-lg border p-2" />
    </label>

    <label class="flex flex-col gap-1">
      <span class="text-sm text-gray-600">{{ 'invoice.form.currency' | translate }}</span>
      <select formControlName="currency" class="rounded-lg border p-2">
        <option value="USD">USD</option>
        <option value="EUR">EUR</option>
        <option value="XAF">XAF</option>
      </select>
    </label>

    <label class="flex flex-col gap-1 md:col-span-2">
      <span class="text-sm text-gray-600">{{ 'invoice.form.notes' | translate }}</span>
      <textarea formControlName="notes" rows="3" class="rounded-lg border p-2"></textarea>
    </label>
  </div>

  <!-- Items -->
  <div class="space-y-3">
    <div class="flex items-center justify-between">
      <h3 class="text-lg font-semibold">{{ 'invoice.form.items' | translate }}</h3>
      <button type="button" class="btn" (click)="addItem()">{{ 'invoice.actions.addItem' | translate }}</button>
    </div>

    <div formArrayName="items" class="space-y-2">
      <div *ngFor="let g of items.controls; let i = index" [formGroupName]="i"
           class="grid grid-cols-12 gap-2 items-center border rounded-lg p-3">
        <input class="col-span-5 rounded-lg border p-2" type="text"
               placeholder="{{ 'invoice.form.item.description' | translate }}"
               formControlName="description" />

        <input class="col-span-2 rounded-lg border p-2" type="number" min="0" step="1"
               formControlName="quantity" placeholder="{{ 'invoice.form.item.quantity' | translate }}" />

        <input class="col-span-2 rounded-lg border p-2" type="number" min="0" step="0.01"
               formControlName="unitPrice" placeholder="{{ 'invoice.form.item.unitPrice' | translate }}" />

        <input class="col-span-1 rounded-lg border p-2" type="number" min="0" max="100" step="0.1"
               formControlName="taxRate" placeholder="{{ 'invoice.form.item.taxRate' | translate }}" />

        <input class="col-span-1 rounded-lg border p-2" type="number" min="0" max="100" step="0.1"
               formControlName="discountRate" placeholder="{{ 'invoice.form.item.discountRate' | translate }}" />

        <div class="col-span-12 md:col-span-10 text-sm text-gray-600 md:text-right">
          {{ 'invoice.form.item.total' | translate }}:
          <strong>{{ lineTotalAt(i) }}</strong>
        </div>

        <div class="col-span-12 md:col-span-2 flex justify-end">
          <button type="button" class="btn-secondary" (click)="removeItem(i)">
            {{ 'invoice.actions.removeItem' | translate }}
          </button>
        </div>
      </div>
    </div>
  </div>

  <!-- Totals + actions -->
  <div class="flex items-center justify-between border-t pt-4">
    <div class="text-lg">
      {{ 'invoice.form.total' | translate }}:
      <strong>{{ grandTotal() }}</strong>
    </div>
    <div class="flex gap-2">
      <a routerLink="/" class="btn-secondary">{{ 'nav.back' | translate }}</a>
      <button type="submit" class="btn">{{ 'invoice.actions.save' | translate }}</button>
    </div>
  </div>
</form>

Don’t forget to update the translations:

{
  "invoice": {
    "form": {
      "clientName": "Client name",
      "clientEmail": "Client email",
      "issueDate": "Issue date",
      "dueDate": "Due date",
      "currency": "Currency",
      "notes": "Notes",
      "items": "Items",
      "item": {
        "description": "Description",
        "quantity": "Qty",
        "unitPrice": "Unit price",
        "taxRate": "Tax %",
        "discountRate": "Discount %",
        "total": "Line total"
      },
      "total": "Total"
    },
    "actions": {
      "addItem": "Add item",
      "removeItem": "Remove",
      "save": "Save"
    }
  }
}

```tsx
{
  "invoice": {
    "form": {
      "clientName": "Nom du client",
      "clientEmail": "Email du client",
      "issueDate": "Date d'émission",
      "dueDate": "Date d'échéance",
      "currency": "Devise",
      "notes": "Notes",
      "items": "Articles",
      "item": {
        "description": "Description",
        "quantity": "Qté",
        "unitPrice": "Prix unitaire",
        "taxRate": "TVA %",
        "discountRate": "Remise %",
        "total": "Total ligne"
      },
      "total": "Total"
    },
    "actions": {
      "addItem": "Ajouter un article",
      "removeItem": "Supprimer",
      "save": "Enregistrer"
    }
  }
}
```

Now wire the Invoice Editor to the store, create on /invoice/new, update on /invoice/:id.

Only one file changes. The editor now loads an existing invoice (when :id is present), patches the form, and saves either a new draft or an update to the store.

src/app/features/invoice-edit/invoice-edit.component.ts

...

import { lineTotal, invoiceTotal } from '../../core/utils/money';
import { InvoiceStore } from '../../core/stores/invoice.store';
import type { Invoice } from '../../core/models/invoice.model';

....

@Component({
  selector: 'app-invoice-edit',
  standalone: true,
  imports: [CommonModule, RouterModule, TranslateModule, ReactiveFormsModule],
  templateUrl: './invoice-edit.html',
  styleUrl: './invoice-edit.scss',
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class InvoiceEditComponent {
  ...
  private route = inject(ActivatedRoute);
  private store = inject(InvoiceStore);

  // when editing, keep refs to id + current invoice
  private editingId: string | null = null;
  private current: Invoice | null = null;

  ...

  constructor() {
    // detect /invoice/new vs /invoice/:id and hydrate if editing
    this.route.paramMap.subscribe(p => {
      const id = p.get('id');
      this.editingId = id;
      if (id) {
        const inv = this.store.byId(id)();
        this.current = inv ?? null;
        if (inv) this.setFormFromInvoice(inv);
      } else {
        this.current = null; // creating new
      }
    });
  }

...

  // ---------- hydrate form for edit ----------
  private setFormFromInvoice(inv: Invoice): void {
    this.form.patchValue({
      clientName: inv.clientName,
      clientEmail: inv.clientEmail ?? null,
      issueDate: inv.issueDate,
      dueDate: inv.dueDate ?? null,
      currency: inv.currency,
      notes: inv.notes ?? null,
    });

    this.items.clear();
    inv.items.forEach(it => {
      const g = this.createItemGroup();
      g.patchValue({
        description: it.description,
        quantity: it.quantity,
        unitPrice: it.unitPrice,
        taxRate: it.taxRate ?? 0,
        discountRate: it.discountRate ?? 0,
      });
      this.items.push(g);
    });
  }

  // replace the previous save() placeholder with create/update via store
  save(): void {
    if (this.form.invalid) {
      this.form.markAllAsTouched();
      return;
    }

    const v = this.form.getRawValue();

    // rebuild items; preserve existing IDs when editing
    const items = v.items.map((row, idx) => ({
      id: this.current?.items[idx]?.id ?? this.store.newLineItem().id,
      description: row.description,
      quantity: row.quantity,
      unitPrice: row.unitPrice,
      taxRate: row.taxRate,
      discountRate: row.discountRate,
    }));

    if (this.editingId) {
      this.store.update(this.editingId, {
        clientName: v.clientName,
        clientEmail: v.clientEmail ?? undefined,
        issueDate: v.issueDate,
        dueDate: v.dueDate ?? undefined,
        currency: v.currency,
        notes: v.notes ?? undefined,
        items,
      });
    } else {
      this.store.createDraft({
        clientName: v.clientName,
        clientEmail: v.clientEmail ?? undefined,
        issueDate: v.issueDate,
        dueDate: v.dueDate ?? undefined,
        currency: v.currency,
        notes: v.notes ?? undefined,
        items,
        status: 'draft',
      });
    }
  }
}

That’s all you need to switch between create (/invoice/new) and edit (/invoice/:id) with the store, without dumping the whole file.

Let’s make rows editable and add inline actions.

1. Make invoice number a link 🔗

src/app/features/dashboard/dashboard.component.html

- <div class="font-semibold">{{ inv.number }}</div>
+ <a [routerLink]="['/invoice', inv.id]" class="font-semibold hover:underline">
+   {{ inv.number }}
+ </a>

2. Add row actions (Edit / Mark Sent / Mark Paid / Delete) 🔗

Go tosrc/app/features/dashboard/dashboard.component.html inside the same @for row and append this to the right-side info block (after total):

<!-- actions -->
<div class="flex items-center gap-2 ml-4">
  <a [routerLink]="['/invoice', inv.id]" class="btn-secondary">
    {{ 'invoice.actions.edit' | translate }}
  </a>

  @if (inv.status === 'draft') {
    <button type="button" class="btn-secondary" (click)="markAsSent(inv.id)">
      {{ 'invoice.actions.markSent' | translate }}
    </button>
  } @else if (inv.status === 'sent') {
    <button type="button" class="btn-secondary" (click)="markAsPaid(inv.id)">
      {{ 'invoice.actions.markPaid' | translate }}
    </button>
  }

  <button type="button" class="btn-secondary" (click)="remove(inv.id)">
    {{ 'invoice.actions.delete' | translate }}
  </button>
</div>

3. Add the handlers 🔗

Add these methods inside the DashboardComponent class src/app/features/dashboard/dashboard.ts.

markAsSent(id: string): void {
  this.store.setStatus(id, 'sent');
}

markAsPaid(id: string): void {
  this.store.setStatus(id, 'paid');
}

remove(id: string): void {
  if (confirm('Delete this invoice?')) {
    this.store.remove(id);
  }
}

4. Update strings 🔗

public/assets/i18n/en.json

{
  "invoice": {
    "actions": {
      "edit": "Edit",
      "markSent": "Mark as sent",
      "markPaid": "Mark as paid",
      "delete": "Delete"
    }
  }
}

public/assets/i18n/fr.json

{
  "invoice": {
    "actions": {
      "edit": "Modifier",
      "markSent": "Marquer comme envoyée",
      "markPaid": "Marquer comme payée",
      "delete": "Supprimer"
    }
  }
}

Now the invoice ID are clickable, rows have clear actions, and status transitions happen with one click, all persisted via your repository-backed store. To finish off this step, run a quick check with npm start to test that the edit, language switch, invoice status and delete operations work well.

Let’s enable PWA support cleanly in the next step.

5️⃣ Step 5: Feature core-PWA scaffold 🔗

We’ll enable installable, offline-first behavior and lay the groundwork for small UX helpers (online/offline signal and “Install app” prompt). The idea is to keep it minimal and production-ready.

1. Install PWA support 🔗

Run the Angular schematic via your project script:

npm run ng -- add @angular/pwa

This adds @angular/service-worker, creates ngsw-config.json, drops public/manifest.webmanifest and icons, and wires the worker.

2. Test in production mode 🔗

Build and serve the production output so the Service Worker can activate:

npm run build -- --configuration=production
npx http-server ./dist/invoice-pwa/browser -p 4200 -c-1

Open http://localhost:4200. In DevTools > Application > Service Workers, confirm ngsw-worker.js is activated. Toggle Offline in the Network tab and reload; the app should still load.

3. Create a tiny PWA service 🔗

This service exposes three simple signals you can bind to the UI: canInstall (show an “Install app” button), isOnline(online/offline badge), and isStandalone (running as an installed PWA). It also provides an install() method that triggers the browser’s install prompt.

File: src/app/core/pwa/pwa.service.ts

import { Injectable, signal, computed } from '@angular/core';

type BeforeInstallPromptEvent = Event & {
  prompt: () => Promise<void>;
  userChoice: Promise<{ outcome: 'accepted' | 'dismissed'; platform: string }>;
};

@Injectable({ providedIn: 'root' })
export class PwaService {
  private deferred: BeforeInstallPromptEvent | null = null;

  // shows the “Install” button when true
  readonly canInstall = signal(false);

  // are we already installed?
  readonly isStandalone = computed(() => {
    // iOS Safari
    const iosStandalone = (navigator as any).standalone === true;
    // All modern browsers
    const displayModeStandalone = window.matchMedia?.('(display-mode: standalone)').matches;
    return iosStandalone || displayModeStandalone;
  });

  constructor() {
    // Fired when the browser thinks the app is installable
    window.addEventListener('beforeinstallprompt', (e: Event) => {
      e.preventDefault(); // don't show the mini-infobar
      this.deferred = e as BeforeInstallPromptEvent;
      this.canInstall.set(!this.isStandalone());
    });

    // Fired after a successful install
    window.addEventListener('appinstalled', () => {
      this.deferred = null;
      this.canInstall.set(false);
    });
  }

  async promptInstall(): Promise<void> {
    if (!this.deferred) return;
    this.canInstall.set(false);
    await this.deferred.prompt();
    try {
      await this.deferred.userChoice; // optional: inspect outcome
    } finally {
      this.deferred = null;
    }
  }
}

4. Update the component class 🔗

File: src/app/app.ts

...

import { PwaService } from './core/pwa/pwa.service';

...

export class App {
  private readonly lang = inject(LanguageService);
  readonly pwa = inject(PwaService);

  setLang(l: 'en' | 'fr') {
    this.lang.use(l);
  }

  install() {
    this.pwa.promptInstall();
  }
}

5. Add the button to the template 🔗

Add the install button next to EN/FR in src/app/app.html.

<header class="flex items-center gap-3 p-4 border-b">
  <h1 class="text-xl font-semibold">{{ 'app.title' | translate }}</h1>

  <div class="ml-auto flex items-center gap-2">
    <!-- Install button appears only when available and not already installed -->
    @if (pwa.canInstall() && !pwa.isStandalone()) {
      <button type="button" class="btn" (click)="install()">
        {{ 'app.install' | translate }}
      </button>
    }
    ...
    
  </div>
</header>

Add translation key on public/assets/i18n/en.json:

{
  "app": {
    "install": "Install app"
  }
}

public/assets/i18n/fr.json

{
  "app": {
    "install": "Installer l’application"
  }
}

Now test the button. Make sure you’re on the production build served over HTTP(s).

npm run build -- --configuration=production
npx http-server ./dist/invoice-pwa/browser -p 4200 -c-1

1. Open http://localhost:4200.
2. You should see the Install app button when:

• Not already installed.
• Browser deems it installable (has manifest, SW active, visited at least once).

3. Click Install app > the native install dialog appears.

4. After installing, the button disappears.

6. Add connectivity toasts (offline & back online) 🔗

Here you’ll display a small banner when the app goes offline and a quick green flash when it comes back online. This improves UX by giving clear, instant feedback about network status.

It only takes four lightweight parts: a network status service, a toast banner, a quick wire-up in the app shell, and two i18n entries. Follow these steps:

• Create the network service

Tracks online/offline state using signals, and flashes a short Back online message after reconnection, too.

File: src/app/core/network/network.service.ts

import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class NetworkService {
  // true = online, false = offline
  readonly online = signal<boolean>(navigator.onLine);

  // flash "Back online" for a few seconds after reconnection
  readonly flashOnline = signal<boolean>(false);

  private timer: any = null;

  constructor() {
    window.addEventListener('online', () => {
      this.online.set(true);
      this.flashOnline.set(true);
      clearTimeout(this.timer);
      this.timer = setTimeout(() => this.flashOnline.set(false), 3000);
    });

    window.addEventListener('offline', () => {
      this.online.set(false);
      this.flashOnline.set(false);
      clearTimeout(this.timer);
    });
  }
}

• Expose the service in the app shell

Expose the network status in the app shell so the template (and the offline toast) can read it.

File: src/app/app.ts

...
import { PwaService } from './core/pwa/pwa.service';
import { NetworkService } from './core/network/network.service';

...
export class App {
  ...
  readonly net = inject(NetworkService);

 ...
}

• Add toast banners to the template

Place the toaster exactly at the end of app.html after </main>:

<!-- Offline / Online toasts -->
@if (!net.online()) {
  <div class="fixed bottom-4 left-1/2 -translate-x-1/2 bg-red-600 text-white px-4 py-2 rounded-lg shadow
              flex items-center gap-2 z-50"
       role="status" aria-live="polite">
    {{ 'app.offline' | translate }}
  </div>
}
@if (net.flashOnline()) {
  <div class="fixed bottom-4 left-1/2 -translate-x-1/2 bg-green-600 text-white px-4 py-2 rounded-lg shadow
              flex items-center gap-2 z-50"
       role="status" aria-live="polite">
    {{ 'app.backOnline' | translate }}
  </div>
}

Like always, add the translations:

public/assets/i18n/en.json

{
  "app": {
    "offline": "You’re offline. Some features may be unavailable.",
    "backOnline": "Back online"
  }
}

public/assets/i18n/fr.json

{
  "app": {
    "offline": "Vous êtes hors ligne. Certaines fonctionnalités peuvent être indisponibles.",
    "backOnline": "De retour en ligne"
  }
}

Now let's test:

• In DevTools > Network > set throttling to Offline > the red toast appears.
• If you switch back to Online > a green “Back online” toast flashes for ~3s.

Next, we’ll extend this feature core by adding new version available, search, filter, sort, and CSV export/import logic to the dashboard.

7. New version available toast 🔗

Here you will show a small toast when a fresh build is ready. One tap, it reloads into the new version. Note that this runs only on production builds.

• Create the update service

src/app/core/pwa/update.service.ts

import { Injectable, signal } from '@angular/core';
import { SwUpdate } from '@angular/service-worker';

@Injectable({ providedIn: 'root' })
export class UpdateService {
  /** Show the “Update available” toast */
  readonly updateAvailable = signal<boolean>(false);

  /** Disable the button and show progress text while activating */
  readonly installing = signal<boolean>(false);

  constructor(private sw: SwUpdate) {
    // SW is only enabled in production; guard in dev
    if (!this.sw.isEnabled) return;

    // Listen for version events; when a new version is ready, show the toast
    this.sw.versionUpdates.subscribe(evt => {
      if ((evt as any).type === 'VERSION_READY') {
        this.updateAvailable.set(true);
      }
      // Optional: handle failures
      if ((evt as any).type === 'VERSION_INSTALLATION_FAILED') {
        // Could log or surface a subtle warning if you want
      }
    });

    // Also check on app focus (useful if the tab was idle)
    window.addEventListener('focus', () => {
      this.checkForUpdates();
    });

    // Initial check shortly after boot
    setTimeout(() => this.checkForUpdates(), 5_000);

    // Periodic check every 6 hours
    setInterval(() => this.checkForUpdates(), 6 * 60 * 60 * 1000);
  }

  async checkForUpdates(): Promise<void> {
    if (!this.sw.isEnabled) return;
    try {
      await this.sw.checkForUpdate();
    } catch {
      // ignore network errors
    }
  }

  /** Activate the new version and reload the app */
  async activateAndReload(): Promise<void> {
    if (!this.sw.isEnabled) return;
    this.installing.set(true);
    try {
      await this.sw.activateUpdate();
    } finally {
      // Reload to load the fresh version (even if activateUpdate failed, reload is harmless)
      document.location.reload();
    }
  }
}

• Expose it in the root component

Inject the service and add a tiny handler for the button.

File: src/app/app.ts

...

import { UpdateService } from './core/pwa/update.service';

...

export class App {
  
  readonly upd = inject(UpdateService);

 
  reloadApp() { this.upd.activateAndReload(); }
}

• Add the update toast

Place the code below at the very end of the template, after your offline/online toasts.

File: src/app/app.html

<!-- Update available toast -->
@if (upd.updateAvailable()) {
  <div class="fixed bottom-4 left-1/2 -translate-x-1/2 bg-blue-600 text-white px-4 py-2 rounded-lg shadow
              flex items-center gap-3 z-50"
       role="status" aria-live="polite">
    {{ 'app.updateAvailable' | translate }}
    <button class="btn ml-2"
            [disabled]="upd.installing()"
            (click)="reloadApp()">
      @if (upd.installing()) {
        {{ 'app.updating' | translate }}
      } @else {
        {{ 'app.reload' | translate }}
      }
    </button>
  </div>
}

And don’t forget to update your translations!

File: public/assets/i18n/en.json

{
  "app": {
    "updateAvailable": "A new version is available.",
    "reload": "Reload",
    "updating": "Updating…"
  }
}

File: public/assets/i18n/fr.json

{
  "app": {
    "updateAvailable": "Une nouvelle version est disponible.",
    "reload": "Recharger",
    "updating": "Mise à jour…"
  }
}

Build, serve, and then watch the toast appear.

# Build v1
npm run build -- --configuration=production
npx http-server ./dist/invoice-pwa/browser -p 4200 -c-1

When the app checks for updates on focus after approximately 5s periodically, the blue toast will show. Click Reload to activate and jump to the new version.

Up to now, the app allows you to create, edit, and manage invoices, but there’s no dedicated way to view a finalized invoice in a clean, print-friendly layout. Users need a professional, read-only page they can show clients, download as PDF, or print directly from the browser.

So now, you will create the invoice view to display the selected invoice with proper formatting, localized currency and date styles, as well as optional notes.

🧾 Generate the view invoice component 🔗

In this section you will create the invoice view to see the detail of an individual invoice when a user clicks on a specific view.

npm run ng -- g c features/invoice-view/invoice-view --standalone --flat --skip-tests

Add its route: src/app/app.routes.ts.

{
  path: 'invoice/:id/view',
  loadComponent: () =>
    import('./features/invoice-view/invoice-view').then(m => m.InvoiceViewComponent),
},

Create the View component (read-only, print-ready):

src/app/features/invoice-view/invoice-view.component.ts

import { Component, ChangeDetectionStrategy, inject, OnInit, computed } from '@angular/core';
import { CommonModule } from '@angular/common';
import { Router, ActivatedRoute, RouterModule } from '@angular/router';
import { TranslateModule } from '@ngx-translate/core';

import { InvoiceStore } from '../../core/stores/invoice.store';
import type { Invoice, LineItem } from '../../core/models/invoice.model';
import { LocaleFormatService } from '../../core/locale-format.service';
import { lineTotal, invoiceTotal } from '../../core/utils/money';

@Component({
  selector: 'app-invoice-view',
  standalone: true,
  imports: [CommonModule, RouterModule, TranslateModule],
  templateUrl: './invoice-view.component.html',
  styleUrl: './invoice-view.component.scss',
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class InvoiceViewComponent implements OnInit {
  private readonly route = inject(ActivatedRoute);
  private readonly router = inject(Router);
  private readonly store = inject(InvoiceStore);
  private readonly fmt = inject(LocaleFormatService);

  // signal to the selected invoice (reactive)
  invoice = computed<Invoice | null>(() => {
    const id = this.route.snapshot.paramMap.get('id');
    return id ? this.store.byId(id)() : null;
  });

  ngOnInit(): void {
    if (!this.invoice()) this.router.navigateByUrl('/');
  }

  // formatting helpers
  date(d: string) { return this.fmt.dateISO(d); }
  money(amount: number, cur: string) { return this.fmt.currency(amount, cur); }
  lineTotal(li: LineItem) { return lineTotal(li); }
  grand(inv: Invoice) { return invoiceTotal(inv); }

  print(): void { window.print(); }
  back(): void { this.router.navigateByUrl('/'); }
}

Add this code in src/app/features/invoice-view/invoice-view.component.html.

<!-- Controls (hidden in print) -->
<div class="no-print max-w-4xl mx-auto p-4 flex items-center gap-2">
  <a routerLink="/" class="btn-secondary">{{ 'nav.back' | translate }}</a>
  <button class="btn" type="button" (click)="print()">
    {{ 'invoice.view.print' | translate }}
  </button>
</div>

<!-- Printable page -->
<section class="sheet max-w-4xl mx-auto bg-white text-gray-900 shadow p-8">
  @if (invoice(); as inv) {
    <header class="flex items-start justify-between mb-8">
      <div>
        <h1 class="text-2xl font-semibold">{{ 'invoice.view.title' | translate }} {{ inv.number }}</h1>
        <div class="text-sm text-gray-600">
          <div>{{ 'invoice.view.issueDate' | translate }}: {{ date(inv.issueDate) }}</div>
          @if (inv.dueDate) {
            <div>{{ 'invoice.view.dueDate' | translate }}: {{ date(inv.dueDate!) }}</div>
          }
          <div>{{ 'invoice.view.status' | translate }}: {{ ('status.' + inv.status) | translate }}</div>
        </div>
      </div>

      <!-- Minimal “Bill To” block -->
      <div class="text-right">
        <div class="uppercase text-xs text-gray-500">{{ 'invoice.view.billTo' | translate }}</div>
        <div class="font-medium">{{ inv.clientName || '—' }}</div>
        @if (inv.clientEmail) { <div class="text-sm text-gray-600">{{ inv.clientEmail }}</div> }
      </div>
    </header>

    <!-- Items table -->
    <table class="w-full border-collapse">
      <thead>
        <tr class="border-b border-gray-300 text-left">
          <th class="py-2 pr-2 w-7/12">{{ 'invoice.form.item.description' | translate }}</th>
          <th class="py-2 pr-2 w-1/12 text-right">{{ 'invoice.form.item.quantity' | translate }}</th>
          <th class="py-2 pr-2 w-2/12 text-right">{{ 'invoice.form.item.unitPrice' | translate }}</th>
          <th class="py-2 pr-2 w-1/12 text-right">{{ 'invoice.form.item.taxRate' | translate }}</th>
          <th class="py-2 pl-2 w-2/12 text-right">{{ 'invoice.form.item.total' | translate }}</th>
        </tr>
      </thead>
      <tbody>
        @for (it of inv.items; track it.id) {
          <tr class="border-b border-gray-100">
            <td class="py-2 pr-2 align-top">
              <div class="font-medium">{{ it.description || '—' }}</div>
              @if (it.discountRate && it.discountRate > 0) {
                <div class="text-xs text-gray-600">
                  {{ 'invoice.view.discount' | translate }}: {{ it.discountRate }}%
                </div>
              }
            </td>
            <td class="py-2 pr-2 text-right align-top">{{ it.quantity }}</td>
            <td class="py-2 pr-2 text-right align-top">{{ money(it.unitPrice, inv.currency) }}</td>
            <td class="py-2 pr-2 text-right align-top">{{ it.taxRate || 0 }}%</td>
            <td class="py-2 pl-2 text-right align-top">
              {{ money(lineTotal(it), inv.currency) }}
            </td>
          </tr>
        }
      </tbody>
    </table>

    <!-- Notes + totals -->
    <div class="flex flex-col md:flex-row gap-6 mt-6">
      <div class="md:w-1/2">
        @if (inv.notes) {
          <div class="uppercase text-xs text-gray-500 mb-1">{{ 'invoice.view.notes' | translate }}</div>
          <div class="whitespace-pre-line">{{ inv.notes }}</div>
        }
      </div>
      <div class="md:w-1/2">
        <div class="flex justify-between text-lg font-medium border-t pt-4">
          <span>{{ 'invoice.form.total' | translate }}</span>
          <span>{{ money(grand(inv), inv.currency) }}</span>
        </div>
      </div>
    </div>
  }
</section>

And add print style so the PDF looks good:

src/app/features/invoice-view/invoice-view.component.scss

/* Hide elements with .no-print when printing */
@media print {
  .no-print { display: none !important; }
  html, body { background: white !important; }
  .sheet {
    box-shadow: none !important;
    margin: 0 !important;
    width: auto !important;
    padding: 0.5in !important; /* print margins */
  }
}

/* On screen */
.sheet { border-radius: 0.75rem; }

Now, update your translations:

public/assets/i18n/en.json

{
  "invoice": {
    "view": {
      "title": "Invoice",
      "issueDate": "Issue date",
      "dueDate": "Due date",
      "status": "Status",
      "billTo": "Bill to",
      "notes": "Notes",
      "print": "Print / Save as PDF",
      "discount": "Discount"
    }
  }
}

public/assets/i18n/fr.json

{
  "invoice": {
    "view": {
      "title": "Facture",
      "issueDate": "Date d'émission",
      "dueDate": "Date d'échéance",
      "status": "Statut",
      "billTo": "Destinataire",
      "notes": "Notes",
      "print": "Imprimer / Enregistrer en PDF",
      "discount": "Remise"
    }
  }
}

Then add the“View” action on each row in src/app/features/dashboard/dashboard.ts.

view(inv: Invoice) {
  this.router.navigate(['/invoice', inv.id, 'view']);
}

Drop the button in your actions block in src/app/features/dashboard/dashboard.html.

<button type="button" class="btn-secondary" (click)="view(inv)">
  {{ 'invoice.actions.view' | translate }}
</button>

And translations in public/assets/i18n/en.json...

{ "invoice": { "actions": { "view": "View" } } }

...and public/assets/i18n/fr.json.

{ "invoice": { "actions": { "view": "Voir" } } }

Finally, run a quick test by starting the app with npm start, then open /invoice/:id/view to verify that the page displays and prints cleanly. From the dashboard, click View. It should open the same screen where the Print / Save as PDF action is working properly.

Our last step today will be adding Search / Filter / Sort to the dashboard.

🔎 Search, filter and sort feature 🔗

1. Dashboard component 🔗

In your src/app/features/dashboard/dashboard.component.ts:

import { Component, ChangeDetectionStrategy, inject, computed, signal } from '@angular/core';
import { RouterModule, Router } from '@angular/router';

Inject Router:

private readonly router = inject(Router);

Add UI state signals for search text, status, sort:

type StatusFilter = 'all' | 'draft' | 'sent' | 'paid';
type SortKey = 'dateDesc' | 'dateAsc' | 'amountDesc' | 'amountAsc';

readonly query  = signal<string>('');
readonly status = signal<StatusFilter>('all');
readonly sort   = signal<SortKey>('dateDesc');

Derived view:

readonly view = computed(() => {
  const q = this.query().trim().toLowerCase();
  const st = this.status();
  const sortKey = this.sort();

  let rows = this.invoices();

  if (st !== 'all') rows = rows.filter(r => r.status === st);

  if (q) {
    rows = rows.filter(r =>
      r.number.toLowerCase().includes(q) ||
      r.clientName.toLowerCase().includes(q) ||
      (r.clientEmail?.toLowerCase().includes(q) ?? false) ||
      (r.notes?.toLowerCase().includes(q) ?? false)
    );
  }

  const byAmount = (r: Invoice) => invoiceTotal(r);
  const byDate   = (r: Invoice) => r.issueDate; // ISO sorts lexicographically

  rows = [...rows];
  switch (sortKey) {
    case 'amountDesc': rows.sort((a,b) => byAmount(b) - byAmount(a)); break;
    case 'amountAsc':  rows.sort((a,b) => byAmount(a) - byAmount(b)); break;
    case 'dateAsc':    rows.sort((a,b) => byDate(a).localeCompare(byDate(b))); break;
    case 'dateDesc':
    default:           rows.sort((a,b) => byDate(b).localeCompare(byDate(a))); break;
  }

  return rows;
});

Add row action handlers:

viewInvoice(inv: Invoice) { this.router.navigate(['/invoice', inv.id, 'view']); }
edit(inv: Invoice)        { this.router.navigate(['/invoice', inv.id]); }
markSent(inv: Invoice)    { if (inv.status !== 'sent') this.store.setStatus(inv.id, 'sent'); }
markPaid(inv: Invoice)    { if (inv.status !== 'paid') this.store.setStatus(inv.id, 'paid'); }
remove(inv: Invoice)      { if (confirm(`Delete ${inv.number}? This cannot be undone.`)) this.store.remove(inv.id); }

// top-bar inputs → signals
onSearch(v: string)       { this.query.set(v); }
onStatusChange(v: string) { this.status.set((v as StatusFilter) || 'all'); }
onSortChange(v: string)   { this.sort.set((v as SortKey) || 'dateDesc'); }

Then update the dashboard template on src/app/features/dashboard/dashboard.html.

<header class="flex flex-col gap-3 md:flex-row md:items-center">
  <h2 class="text-2xl font-semibold">{{ 'dashboard.title' | translate }}</h2>

  <div class="md:ml-auto grid grid-cols-1 md:grid-cols-3 gap-2 items-center">
    <!-- Search -->
    <input
      #q type="search"
      class="rounded-lg border p-2"
      [value]="query()"
      (input)="onSearch(q.value)"
      [placeholder]="'dashboard.filters.searchPlaceholder' | translate" />

    <!-- Status -->
    <select
      #statusSel class="rounded-lg border p-2"
      [value]="status()"
      (change)="onStatusChange(statusSel.value)">
      <option value="all">{{ 'status.all' | translate }}</option>
      <option value="draft">{{ 'status.draft' | translate }}</option>
      <option value="sent">{{ 'status.sent' | translate }}</option>
      <option value="paid">{{ 'status.paid' | translate }}</option>
    </select>

    <!-- Sort -->
    <select
      #sortSel class="rounded-lg border p-2"
      [value]="sort()"
      (change)="onSortChange(sortSel.value)">
      <option value="dateDesc">{{ 'dashboard.filters.sort.dateDesc' | translate }}</option>
      <option value="dateAsc">{{ 'dashboard.filters.sort.dateAsc' | translate }}</option>
      <option value="amountDesc">{{ 'dashboard.filters.sort.amountDesc' | translate }}</option>
      <option value="amountAsc">{{ 'dashboard.filters.sort.amountAsc' | translate }}</option>
    </select>
  </div>

  <div class="flex items-center gap-2">
    <a routerLink="/invoice/new" class="btn">{{ 'invoice.actions.create' | translate }}</a>
    <button class="btn-secondary" type="button" (click)="createSample()">+ Sample</button>
  </div>
</header>

Insert the result count + empty states above your list:

@if (view().length > 0) {
  <div class="text-sm text-gray-500">
    {{ 'dashboard.resultsPlural' | translate : { count: view().length } }}
    @if (query().length) { — {{ 'dashboard.searchTerm' | translate }}: “{{ query() }}” }
  </div>
}

@if (invoices().length === 0) {
  <div class="rounded-xl border border-dashed p-8 text-gray-600">
    {{ 'dashboard.empty' | translate }}
  </div>
} @else if (view().length === 0) {
  <div class="rounded-xl border border-dashed p-8 text-gray-700 space-y-1">
    <div class="font-semibold">{{ 'dashboard.noResultsTitle' | translate }}</div>
    <div>{{ 'dashboard.noResultsBody' | translate }}</div>
    @if (query().length) {
      <div class="text-sm text-gray-500">
        {{ 'dashboard.searchTerm' | translate }}: “{{ query() }}”
      </div>
    }
  </div>
}

Use the filtered list (view()) and updated actions inside your existing list:

<ul class="space-y-3">
  @for (inv of view(); track inv.id) {
    <!-- … existing row header with number/client/date/total … -->

    <div class="mt-3 flex items-center gap-2">
      <button type="button" class="btn-secondary" (click)="viewInvoice(inv)">
        {{ 'invoice.actions.view' | translate }}
      </button>
      <button type="button" class="btn-secondary" (click)="edit(inv)">
        {{ 'invoice.actions.edit' | translate }}
      </button>
      @if (inv.status !== 'sent') {
        <button type="button" class="btn-secondary" (click)="markSent(inv)">
          {{ 'invoice.actions.markSent' | translate }}
        </button>
      }
      @if (inv.status !== 'paid') {
        <button type="button" class="btn-secondary" (click)="markPaid(inv)">
          {{ 'invoice.actions.markPaid' | translate }}
        </button>
      }
      <buttontype="button"
        class="inline-flex items-center gap-2 rounded-lg border border-red-300 bg-white px-3 py-1.5 text-red-700 shadow-sm hover:bg-red-50 focus:outline-none focus:ring-2 focus:ring-red-400/40"
        (click)="remove(inv)">
        {{ 'invoice.actions.delete' | translate }}
      </button>
    </div>
  }
</ul>

Then update your translations:

public/assets/i18n/en.json

{
  "status": {
    "all": "All",
    "draft": "Draft",
    "sent": "Sent",
    "paid": "Paid"
  },
  "dashboard": {
    "resultsPlural": "{{count}} result(s)",
    "noResultsTitle": "Invoice not found",
    "noResultsBody": "No invoices match your search or filters.",
    "searchTerm": "Search",
    "filters": {
      "searchPlaceholder": "Search by number, client, email, notes…",
      "sort": {
        "dateDesc": "Newest first",
        "dateAsc": "Oldest first",
        "amountDesc": "Amount: high → low",
        "amountAsc": "Amount: low → high"
      }
    }
  }
}

public/assets/i18n/fr.json

{
  "status": {
    "all": "Tous",
    "draft": "Brouillon",
    "sent": "Envoyée",
    "paid": "Payée"
  },
  "dashboard": {
    "resultsPlural": "{{count}} résultat(s)",
    "noResultsTitle": "Facture introuvable",
    "noResultsBody": "Aucune facture ne correspond à votre recherche ou à vos filtres.",
    "searchTerm": "Recherche",
    "filters": {
      "searchPlaceholder": "Rechercher par numéro, client, email, notes…",
      "sort": {
        "dateDesc": "Plus récentes d'abord",
        "dateAsc": "Plus anciennes d'abord",
        "amountDesc": "Montant : élevé → faible",
        "amountAsc": "Montant : faible → élevé"
      }
    }
  }
}

Try typing in the search box and observe the list updates instantly! Play with filters or sorting to see invoices reshuffle, then clear everything to get back to your cozy “Newest first” view.

2. Add an export method 🔗

Add the code blow inside the InvoiceStore class in src/app/core/stores/invoice.store.ts.

/** ---- backup/export ---- */
exportJSON(pretty = true): string {
  const payload = { version: 2, data: this._invoices() };
  return JSON.stringify(payload, null, pretty ? 2 : 0);
}

Add this helper in  src/app/core/utils/files.ts:

export function downloadText(
  filename: string,
  text: string,
  mime = 'application/json;charset=utf-8'
) {
  const blob = new Blob([text], { type: mime });
  const url = URL.createObjectURL(blob);
  const a = document.createElement('a');
  a.href = url;
  a.download = filename;
  document.body.appendChild(a);
  a.click();
  document.body.removeChild(a);
  URL.revokeObjectURL(url);
}

Next, add the import at the top and then the method inside the class in src/app/features/dashboard/dashboard.component.ts:

// add import
import { downloadText } from '../../core/utils/files';

// inside DashboardComponent
exportBackup() {
  const json = this.store.exportJSON(true);
  const stamp = new Date().toISOString().slice(0, 19).replace(/[:T]/g, '-'); // YYYY-MM-DD-HH-MM-SS
  downloadText(`invoices-backup-${stamp}.json`, json);
}

Add now the export button in src/app/features/dashboard/dashboard.component.html:

<button class="btn-secondary" type="button" (click)="exportBackup()">
  {{ 'dashboard.actions.export' | translate }}
</button>

public/assets/i18n/en.json

{
  "dashboard": {
    "actions": {
      "export": "Exporter en JSON"
    }
  }
}

public/assets/i18n/fr.json

{
  "dashboard": {
    "actions": {
      "export": "Export JSON"
    }
  }
}

3. Add Import JSON 🔗

Here, add a simple way for users to restore saved invoices by importing their JSON backups. They can either replace all data or merge it with existing invoices

Add these inside the InvoiceStore class in src/app/core/stores/invoice.store.ts:

/** ---- restore/import helpers ---- */
setAll(list: Invoice[]): void {
  this._invoices.set([...list]);
}

mergeAll(list: Invoice[]): void {
  const map = new Map<string, Invoice>();
  for (const inv of this._invoices()) map.set(inv.id, inv);
  for (const inv of list) map.set(inv.id, inv); // imported wins on id collision
  this._invoices.set([...map.values()]);
}

The setAll replaces everything in one go; mergeAll keeps existing invoices and lets imported ones win when IDs collide.

Add these imports at the top alongside your existing ones in src/app/features/dashboard/dashboard.component.ts:

import { ViewChild, ElementRef } from '@angular/core';
import { sanitizeInvoice } from '../../core/persistence/invoice.serialization';

Add a reference to the hidden input inside the class:

@ViewChild('importInput') importInput?: ElementRef<HTMLInputElement>;

Include these two small methods with your other actions:

triggerImport(el: HTMLInputElement) {
  el.value = ''; // allow re-selecting the same file
  el.click();
}

async handleImport(files: FileList | null) {
  if (!files || files.length === 0) return;
  const file = files[0];

  try {
    const text = await file.text();
    const parsed: unknown = JSON.parse(text);

    // Accept v1 (array) or v2 ({version, data: []})
    const rawList: unknown[] =
      Array.isArray(parsed)
        ? parsed
        : (parsed && typeof parsed === 'object' && Array.isArray((parsed as any)['data']))
          ? (parsed as any)['data']
          : [];

    const imported = rawList
      .map(sanitizeInvoice)
      .filter((x): x is NonNullable<ReturnType<typeof sanitizeInvoice>> => !!x);

    if (imported.length === 0) {
      alert('Import failed: no valid invoices found in file.');
      return;
    }

    const replace = confirm(
      `Found ${imported.length} invoices.\\n\\nOK = Replace ALL existing invoices\\nCancel = Merge (imported overwrite by id)`
    );

    if (replace) {
      this.store.setAll(imported);
      alert('Restore complete: replaced all invoices.');
    } else {
      this.store.mergeAll(imported);
      alert('Restore complete: merged invoices.');
    }
  } catch (e) {
    console.error(e);
    alert('Import failed: invalid JSON or unreadable file.');
  } finally {
    if (this.importInput?.nativeElement) this.importInput.nativeElement.value = '';
  }
}

Let hide file input for import button in the header actions (next to Create / + Sample / Export) of the src/app/features/dashboard/dashboard.component.html:

<!-- Hidden file input for import -->
<input
  #importInput
  type="file"
  accept="application/json"
  class="hidden"
  (change)="handleImport(importInput.files)" />

<button class="btn-secondary" type="button" (click)="triggerImport(importInput)">
  {{ 'dashboard.actions.import' | translate }}
</button>

Add the import text on public/assets/i18n/en.json:

{
  "dashboard": {
    "actions": {
      "import": "Import JSON"
    }
  }
}

And on public/assets/i18n/fr.json:

{
  "dashboard": {
    "actions": {
      "import": "Importer JSON"
    }
  }
}

Open the app and run a quick test to make sure the import works.

Let’s round out backups with a clean CSV export. No need to use libraries: just two neat files you can open in Excel/Sheets. One for invoices, one for line items.

4. Export as CSV 🔗

Let’s make it easy for users to work with their data outside the app.

With a single click, they’ll be able to export all invoices and line items as CSV files, perfect for quick reviews, reports, or even Excel and Google Sheets.

Create a CSV helper first:

src/app/core/utils/csv.ts

function csvEscape(value: unknown): string {
  const s = value === undefined || value === null ? '' : String(value);
  if (/[",\\r\\n]/.test(s)) return `"${s.replace(/"/g, '""')}"`;
  return s;
}

/** Build a CSV string from an array of plain objects using the provided column order. */
export function toCsv(columns: string[], rows: Array<Record<string, unknown>>): string {
  const header = columns.join(',');
  const data = rows.map(r => columns.map(c => csvEscape(r[c])).join(','));
  return [header, ...data].join('\\r\\n');
}

This tiny helper takes any list of objects and turns it into a clean, spreadsheet-ready CSV file. It automatically escapes commas and quotes so everything opens correctly in Excel or Sheets.

Add these imports at the top in src/app/features/dashboard/dashboard.component.ts:

import { toCsv } from '../../core/utils/csv';
import { lineTotal, invoiceTotal } from '../../core/utils/money';

Then, inside your DashboardComponent, add this method:

// ---------- export CSV ----------
exportCsv() {
  const list = this.invoices();

  // Invoices CSV (one row per invoice; totals are raw numbers in base currency)
  const invCols = [
    'id','number','clientName','clientEmail','issueDate','dueDate',
    'currency','status','itemsCount','total','createdAt','updatedAt'
  ];
  const invRows = list.map(inv => ({
    id: inv.id,
    number: inv.number,
    clientName: inv.clientName,
    clientEmail: inv.clientEmail ?? '',
    issueDate: inv.issueDate,
    dueDate: inv.dueDate ?? '',
    currency: inv.currency,
    status: inv.status,
    itemsCount: inv.items.length,
    total: invoiceTotal(inv),        // numeric, not localized
    createdAt: inv.createdAt,
    updatedAt: inv.updatedAt,
  }));
  const invoicesCsv = toCsv(invCols, invRows);

  // Items CSV (one row per line item; includes invoiceId)
  const itemCols = [
    'invoiceId','itemId','description','quantity','unitPrice','taxRate','discountRate','lineTotal'
  ];
  const itemRows = list.flatMap(inv =>
    inv.items.map(it => ({
      invoiceId: inv.id,
      itemId: it.id,
      description: it.description,
      quantity: it.quantity,
      unitPrice: it.unitPrice,
      taxRate: it.taxRate ?? 0,
      discountRate: it.discountRate ?? 0,
      lineTotal: lineTotal(it),      // numeric, not localized
    }))
  );
  const itemsCsv = toCsv(itemCols, itemRows);

  const stamp = new Date().toISOString().slice(0, 19).replace(/[:T]/g, '-');
  downloadText(`invoices-${stamp}.csv`, invoicesCsv, 'text/csv;charset=utf-8');
  downloadText(`invoice_items-${stamp}.csv`, itemsCsv, 'text/csv;charset=utf-8');
}

This exports two CSV files: one summarizing each invoice and another listing all individual line items. Keeping the numbers raw makes them easier to analyze or chart later in any spreadsheet.

Let add the UI button in src/app/features/dashboard/dashboard.component.html  in the header actions (next to Create / + Sample / Export JSON / Import JSON):

<button class="btn-secondary" type="button" (click)="exportCsv()">
  {{ 'dashboard.actions.exportCsv' | translate }}
</button>

Update your translations:

public/assets/i18n/en.json

{
  "dashboard": {
    "actions": {
      "exportCsv": "Export CSV"
    }
  }
}

public/assets/i18n/fr.json

{
  "dashboard": {
    "actions": {
      "exportCsv": "Exporter CSV"
    }
  }
}

Open the app, hit Export CSV, and voilà! Two neat files land on your computer (invoices-YYYY-MM-DD-HH-MM-SS.csvand invoice_items-YYYY-MM-DD-HH-MM-SS.csv). Drop them into Excel or Google Sheets and play around: sort, filter, or build quick reports in seconds.

➡️ What's next? 🔗

This wraps up the second part of your journey where we built the foundation of the app and set up translation services to make it bilingual and user-friendly. In the next part, we’ll take things further by integrating the Angular app with Localazy, unlocking the real advantages of localization: faster translations, easier updates, and a smoother multilingual experience for every user.

Over the past two years, all costs have increased while our pricing stayed the same. Now we need to make a modest adjustment to maintain the quality and reliability you expect from Localazy.

The average price increase across all plans is +5.4%.

🧐 What this means for you 🔗

• Annual plans: Your current pricing is locked in until your next renewal date.
• Monthly plans: The new pricing takes effect with your January 2026 billing cycle.
• Enterprise plans: Your pricing stays the same.

Localazy AI is coming to Professional plan 🔗

If you are on the Professional plan, you can look forward to getting access to the Localazy AI in your tier.

You get more credits too 🔗

Each subscription includes free credits that renew every month (or year, depending on your billing period). And we are raising these credit amounts for you too, it's only fair.

🧮 New pricing overview 🔗

All prices in USD, not including VAT.

🤩 Something to look forward to 🔗

Now for some good news. 😅 Our team continuously improves the platform based on your feedback. Here are some things that you can expect in the year 2026, in no particular order:

1. Glossary refresh for better management
2. New QA tools and QA agent
3. Localazy AI translation API
4. Organization-wide glossaries and style guides

🙋‍♀️ Questions? 🔗

If you have any questions about the pricing change, upcoming features, or your specific plan, reach out to me at petr@localazy.com.

Thanks for being part of the Localazy community. 💙

Not so fast!

User feedback is great, but waiting until enough people complain about localization issues isn’t a winning strategy. Do you really want to hear about problems days, weeks, or months after launch? Just think how many users will drop off before it comes to light.

The truth is, most people won’t bother to complain. They’ll just drop off without a word.

As Joe Speck, Global Web Platforms Manager at Wall Street English, puts it, “We can’t just rely on site visitors to flag problems. Consistency across 35 sites is already hard enough to manage. If a localization error slips through, we might not see it until much later.

Those first impressions last, so it’s unlikely you’ll get a second chance to impress. As research shows, 88% of users say they won’t return after a bad experience.

With that in mind, if you’re launching in new markets or updating your website or app, can you really afford to neglect localization testing?

👎 Localization errors are a churn trigger 🔗

We’re imperfect humans living in an imperfect world. Until that changes (which it won’t), most new UX releases will have at least a few localization issues that don’t get picked up during the development phase.

That’s why it pays to test baby, test! Don’t mistakenly think that fancy new automation tools will pick up all the bloopers.

As useful as AI is, it can’t catch all localization bugs. Robots don’t understand cultural nuances like we do. You need a real human translator to cast an eye over it if you want perfection. As well as missing cultural nuance, automation tools don’t pick up on other common localization problems, such as…

Clunky translations that sound unnatural 🔗

A funny, but slightly cringe, example is when KFC's slogan “Finger-lickin’ good” was translated in China as the darkly sinister: “Eat your fingers off.”  Coors messed up too, when their slogan “Turn it loose” was translated into Spanish as “Suffer from diarrhea.” Not a great advert for their beer! 😬

Badly-translated idioms 🔗

The English idiom “it’s raining cats and dogs” is meaningless if translated literally in China. They would probably wonder why cats and dogs are falling from the sky. In instances like these, idioms can lose meaning (or even change it) across locales.

Cultural slip-ups 🔗

This encompasses words, colors, symbols, or images that confuse or offend. Nike faced backlash in 2019 after the sole design on its Air Max 270 resembled the Arabic word for “Allah.” In Arab culture, showing or stepping on the sole is highly offensive, so this sparked outrage and led to a petition with over 48,000 signatures. The brand apologized and clarified it was unintentional, but the damage was done.

Formatting mix-ups 🔗

Dates, times, currencies, or numbers can also lead to UX confusion. For example, 05/09 is May 9 in the US, but 5th Sept in the UK.

Broken UIs 🔗

German, Finnish, or Russian words are often much longer than English ones, which means buttons or labels might overflow when translated. Languages like Chinese or Japanese are shorter and could leave odd gaps. Arabic and Hebrew read right to left, which can lead to UI misalignments.

Sloppy localization, including text that overflows, cut off buttons, or layouts that don't align, doesn’t inspire trust and loyalty. In fact, it does the opposite and ramps up customer churn. Recent research shows that 24% of users turn away from brands with poor localization practices.

It’s not worth the risk of waiting it out and relying on user feedback. Localization testing before launch is a much smarter strategy.

24% of users turn away from brands with poor localization practices. A broken or misaligned UI, unnatural translations or just bad formatting can ramp up customer churn — that's why testing ends up paying off

👁️ What is localization testing? 🔗

Localization testing catches all those pesky localization errors before you put them out into the world.

It’s a bit like using quality assurance (QA) processes to find and correct software bugs, but instead of hunting down coding errors that crash your product, you’re looking for translation errors, cultural issues, and UI blips that might annoy or confuse people.

Localization testing is often referred to as global UX testing, as it involves checking whether the overall experience feels right for users in each market.

🔎 Automated checks to catch the basics 🔗

Automated checks are like a spell-check for your localized product. They apply localization QA rules to scan for common mistakes. Tools like Localazy have this feature built-in, helping you catch glaring errors early on.

They flag things like common translation errors, placeholder mismatches, missing punctuation marks, awkward spacing, or formatting errors.

However, these checks are like an initial safety net and don’t catch everything. You need humans to go through everything with a fine-tooth comb if you want high-quality localization. 🪮

In-context & pseudo-testing for previews 🔗

Reading translations in a spreadsheet is a totally different experience from seeing them out there in the “wild” (that is, actually in your product).

Using an in-context preview tool lets you drop translations into the real layout, making it easy to spot broken buttons, odd spacing, gaps, or text that doesn’t quite fit. Integrations with popular tools like Figma make it even easier.

You can also use pseudo-localization, a clever trick that involves adding fake text or special characters to mimic real translations. This stretches out words, adds accents, and tests encoding so you can catch the ugly stuff early on, like cut-off labels or characters that refuse to render properly. For example, “Account Settings” could be written as something like [!!! Àççôûñţ Šéţţîñĝš !!!].

Human review for nuance 🔗

Automation can’t tell you when something simply sounds wrong. That’s where human reviewers come in. They make sure the tone feels natural and that any idioms make sense, a process known as linguistic testing. It focuses on grammar, tone, meaning, and flow so the product feels like it was built for the target market from day one. If there are cultural references, reviewers ensure they land the way they should and don’t cause confusion or offense.

Continuous Integration with development 🔗

A Continuous Integration (CI) approach offers the best results. It means localizing your product as it’s built and updated. You can use tools that take new strings straight from your code and feed them into the localization platform and back again.

A good CI workflow means translations get tested as part of your regular build, rather than being bolted on at the end. It leads to faster feedback and fewer last-minute surprises. It means you squash localization bugs early before they get a chance to annoy your audience.

⚙️ See some examples of CI technical workflows in localization here

Task automation to save time 🔗

As well as automated checks at the beginning, you can also automate some of the dull, repetitive stuff, such as syncing files, spotting duplicates, or running machine or AI-powered pre-translations. Using smart automations like these frees your team from some of their busywork to focus on the things where they can bring real value, like optimizing content and UX.

🐞 How to catch issues before users spot them 🔗

Doing localization testing and management manually is a bit of a nightmare. It swallows up hours of a developer’s schedule, which is time that would be better spent coding and adding new features. The added pressure on development teams means that localization errors often slip through the net.

Continuous localization helps to stop the last-minute rush to fix errors or waiting for users to complain. It builds translation and QA into the development pipeline so that every new feature launch and update gets localized and tested as part of the release cycle.

Doing localization testing and management manually is a bit of a nightmare. With a continuous localization approach, errors get fixed, features are developed and testing is carried out all in paralel

Platforms like Localazy make continuous localization testing and fixing much easier to manage. For example, Wall Street English used the Localazy’s Strapi integration to cut hours of manual work. “We translated and deployed our content to create three new sites at the click of a button,” says Speck.

You can set up Localazy so that it automatically translates new strings as soon as they appear in your project. It pulls from trusted MT engines (like DeepL, Amazon, or Azure) or from the Localazy AI model, and cross-checks with its own shared translation memory to give you an instant first draft. 📑

Localazy also runs automated QA rules in the background to flag common UI and UX problems. These are quick wins that otherwise slip through unnoticed.

Post-editing with translators & reviewers 🔗

After producing the first automated draft, Localazy lets you layer human input on top of the machine output:

✍️ Remote translators

The machine does a first pass, then a human linguist checks context, punctuation, placeholders, and fixes anything that feels off.

📝 Remote reviewers

Human reviewers run QA on translations (whether machine or human-generated) to catch consistency issues or tone mismatches.

The best thing is, you don’t have to hire and manage reviewers manually, as it’s all built into Localazy’s Autopilot service. For markets where you really don’t want to compromise on quality (your core revenue regions), Localazy connects you directly with vetted professional translators. They’ll handle the cultural adaptation and style to make sure it aligns perfectly with your brand voice.

Everything is managed within the platform workflows, so you don’t waste time engaging and managing freelancers or agencies.

Alternatively, you can opt for a machine translation approach using Localazy AI and style guides. It’s ideal for lower risk products or for markets where speed and scalability are more important than perfection.

💙 Give Localazy a try today and see how it can improve your localization testing workflows. It’s free for the first 14 days!

？FAQ 🔗

Do I really need localization testing if my product is small? 🔗

Yes. Even a lightweight app or website can lose users fast if the translation feels off or the UI breaks. Small multilingual products often rely on first impressions and you may only get one shot.

Isn’t machine translation good enough now? 🔗

MT has come a long way, but it still misses nuance, idioms, and cultural fit. Machines catch the easy stuff, then humans add the finishing touches to make it sound natural. The winning formula is using both.

Can’t I just rely on user feedback to catch issues? 🔗

Not safely. Most people won’t tell you when something feels wrong: they’ll just run away. Waiting for complaints means losing users you might never win back.

How much does localization testing cost? 🔗

It depends on your product size and number of languages. Doing it manually can add up — for example, five hours of testing across five languages at around $50 per hour, plus another eight hours of human review per language, could easily reach $2,800 or more.

But a platform like Localazy helps cut these costs. Automated QA, in-context previews, and built-in reviewer workflows remove much of the manual effort, cutting both time and spend. Instead of hiring and managing freelancers or agencies, you can handle everything in one place.

How long does localization testing take? 🔗

For small apps, think a few hours per language. For bigger localized products (like games or complex platforms), it can take days for each language. Either way, catching errors before launch is always faster than fixing them afterwards.

What’s the difference between localization testing and QA testing? 🔗

QA looks for things that break your product. Localization testing looks for things that break the experience: the language, culture, layout, and flow, which is the stuff that makes users feel “this was built for me.”

🧱 What you'll build in this tutorial 🔗

Here’s a quick look at the Angular localization app you’ll create in this tutorial. The video below shows the final result, including the integration with Localazy for managing translations effortlessly.

1. 🏗️ Part 1: Foundations. Set up your Angular project, configure runtime i18n with ngx-translate, handle missing translations, and style everything with Tailwind.
2. 📲 Part 2: App logic. Build the full invoice dashboard and create, edit, delete, print, and export invoices while preparing every element for translation.
3. 🌎 Part 3: i18n. Integrate Localazy, manage the translation workflow, add pseudo-locales for testing, and use ICU pluralization for dynamic content.

🧑🏿‍💻 Project overview 🔗

In this project, you’ll build a Progressive Web App (PWA) using Angular designed to showcase a complete localization workflow. The app manages invoice data, supports multiple languages, and integrates with Localazy for automated translation management.

invoice-pwa/
├── public/
│   ├── assets/
│   │   └── i18n/
│   │       ├── en.json
│   │       ├── fr.json
│   │       └── qps.json
│   ├── icons/
│   ├── favicon.ico
│   └── manifest.webmanifest
│
├── src/
│   ├── app/
│   │   ├── core/
│   │   │   ├── models/
│   │   │   │   └── invoice.model.ts
│   │   │   ├── network/
│   │   │   │   └── network.service.ts
│   │   │   ├── persistence/
│   │   │   │   ├── invoice.repository.ts
│   │   │   │   └── invoice.serialization.ts
│   │   │   ├── pwa/
│   │   │   │   ├── pwa.service.ts
│   │   │   │   └── update.service.ts
│   │   │   ├── stores/
│   │   │   │   └── invoice.store.ts
│   │   │   ├── utils/
│   │   │   │   ├── csv.ts
│   │   │   │   ├── date.ts
│   │   │   │   ├── files.ts
│   │   │   │   ├── id.ts
│   │   │   │   ├── money.ts
│   │   │   │   ├── time.ts
│   │   │   │   └── dev-missing.handler.ts
│   │   │   ├── language.service.ts
│   │   │   └── locale-format.service.ts
│   │   │
│   │   ├── features/
│   │   │   ├── dashboard/
│   │   │   │   ├── dashboard.component.html
│   │   │   │   ├── dashboard.component.scss
│   │   │   │   └── dashboard.component.ts
│   │   │   ├── invoice-edit/
│   │   │   │   ├── invoice-edit.component.html
│   │   │   │   ├── invoice-edit.component.scss
│   │   │   │   └── invoice-edit.component.ts
│   │   │   └── invoice-view/
│   │   │       ├── invoice-view.component.html
│   │   │       ├── invoice-view.component.scss
│   │   │       └── invoice-view.component.ts
│   │   │
│   │   ├── shared/
│   │   │   └── translate-loader.factory.ts
│   │   ├── app.config.ts
│   │   ├── app.routes.ts
│   │   ├── app.html
│   │   ├── app.scss
│   │   ├── app.spec.ts
│   │   ├── app.ts
│   │   ├── index.html
│   │   ├── main.ts
│   │   └── styles.scss
│
├── .editorconfig
├── .gitignore
├── .postcssrc.json
├── angular.json
├── localazy.json
├── localazy.keys.json
├── ngsw-config.json
├── package-lock.json
├── package.json
├── [README.md](http://readme.md/)
├── tailwind.config.js
├── tsconfig.app.json
├── tsconfig.json
└── tsconfig.spec.json

The folder structure is organized for clarity and

For clarity and stability, the folder structure is organized like this:

• public/assets/i18n holds all translation files (en.json, fr.json, and qps.json) used by the Angular i18n system.
• src/app/core contains essential app logic such as models, data persistence, network handling, and localization services.
• src/app/features includes feature modules like the dashboard, invoice editor, and invoice viewer that demonstrate component-based structures in Angular.
• src/app/shared provides shared utilities like the custom translation loader used to connect ngx-translate with Localazy.
• Root files such as angular.json, localazy.json, and tailwind.config.js define build configuration, localization settings, and global styling via Tailwind CSS.

This modular setup will make our app maintainable while providing a solid foundation for scaling to more languages, features, and environments.

1️⃣ Step 1: Create a new Angular application 🔗

To begin integrating Angular i18n with Localazy, first scaffold a clean Angular workspace.

This ensures your localization setup is consistent and ready for translation file extraction later.

Run the following command in your terminal:

npx @angular/cli@latest new invoice-pwa --routing --style=scss

When prompted, select the following options:

• Server-Side Rendering (SSR) and Static Site Generation: No
• 'Zoneless' application without zone.js: No
• AI tools configuration: None

With this, you'll get a clean environment without extra dependencies or configurations that might distract from the core topic of integrating Angular with Localazy.

Once the CLI finishes, navigate to your new project directory.

cd invoice-pwa

You now have a baseline Angular project with routing and SCSS styling, ideal for adding Angular i18n, @angular/localize, or ngx-translate later on in this tutorial.

Project setup 🔗

Before you integrate Angular with Localazy, confirm that your base project runs correctly. This step ensures your environment, dependencies, and Angular CLI configuration are all working as expected.

Run the following commands:

npm install
npm start

Once the development server starts, open your browser and navigate to:

<http://localhost:4200/>

You should see the default Angular welcome page:

2️⃣ Step 2: Set up runtime i18n with ngx-translate 🔗

Runtime internationalization allows your Angular app to load and switch languages instantly without needing to rebuild. While the built-in Angular i18n is ideal for compile-time translations, this tutorial focuses on ngx-translate, a more flexible runtime alternative. We’ll use it and its companion libraries to handle dynamic language changes, and later connect it seamlessly with Localazy for automated translation management.

Run the following commands to add the core translation and message formatting packages:

npm install @ngx-translate/core @ngx-translate/http-loader
npm install ngx-translate-messageformat-compiler messageformat

These packages provide:

• @ngx-translate/core, the main translation service and pipe.
• @ngx-translate/http-loader loads translation files from assets.
• ngx-translate-messageformat-compiler and messageformat enable pluralization and complex message syntax following the ICU Message Format standard (e.g., “{count, plural, one {1 item} other {# items}}”). With ngx-translate installed, the next step is to give it something to load.

3️⃣ Step 3: Create translation files 🔗

Inside your project, create a dedicated folder for localization files and add two JSON files for your target languages:

public/assets/i18n/en.json
public/assets/i18n/fr.json

Each file will hold key-value pairs for translated strings. For example:

src/assets/i18n/en.json

{
  "app": {
    "title": "Welcome to Your Invoice & Expense Tracker",
  },
  "lang": {
    "switch": "Change Language",
    "en": "English",
    "fr": "French"
  }
}

src/assets/i18n/fr.json

{
  "app": {
    "title": "Bienvenue dans votre outil de suivi des factures et des dépenses",
    "welcome": "Bienvenue dans notre application !"
  },
  "lang": {
    "switch": "Changer de langue",
    "en": "Anglais",
    "fr": "Français"
  }
}

We’ll later add a qps.json pseudo-locale file, as you saw in the project structure, to show how pseudo-localization helps identify untranslated or hard-coded text during development. This will also be important when syncing with Localazy.

4️⃣ Step 4: Configure the translation loader 🔗

The app needs to know where to fetch translations and how to initialize a default locale. We’ll configure TranslateModule to use an HTTP loader that pulls JSON files at runtime. This follows the standard ngx-translate pattern.

Before Angular can fetch your translation files, it needs a loader that knows where to look. The HttpLoaderFactory handles this by defining the base path used by @ngx-translate/http-loader and plays nicely with sub-path deployments.

Create the file:

src/app/shared/translate-loader.factory.ts

Add the following code:

import { TranslateLoader } from '@ngx-translate/core';
import { TranslateHttpLoader } from '@ngx-translate/http-loader';

/**
 * Uses document.baseURI so it also works when the app is deployed under a sub-path.
 * Example URL: <base href="/invoice-pwa/">
 */
export function HttpLoaderFactory(): TranslateLoader {
  return new TranslateHttpLoader();
}

This factory simply tells Angular where to load translation files from at runtime. It ensures your app fetches language JSONs correctly, even when deployed in subdirectories, and prepares the setup for smooth TMS integration later.

5️⃣ Step 5: Add a custom missing translation handler 🔗

To make localization easier to debug during development, you can add a custom missing-translation handler. This feature helps identify untranslated keys directly in your templates, with no need to check console logs. It’s one of the most useful Angular localization best practices when working with ngx-translate instead of the default Angular i18n compiler approach.

Create the file:

src/app/core/dev-missing.handler.ts

Add the following code:

import { MissingTranslationHandler, MissingTranslationHandlerParams } from '@ngx-translate/core';

export class DevMissingHandler implements MissingTranslationHandler {
  handle(params: MissingTranslationHandlerParams) {
    // Loud in dev so you see gaps immediately. Do not enable in production.
    return `⛔ ${params.key}`;
  }
}

To simplify runtime language management, it’s best to wrap all i18n logic inside a small, dedicated service. Language switching, storage, and fallback logic will then stay consistent across components.

Create the file src/app/core/language.service.ts

Add the following code:

import { Injectable } from '@angular/core';
import { TranslateService } from '@ngx-translate/core';

type Lang = 'en' | 'fr';

@Injectable({ providedIn: 'root' })
export class LanguageService {
  private readonly storageKey = 'lang';
  private readonly supported: Lang[] = ['en', 'fr'];

  constructor(private translate: TranslateService) {}

  init(): void {
    const saved = (localStorage.getItem(this.storageKey) as Lang | null) ?? this.matchNavigator();
    this.use(saved);
  }

  use(lang: string): void {
    const chosen: Lang = this.supported.includes(lang as Lang) ? (lang as Lang) : 'en';
    this.translate.setDefaultLang('en'); // fallback
    this.translate.use(chosen).subscribe({
      next: () => localStorage.setItem(this.storageKey, chosen),
      error: () => this.translate.use('en'),
    });
  }

  private matchNavigator(): Lang {
    const nav = (navigator.language || navigator.languages?.[0] || 'en').slice(0, 2);
    return (this.supported as string[]).includes(nav) ? (nav as Lang) : 'en';
  }
}

This service handles all runtime language management for your app. It detects the user’s browser language, applies the right locale, and remembers their choice for future sessions. You’ll initialize this service during app startup (in app.ts ) to set the default language as soon as the app loads.

Let’s verify everything end-to-end by initializing it in the root component and exposing a setLang method to set the default language as soon as the app loads.

Update your src/app/app.ts (or your root component) to include the service:

import { Component, OnInit } from '@angular/core';
import { LanguageService } from './core/language.service';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
})
export class AppComponent implements OnInit {
  constructor(private lang: LanguageService) {}

  ngOnInit(): void {
    this.lang.init(); // picks saved/browser language and sets default fallback
  }

  setLang(code: 'en' | 'fr'): void {
    this.lang.use(code);
  }
}

Replace your existing code in app.html with the following snippet:

<header class="app-header">
  <h1>{{ 'app.title' | translate }}</h1>
  <div class="spacer"></div>
  <button type="button" (click)="setLang('en')" aria-label="Switch to English">{{ 'lang.en' | translate }}</button>
  <button type="button" (click)="setLang('fr')" aria-label="Basculer en français">{{ 'lang.fr' | translate }}</button>
</header>
<main class="app-main">
  <router-outlet />
</main>

Then run a test:

npm start

You should see the title text translated, and the language switches instantly when you click the buttons.

6️⃣ Step 6: Add Tailwind CSS for a consistent UI 🔗

With translations working, it’s time to style your Angular app using Tailwind CSS. Tailwind provides a fast, utility-first approach that keeps your UI consistent while integrating Localazy and building multilingual interfaces, a key part of modern Angular localization workflows.

1. Install dependencies 🔗

Run the following command to add Tailwind and PostCSS:

npm i -D tailwindcss @tailwindcss/postcss postcss

2. Create a PostCSS configuration 🔗

In your project root, create .postcssrc.json:

{
  "plugins": {
    "@tailwindcss/postcss": {}
  }
}

3. Import Tailwind into your global stylesheet 🔗

Since the project uses SCSS, open src/styles.scss and add:

@use "tailwindcss";

@layer components {
  .btn {
    @apply inline-flex items-center gap-2 rounded-lg bg-blue-600 px-3 py-1.5 text-white
           font-medium shadow hover:bg-blue-700 focus:outline-none
           focus:ring-2 focus:ring-blue-500/50 active:translate-y-px;
  }

  .btn-secondary {
    @apply inline-flex items-center gap-2 rounded-lg border border-gray-300 bg-white
           px-3 py-1.5 text-gray-700 shadow-sm hover:bg-gray-50 focus:outline-none
           focus:ring-2 focus:ring-gray-400/40;
  }
}

For more details, refer to the official Angular + Tailwind guide

Now, add the corresponding .btn and .btn-secondary classes to the two language switch buttons in your app.html.

4. Restart the development server 🔗

Once done, restart your Angular environment to apply the styles and confirm everything works correctly:

Ctrl + C
npm start

Your Angular app now has Tailwind CSS fully configured, and the localized buttons are styled consistently across languages.

You’ve just laid the foundation of your Angular PWA, setting up runtime i18n with ngx-translate, connecting your translation loader, handling missing keys gracefully, and giving the whole app a clean Tailwind base.

That’s a big step. You now have a flexible structure ready for real content and real users.

➡️ What next? 🔗

In the next part, you will bring this foundation to life. You’ll build the core of the invoice dashboard: creating, editing, and managing invoices with features like printing, exporting, and importing data. Each feature will quietly stay i18n-ready so that, when you move to Part 3, you can seamlessly plug everything into Localazy and localize the entire app in multiple languages, including pseudo-locales, and ICU plurals. See you there! 👋

In localization, this pain often equals high costs, long hours of research, and large teams of experts. In-house data and know-how are the only effective way forward, so if you lack these key ingredients, your company won’t be able to grow.

This assumption often leads to lost opportunities.

Localization isn’t only for big businesses with large budgets. Your small or medium-sized business can grow globally, too. And you don’t need to hire expensive consultants to enter new regions in style.

All you need is a change of perspective. And a different set of tools.

One such tool is a large language model.

👀 What's the cheapest way to localize your SaaS? 🔗

Localization for SaaS companies typically costs between $10,000 and $50,000 for initial entry into a single language. Ongoing annual maintenance is pricey too, ranging between 15 and 25% of that cost each year.

This isn’t money thrown down the drain. Companies that invest in localization are more likely to grow revenue, with 96% reporting a positive return from their efforts and 65% reporting a ROI of 3x or greater as a result. If done smartly, localization costs less than deciding not to localize. How is that possible? We explained it in this article on best practices to allocate a budget for localization – whether it’s big or small. The key conclusion is: localization is not optional.

But how to benefit from localization when your budget is tight?

Small and mid-sized SaaS companies often struggle to find resources for such an investment. Market data, competitor analysis, linguistic insights – every single step multiplies the costs.

This is where AI may come in handy. It makes localization planning more accessible for smaller brands. Using tools such as ChatGPT or Claude, you can easily conduct market research, validate assumptions, or spot market trends.

No more guesswork. No more delays. No more excuses.

🔦 When does AI localization research make sense? 🔗

AI-powered research can be useful in these two scenarios:

1. You’re localizing for the first time and need to make smart moves fast.
2. You’re already present on the global market, but want to scale without overloading/expanding your team.

Let’s have a closer look at both situations.

The Starter 🔗

You’ve built a product that’s working in your home market. Web traffic is growing, and sales figures are climbing. You know that localizing your product and marketing could lead to more growth, but you’re now wondering:

• How do I choose which countries to expand to first?
• What’s the best go-to-market strategy for startups?
• How can I define my go-to-market strategy?

You don’t have a localization team, and hiring localization strategists is out of the question.

With a few smart prompts, AI can:

• Suggest languages for localization based on your current user engagement.
• Build an internationalization roadmap tailored to your existing setup.
• Help you compare potential markets using publicly available data.

The Scaler 🔗

You’ve experimented with localization. Maybe you’ve translated your app into a few languages or hired freelance translators for your blog. Perhaps you also have multiple users across Europe and Asia, but your growth is slow.

You’re wondering:

• Is it a good idea to localize everything for more impact?
• Which markets deserve significant investment?
• Should we use ChatGPT for market research?

With the right AI-powered prompts, you can:

• Audit your existing localization efforts.
• Prioritize regions based on user visits and revenue.
• Build a localization ROI model to support strategic decisions.

Whether you’re just starting or scaling up, AI can give you enough data to build your roadmap and make the right decisions.

⬇️ What we’ll cover 🔗

In this guide, we’ll show you how to use ChatGPT and similar LLMs to support key parts of your go-to-market localization strategy.

You’ll get ready-to-use prompt templates for:

• 🗺️ Choosing your first or next localization markets
• 🪜 Mapping a lightweight internationalization plan
• 💰 Estimating and tracking localization ROI

Each prompt is designed for two scenarios: companies just starting out and those scaling into new regions.

Disclaimer: Always review and adapt prompts to your business context. Don’t share sensitive data. Use anonymized or high-level info when feeding AI tools.

With this cleared out, let’s look into the nitty-gritty.

🗺️ How to craft your localization strategy roadmap with AI 🔗

1. Language selection 🔗

Choosing the right languages is a tough enterprise when you don’t have solid data to lean on. Guesswork might be costly, but you can use this prompt to craft effective go-to-market strategies.

Act as a localization strategist helping a small SaaS company identify the most strategic languages for their first localization effort.

Here’s the company background:
- Product: [brief description of your product or service]
- Current market: [main market, e.g., UK, Germany]
- Existing users outside the core market: [any known user traffic or signups by region or language, if available]
- Ideal customer profile: [who your main users are: include industry, job titles, pain points]
- Known limitations: [budget, team size, tech stack limitations]

Based on this context, which 3–5 languages would be the most strategic to start with, and why? Include expected benefits and potential challenges.

Act as a senior localization strategist supporting a SaaS company with an existing international presence. Help us evaluate and prioritize the next 3–5 languages to localize into based on our current presence and growth goals.

Here’s the company context:
- Product: [brief description of your product or service]
- Existing localized languages: [list]
- Regions or countries we currently serve: [list]
- Web traffic by region/language: [if available]
- Conversion and churn rates by region/language: [if available]
- Support ticket language trends or user requests: [if any]
- Ideal customer profile: [industry, buyer role, usage patterns]
- Strategic goals: [e.g., deepen market penetration, enter new regions]
- Constraints: [e.g., limited resources, need for quick wins, tech limitations]

Based on this input, suggest which 3–5 new languages would offer the highest potential impact. For each language, explain:
- Why it's a good fit based on our user base and growth goals
- Potential challenges or hidden costs

Also note any “nice-to-have” languages we could consider later, and markets we might want to avoid for now.

Before evaluating which languages to localize into, it’s essential to define your global ambitions and identify where you can realistically compete. In this guide on choosing the right language, we break down four key pillars to consider: economic viability, cultural alignment, strategic fit, and regulatory complexity. By using these pillars, you can make smarter market entry decisions.

96% of companies report a positive ROI from localization efforts. These efforts start with choosing the right language. Now, with the AI prompts for marketing strategy presented above, you’ll be able to take the first steps towards more revenue.

2. Internationalization roadmap 🔗

Once the language puzzle is solved, it’s time to move to the next phase. With the prompt discussed below, you can create an internationalization plan that will prepare your content for localization.

Act as a localization and internationalization strategist guiding a small SaaS company through its first internationalization effort. We want a phased, startup-friendly roadmap that helps us prepare our product and content for localization without disrupting our core development.

Here’s the company context:
- Product type and key features: [brief description]
- Current tech stack: [e.g., CMS, Localazy, etc.]
- Team structure: [e.g., small engineering team, no dedicated localization manager]
- Budget or resource limits: [if any]
- Target markets and languages: [initial picks or regions of interest]
- Timeline goals: [e.g., ready for launch in 3–6 months]

Based on this, outline an internationalization roadmap that includes:
- Key technical tasks (e.g., extracting translatable strings, handling date formats, multilingual UI support)
- Content preparation steps (e.g., rewriting hardcoded content, structuring metadata for translation)
- Suggested tooling or automation
- Realistic phases with estimated timelines
- Any “quick wins” we can implement early

Flag any common pitfalls we should watch out for.

Act as a senior internationalization strategist advising a SaaS company that has already localized into several languages but lacks a structured, scalable internationalization process. Help us design a roadmap that prepares our product, content systems, and teams to expand into new markets.

Here’s our current situation:
- Product overview: [short description]
- Current languages and markets: [list]
- Tech stack and frameworks: [e.g., headless CMS, Localazy]
- Known internationalization gaps or pain points: [e.g., hardcoded UI strings, inconsistent translation workflows]
- Team setup: [e.g., engineering, marketing]
- Growth goals: [e.g., enter 3 new regions in the next 12 months]
- Constraints: [e.g., no full-time internationalization lead, limited engineering time]

Based on this context, build an internationalization roadmap that includes:
- Technical priorities for scalable internationalization (e.g., locale management, automation)
- Workflow and tooling improvements (e.g., TMS integration, automated QA)
- Governance and roles (e.g., who owns what, central vs local input)
- Sequencing by impact and feasibility
- Milestones over the next 3–12 months

Highlight common scaling traps to avoid.

There’s no localization without internationalization. So, don’t cut corners by jumping straight into translating your content. It has to be market-ready first. If you’re in doubt as to what internationalization involves, have a look at our short explanation here.

Effective internationalization can save companies around 30-50% in preparation and localization costs, while significantly reducing time-to-market. With the prompts presented above, you’ll be on the right track to achieve these savings as well.

3. Localization ROI tracker 🔗

Your i18n and localization efforts might be worthless if you don’t know how to track your gains. But there’s a prompt for that, too. This is how you can create a localization ROI tracker tailored to your company.

Act as a SaaS localization strategist helping a small company define a simple, actionable way to track the return on their first localization investments.

Here’s the company context:
- Product type: [brief description]
- Initial localization plan: [languages or regions to be localized, content]
- Key goals: [e.g., increase signups, grow in non-English markets]
- Data available: [e.g., traffic by region, conversion rates]
- Current tools: [e.g., HubSpot, custom dashboards]

Based on this, create a basic ROI tracking framework that includes:
- What to track before and after localization (e.g., traffic, signups, conversion)
- A few simple KPIs that reflect product and content performance across regions
- How to attribute improvements to localization efforts
- How often to review the data and what to look for

Prioritize clarity and startup-readiness. The framework should be easy to implement using existing tools and help us make smarter localization decisions over time.

Act as a senior localization strategist advising a SaaS company that has already localized into several markets. We need a structured but practical way to track the ROI of our localization efforts, so we can optimize budgets and prioritize high-performing regions.

Here’s our company context:
- Product type: [brief description]
- Current localized languages: [list]
- Primary growth goals: [e.g., increase paid user conversion]
- Available data: [e.g., app downloads by region, engagement metrics]
- Current tools: [e.g., HubSpot, Google Analytics]
- Known gaps or challenges: [e.g., inconsistent tagging]

Based on this input, create a localization ROI tracking framework that includes:
- Metrics to track across the funnel (awareness, acquisition, activation, retention, revenue)
- Which KPIs to monitor for each language/region
- How to compare localized vs non-localized markets
- Suggestions for data visualization and reporting
- How often to review performance and adjust strategy

The framework should be actionable, scalable, and team-friendly. Also, note any common pitfalls to avoid.

The formula for your localization ROI might depend on your KPIs, but in essence, it boils down to:

We explained it in more detail in this guide to measuring your localization ROI: Costs, benefits and KPIs.

Companies using AI for performance and investment ROI tracking save over 20 hours per employee each month, which helps to reduce operational costs by 30%.

Now, with the prompt above, you can join the ranks of these smart brands as well.

🔎 How to effectively use AI prompts for a localization strategy? 🔗

The prompts we’ve just discussed are not set in stone. You can play around with them and customize them to your business needs. It won’t hurt to take a step further and add relevant real-world data, too.

Here’s a short overview of how to enrich your prompts and generate more tailored results:

1. User research and feedback 🔗

Adding relevant data from customer reviews, support tickets, or customer surveys will allow the AI model to provide more precise suggestions on content prioritization, new markets, and languages. The outputs will match the actual user behavior.

2. Channel performance by market 🔗

Some channels outperform others in specific regions, and spotting these early can reveal valuable market identification trends. This kind of data helps you decide which content to localize first based on where engagement is already happening. Even if your SaaS company is active in just one market for now, you can enrich your prompt by sharing which channels you currently use or plan to test when entering new markets.

3. Competitor benchmark 🔗

You don’t need a deep market analysis, but a quick scan of 2-3 competitors’ websites, apps, or marketing content can be a good source of invaluable insights.

Your competitors have already made decisions about language, content, or channels that you can learn from. By using effective prompts for market research, you can spot market gaps, identify competitive differentiators, or come up with strategies that align or deliberately contrast with the market norm.

💬 The final prompts, ready to use 🔗

We’ve reached the end of our prompting journey. But before you jump into experimenting with these free prompts for GTM strategy, here’s a clear overview and a checklist to make sure you know where to start.

📋 AI-powered localization strategy checklist 🔗

Even the best prompts for GTM strategy can backfire if you act without a plan.

Make sure to follow these steps to stay on track:

   ☑ Define your goal: Are you launching for the first time or expanding existing localization?

   ☑ Gather key business context: Product type, ICP, traffic sources, known constraints.

   ☑ Collect available data: Traffic, conversion rates, support tickets, customer feedback.

   ☑ Analyze your competitors: Identify which markets, languages, and content types they localize.

   ☑ Run the language selection prompt: Prioritize target languages based on data and goals.

   ☑ Create an internationalization roadmap: Map out tech, content, and timeline phases.

   ☑ Define your localization KPIs: Use the ROI tracker prompt to measure what matters.

   ☑ Feed your prompts rich context: Include all the inputs above to boost AI accuracy.

   ☑ Review AI-generated insights: Validate outputs with your team before implementation.

Finally, don’t forget to choose your tools wisely. If you’re ready to localize your content and enter new markets, use tools such as Localazy and Localazy AI to put your AI-powered localization strategy into action. When in doubt, you can always ask your preferred LLM about the best course of action in localization using Localazy, or contact us directly.

🤔 FAQ: Using AI prompts for your localization strategy 🔗

1. Can I trust AI-generated insights for strategic decisions?
Act with caution. AI is a powerful research assistant, not a decision-maker. The prompts in this guide are designed to show useful patterns and perspectives. Always validate outputs with real data and your team’s feedback before putting AI suggestions into action.

2. What if I don’t have all the data the prompts ask for?
That’s not a problem at all. Even partial context can improve the output quality. Start with what you have and refine later as you collect more data over time.

3. Is it safe to include business data in my prompts?
Not really. Avoid sharing sensitive or personally identifiable information. Summarize or anonymize wherever possible to protect your data while still guiding the AI effectively.

1. Navigate to the top left menu and click on the question mark icon.
2. Find Feature preview and open it
3. Toggle Dark mode in the dialog window that appears
4. Click on your profile picture and find Theme preference
5. Choose from Light, Dark, or System

😎 Tell us your thoughts! 🔗

Hope you enjoy this quick update. Please let us know on the support chat if you catch anything that is too dark to read, or too bright to handle.

The framework gives you a solid platform on which to build fast, reliable applications that scale with both the size of your team and the size of your codebase. In this article, we will create a demo app showing how to localize an Angular app with angular-18n and Localazy.

📋 Prerequisites 🔗

• Install Node.js if you don't have it already. The Angular CLI requires a minimum Node.js version of v20.19 for Angular v20, which is the most recent version as of the time of writing this article.
• Install Angular CLI using the command npm install -g @angular/cli

👩🏾‍💻 Set up a new Angular project 🔗

In your terminal, run the CLI command ng new with the desired project name. In the following example, we'll be using the angular-i18n-localazy-demoproject name:

ng new angular-i18n-localazy-demo

You will be presented with some configuration options for your project. Use the arrow and enter keys to navigate and select which options you desire.

If you don't have any preferences, just hit Enter to take the default options and continue with the setup.

At this point, we are ready to run our project locally!

To start a local development server, run the command:

ng run start

This command should open a browser window with the application running.

We can temporarily stop the server and initiate the process of internationalization.

Internationalization (i18n) is the process of preparing your application to support multiple languages and regional formats without needing code changes. It involves extracting text from templates, managing translation files, and handling formats like dates or currencies.

The package that is needed for internationalization in Angular is @angular/localize. It was introduced in v9 and adds i18n support to an Angular app.

You can find detailed information about internationalization in the official Angular documentation.

To add the @angular/localize package, use the following command to update the package.json and TypeScript configuration files in your project:

ng add @angular/localize