Canvs works with some of India's largest BFSI companies whose products are built for all Indians, across many languages. And naturally, that meant people would be using that product in their own languages, and not just English. Assuming every user would interact with the app in English was not an option. The designers had to share flows with stakeholders in every supported language to show how the product would look and feel in practice.

That came with two problems:

• Translating each screen’s English microcopy to Hindi, Marathi, Gujarati, Telugu, Kannada, and Tamil.

• Fixing the layout once translated, because each language occupies different space.

Let’s talk about the first problem and how we went about solving it.

Figma's native "Translate to" feature doesn't support Indic languages, so the team had to rely on Google Translate. Their workflow looked like this:

Select text from a screen → copy → go to browser → paste into Google Translate → copy output → switch back to Figma → paste at the relevant place manually

Doing this across 6 languages for every UI element on every screen left very little room for the work that actually needed thinking. And since BFSI screens are information-heavy, so each one took roughly 5 minutes. Across 300 screens, the cumulative time was significant.

Finding an existing tool vs building one

The team sifted through the internet for existing tools & plugins to solve their problem, and tried quite a lot of them before ruling them out.

Some were free, some had usage caps, some were paid. The free ones were the most tempting, but most of them were someone's weekend project, and maintained on good intentions. A plugin like that can stop existing any day, with no notice and no fallback.

It doesn't work when you're delivering for one of India's largest banking companies on a committed timeline. One plugin failure mid-project can turn a 15-day delivery into a 3-month one.

We are chosen as a design agency and get paid because we do certain things better and faster. We deliver what we promise on time. So, the tools that support that work need to hold up under the same standard.

Building our own localisation plugin

Akhil, a product designer at Canvs, decided to build a translation tool of his own that could turn his days of work into mere seconds. He started by identifying a reliable translation API. Google Cloud Translation API was the straightforward answer. It is stable, well-supported, and not going anywhere.

Having used several existing plugins, he already had a clear picture of what the tool needed to do:

• Retain his API token across sessions

• Support popular Indic target languages

• Handle multiple text layer selection and automatically fetch layers inside a frame

• Show a translation preview for selected layers before applying

• Run a single "translate all" action across every selected layer in the target language

The localisation plugin Akhil built in Cursor with Claude, showing the translation panel inside Figma.

The build timeline break down looked like this:

• Research: 30 mins

• Google Cloud Translation API setup: 10 to 15 mins

• Proof of concept (HTML, CSS, JS web app via Claude): 5 mins

• Figma plugin base folder: 5 mins

• Full plugin build in Cursor with Claude: 30 mins

• Feedback-driven improvements: 30 mins

The first version had no CSS. The focus was entirely on getting the functionality right, which was correct translation, multi-layer handling, accurate placement. Once that was confirmed, the second pass addressed the interface and made it more intuitive to use. The plugin supported all Indic languages available through Google Cloud Translation API.

The impact of the built plugin

The plugin in action, translating text layers across a BFSI screen in seconds.

The plugin is now used across all screens of this BFSI product and has been shared across the studio for use on other large BFSI projects. Stress testing new screens against Indic languages has become a standard step in the design process rather than something that happens when there's time for it.

Beyond the time saved, the error rate dropped. Working manually across hundreds of screens, it was easy to miss text strings just because of the sheer volume of it. A single "translate all" action removes that category of error entirely. The team has already saved days of work that would otherwise have gone to a repetitive mechanical task.

Now that the first problem was solved, it exposed a second problem. Even after the copy was translated, the layouts were breaking. Switching a screen to Devanagari or Tamil changed how much space the text occupied. The same word in each language occupied different space.

The line height problem with Indic scripts

A side-by-side showing how the same words in different languages occupy different space vertically when the script changes from Latin to Indic scripts.

Once the translation is done, it needs font changes for those multiple Indian languages. You need something that covers the major scripts, looks consistent across them and ideally does not require a separate licensing conversation.

For a lot of teams, that search leads to variable fonts on Google Fonts that cover Indic scripts. Anek, a variable typeface family, is one of the better ones. It is free, well-designed, and covers ten scripts including Latin, Devanagari, Gujarati, Tamil, Telugu, and Kannada.

Here is where it gets complicated.

Most UI layouts are built and tested in Latin, then switched to an Indic script without accounting for that difference. Latin characters sit between a baseline and a cap height. The vertical range is tight and predictable. Indic scripts work differently. Devanagari has a horizontal headline bar with vowel marks that hang above it. Tamil and Telugu have stacked conjunct forms that extend well below the baseline. A single line of text occupies more vertical space, and the amount varies by script.

How different line heights break in practice

Example of centred layouts, buttons, and nav rows breaking when switched to an Indic script.

The most common place you see it is in centred layouts. For instance, a stock market card, a loan offer banner, a KYC input field, or anything where text is vertically centred inside a fixed-height container. In Latin, it looks right. Switch to a Devanagari script and the text floats toward the top. The layout doesn’t change to accommodate the taller font and extra vertical space used.

Another example would be a primary CTA with centred label text. It will look optically wrong in Hindi or Marathi at the same height designed for English.

Even with navigation rows and tab bars, Latin and Devanagari sitting in the same row have visibly different vertical alignments.

Screens which have multiple scripts, like a financial product serving Hindi speakers, will regularly have English numerals, Latin brand names, and Devanagari body copy on the same card. That is not one line height difference to manage. It is three or four, on the same surface, at the same time.

Figma’s fallback behaviour

Figma's properties panel showing Anek Latin while the canvas is silently rendering a system font fallback.

When a designer pastes Hindi or Tamil text into a Figma layer, two things happen simultaneously:

1. The text renders on screen and looks fine

2. The properties panel still shows Anek Latin as the selected font

So the designer moves on. Nothing looks wrong. But, Anek Latin has no Indic characters. When Figma can't render a character in the selected font, it substitutes it with a system font, without notifying it.

The problem is that the system font that steps in looks different from Anek, with different weight, different spacing, different proportions. So the screen the designer is looking at is not what users will actually see in the product.

We caught this while working on a project, when a Devanagari danda went invisible. The danda (। U+0964) is a sentence-final mark used in Hindi and Marathi, equivalent to a full stop. It was present in the string. The fallback font was rendering it in a colour that did not show against the background. The layer did not indicate anything wrong.

The practical consequence is bigger than one missing character. A designer working in Anek Latin who pastes Hindi, Tamil, or Telugu text and sees it render on canvas can reasonably conclude that Anek Latin supports those scripts. It does not. They are looking at a system font wearing Anek's name.

Screens designed and reviewed in this state get approved in a font that won't match production. The problem doesn't surface until it's already in front of users.

Fixing the space issues, vertical and horizontal

Design problems with accessibility that were identified in 2001 still show up today.

The line height fix has two parts.

1. We set line-height: 1.4 (140%) across all text using Indic script variants, without exception, as compared to the Latin variant, which has line-height: 1.2 (120%). That’s because Indic scripts have taller glyphs, and at tighter line heights the descenders and vowel marks from one line visually collide with the headline bar of the line below. 140% gives enough clearance to prevent that.

2. For CTAs, input fields, and other single-line elements, vertical trim was set to cap height to baseline. This keeps text optically centred inside fixed-height containers regardless of how much vertical space the font file claims around the glyph. These two fixes are independent of each other.

Now to deal with the horizontal spacing issue, we grouped languages into three tiers based on how much the translated string expands in length compared to the English original.

Tier 1 → English, the Latin baseline. No adjustment needed.

Tier 2 → Hindi, Marathi, and Gujarati. Strings run longer than English but are manageable within existing layout constraints.

Tier 3 → Telugu, Kannada, and Tamil. Translated strings are noticeably longer than Tier 1 and 2. They need more attention during QA.

We did not redesign any of the completed screens. If you are earlier in your build, you have more options, and the next section covers what those are.

What we did change is how new components are designed going forward. Tier 3 languages, Telugu, Kannada, and Tamil, now drive the layout decisions for any new element. If a card, button, or input field works in Tamil, it will work in Hindi and English. Designing to the most constrained script first means you are not retrofitting every new component the way we had to retrofit the existing ones.

Localisation as a foundational design decision

The three-tier language grouping and the line height fix applied across Indic script variants.

Picking a typeface that covers the major Indian scripts is the starting point, but coverage alone is not enough. A more useful question would be "does this typeface cover the scripts we might need, and do those script variants behave consistently enough that we are not rebuilding layouts every time we add a language?"

When you pick a typeface that satisfies the above two criteria, test components in Tier 3 languages during the design phase.

Compare each script’s files by opening them side by side at the same type size and comparing the default line height. If there is a visible difference, that difference will show up in every centred layout in your product. It is not a dealbreaker, but it is work, and it is better to know about it before the design system is built around the font.

Replacing a typeface in a mature design system is a real project. Components, tokens, Figma libraries, documentation, production CSS. It is not impossible, but it is expensive and lengthy. It tends to get deprioritised because it is invisible to everyone except the people doing the work.