GDPR, DSA, and Localization: What Legal Requires Your i18n Team to Ship

Your German enterprise customer's legal team sent a security questionnaire. Question 47 asks: "Please confirm that your privacy policy and data processing terms are provided in German for data subjects located in Germany, and provide the audit trail."

You have a German privacy policy. You do not have an audit trail. Your options in the next 48 hours narrow considerably.

What are the actual localization requirements under GDPR?

GDPR does not have a single "localization" clause. It has several requirements that together create a de facto obligation to localize specific strings.

• Article 12. Requires that information provided to data subjects be "concise, transparent, intelligible and easily accessible, using clear and plain language". In practice, EU data protection authorities interpret this as requiring the local language for consumer-facing services.
• Articles 13 and 14. Specify what information must be provided when personal data is collected. All of that information falls under Article 12 language requirements.
• Article 22. Automated decision-making explanations must be provided in language the data subject understands.
• Data subject rights processes. The right to access, rectify, erase, and port data must be exercisable in a language the data subject can operate in. This includes any web forms, email templates, and status updates.

The result is that for any data subject in Germany, your privacy notice, consent language, data subject request flows, and any communication about their data must be available in German. The same rule applies for every other EU country.

What does the Digital Services Act add?

The DSA, in force since 2024, adds a distinct set of obligations that scale with platform size but apply in some form to any online service.

• Terms and conditions must be in the languages of the member states where the service is offered. Not just English with a translation available. The default T&C for a French user should be French.
• Notices to users about content moderation, illegal content, or account restrictions must be in a language the user understands. In practice, this means the user's declared language or the language of the interface.
• Transparency reports for very large platforms must include data broken down by language and member state. This requires you to be able to report on which strings shipped in which locales.
• Contact points for authorities must accept communication in an official language of each member state. This is an operational obligation, not just a linguistic one.

The DSA is enforced actively. Non-compliance is not just theoretical.

What does Quebec Bill 96 require?

Bill 96, in force since 2022 with escalating enforcement, is the strongest French-language obligation in North America.

• Products and services offered in Quebec must be available in French, and French must be equal to or predominant over other languages.
• Consumer contracts must be provided in French unless the consumer explicitly consents to another language after being offered the French version.
• Software and mobile apps must have a French-language version available on the same commercial terms as any other language version.
• Marketing communications in Quebec must be in French, with any other language of equal or lesser prominence.
• Registration requirements for businesses with more than 25 employees include a francization process.

The fines have teeth. Enforcement has ramped up since 2023, and B2B SaaS is not exempt.

What strings actually need to be localized for compliance?

Not every string. But more than most teams assume. The categories that must be covered:

The strings most commonly missed are the ones that feel technical: error messages that reveal data handling, transactional emails triggered by data operations, and third-party consent banners loaded from external scripts.

How do you build an audit trail?

The audit trail is the difference between compliant and technically compliant. You need to answer three questions for any given string in any given locale:

1. What is the current version, and what did it say last week, last quarter, and last year?
2. When was this version approved for the target locale, and by whom?
3. When did it ship to production for users in the target jurisdiction?

A repo-native pipeline answers all three from git history plus the translation service's audit log. Every string change is a commit. Every translation approval is a timestamped event with a named reviewer. Every production deploy is a versioned release.

A spreadsheet workflow cannot answer any of the three reliably. Spreadsheets do not preserve history. Reviewer identity gets lost when files change hands. Production deploy timing is disconnected from the translation event.

Who owns the compliance sweep?

The obligation is legal's. The execution is engineering's and localization's. The typical operating model:

• Legal identifies the string categories in scope for each jurisdiction. This is a document that gets updated when regulations change.
• Localization or i18n leads maintain the mapping from string categories to actual repo paths and file locations. So "privacy notice" is a specific route in a specific file, not a vague concept.
• Engineering owns the pipeline that ensures those strings ship in the required locales. With CI checks that fail if a compliance-tagged string is not present in a required locale.
• A quarterly compliance sweep runs the audit report and surfaces any gaps. Legal reviews. Gaps close within 30 days.

The mistake is treating compliance as a legal-only conversation. Legal cannot enforce what localization does not know about, and localization cannot cover what engineering has not tagged.

What are the operational patterns that work?

Three patterns hold up under real audit pressure.

• Compliance tags on strings. Every string that has a compliance obligation gets a tag in the source file: #compliance:gdpr, #compliance:dsa, #compliance:bill96. CI enforces coverage rules based on tags.
• Locked release process for compliance strings. Changes to compliance-tagged strings require an additional legal review beyond the standard translation review. The pipeline enforces this.
• Quarterly audit report generation. A scheduled job runs every quarter, produces a report of every compliance-tagged string in every required locale with its current version, last approval date, and reviewer. Legal signs off.

The tag-driven approach is scalable. You do not have to remember which strings are compliance-relevant. The tag makes it a data question.

The mistake to avoid

Most teams treat compliance localization as a translation project. Get the strings translated, get legal to approve, ship, done. The mistake is treating it as a one-time event rather than an ongoing obligation. Regulations change. Strings drift. New features add new compliance surfaces. Without an audit trail and a repeatable process, you are always one product change or one regulatory update away from a gap. Build the pipeline to enforce compliance continuously, and the audit is a report you run, not a project you scramble to complete. That is the only version that survives contact with actual enforcement.