How to prepare notices for customers who read different languages

A translated heading does not make an English-only process usable. If the notice is understandable but the withdrawal page, verification message and reply are not, the customer can still struggle to act on the information. Language preparation should therefore follow the journey beyond the first paragraph.

Sections 5(3) and 6(3) provide an option to access notices and consent requests in English or a language specified in the Constitution’s Eighth Schedule. As of 22 October 2026, these provisions are scheduled for May 2027 under the commencement notification. This article describes preparation choices; it does not turn the statutory wording into a claim that every screen must display every language simultaneously.

Begin with the customers who use the service

List the languages people actually use at your counters, on support calls and in digital journeys. Ask frontline colleagues where misunderstandings occur. A delivery business may find that staff can explain a service orally in a local language but that the written permission form remains difficult for many customers.

This audience work helps prioritise implementation. It should not be used to narrow a statutory option without legal analysis. The business still needs a plan for the language access the law requires, including how requests outside the initially common languages will be handled.

Avoid treating language as a proxy for digital ability. Some customers prefer a local language on a smartphone; others need a printed or assisted route. The usable design depends on both language and channel.

Translate meaning from a stable source

First approve a clear source notice describing actual data, purposes and action routes. Translating an uncertain or inaccurate original simply produces several uncertain versions. Rule 3 requires clear, independently understandable information, so simplification belongs before translation as well as after it.

Create a small glossary for repeated concepts such as optional messages, withdrawal, account deletion and grievance. Ask a capable reviewer to check whether the translated phrases preserve the intended distinctions. A word that sounds formal may be less useful than a short explanation of what the customer can do.

Machine translation can support drafting, but review remains important for legal meaning and ordinary usage. Do not describe a tool-generated translation as officially approved unless there is evidence of that approval. Keep the reviewer and version history with the document.

A hypothetical two-channel test

Consider a local appliance retailer whose customers use English and Marathi. Its online form offers a language selector, while the shop counter provides printed notices. The same optional marketing choice appears in both journeys.

The retailer asks a reviewer to complete each route and explain whether declining marketing affects delivery. It then asks them to withdraw that choice. The test reveals that the Marathi notice links to an English-only preferences page and that counter staff cannot locate the withdrawal form.

The repair is operational as well as linguistic: translate or provide usable assistance for the relevant action, align the forms and train staff on the same explanation. A perfect translation of the initial notice would not have solved the broken route alone.

Keep versions connected

When a new data item or purpose is introduced, identify every affected language version and channel. A release checklist should prevent the English form changing while an older printed notice remains at the counter.

Store a version identifier for the approved content and a mapping to the translations. The consent evidence should be able to indicate which notice version and language were presented where relevant. This is a practical evidence design, not a statutory demand for a particular translation database.

If a translation is corrected, assess whether the change merely improves readability or alters an important meaning that customers previously received. The response may differ. Record the decision rather than silently overwriting the document and losing its history.

Make assistance preserve choice

Staff can help customers find information and explain how a process works. They should not make the optional decision on the customer’s behalf simply because reading the form takes time. Provide a way to pause, ask a question or decline.

Accessibility also includes text size, contrast, screen-reader compatibility and the ability to use the route on a modest connection. These are sensible design considerations; their exact legal requirements may arise from other applicable rules as well as the DPDP context.

The outcome to test is comprehension plus action. Can the person explain the proposed use and complete the relevant choice in a language route they can use? That question is more informative than counting translated files in a folder.