Planned Not yet started — this page describes the intended design and build plan.
Overview
This is different from the multi-language interface already on the
roadmap, which translates Notipa's own buttons and labels. This translates the actual content of
guardian-teacher messages — the conversation the messaging feature exists for, not just the chrome
around it. A family that doesn't speak the school's working language shouldn't be shut out of the one
channel built specifically for their questions.
Messaging ships first, since it's the two-way, time-sensitive case where a language gap does the most
damage. The same translation layer can extend to announcements later.
How it will work
Preferred language, set once. Each guardian and teacher sets a preferred language on their profile.
Translated by default. A message is stored in the language it was written in, and translated automatically when delivered to a recipient with a different preferred language.
Original always available. A recipient can tap through to see the original text — nothing is silently altered without a way to check it against what was actually written.
Graceful when translation isn't available. If the translation step fails or the school hasn't configured a provider, the original message still delivers, with a note rather than a dropped message.
Development plan
1Language preference
A preferred-language field on the guardian and teacher profile, set during onboarding and editable afterward.
2Translation integration
A pluggable translation provider interface, rather than a single hardcoded vendor — a self-hosted instance can point at a free/self-hosted engine (such as LibreTranslate) or a paid API, whichever fits the school's country and budget.
Configuration lives in the same environment file already used for other self-hosting settings.
3Message pipeline
Store the original message text alongside the translated version delivered to the recipient.
A "see original" toggle in the message thread UI.
4Testing & fallback
Tests confirming messaging keeps working end-to-end if the translation provider is unreachable — a self-hosted deployment shouldn't lose messaging because a translation API is down or blocked.
Tests confirming the original text is always retrievable, for both parties, indefinitely.
Technical considerations
Provider-agnostic design matters for a self-hosted project — a school in a country where a particular translation API is blocked, expensive, or unavailable needs a working alternative, not a hard dependency.
Keeping the original text alongside every translation preserves an accurate record, consistent with Notipa's existing audit-trail-minded features like read tracking and response rosters.
This is a larger lift than UI translation and depends on guardian-teacher messaging, which has already shipped.