Planned Not yet started — this page describes the intended design and build plan.
Overview
Notipa's interface is English-only today. Since it's meant to run anywhere a school, NGO, or ministry of
education wants to self-host it, the UI chrome — buttons, labels, navigation, form fields, system
messages — needs to be translatable, and a user needs to be able to pick their own language independent
of everyone else using the same instance.
This is UI translation, not content translation: it makes the app itself usable in another language. It
does not translate the actual text a teacher writes in an announcement or homework post — that content
stays in whatever language the author wrote it in, same as any other software.
How it will work
Per-user language preference. Each account — teacher, guardian, or admin — sets their own interface language, stored on their profile, so a bilingual school's staff and families can each use the language they're most comfortable with on the same instance.
Translation files, not hard-coded strings. Every UI string in the app is extracted into translation files, using Django's standard internationalization framework, so new languages can be added by translating a file rather than editing code.
Right-to-left support considered from the start. Layout is checked against RTL languages (e.g. Arabic, Urdu) even in the first release, since retrofitting RTL support later is far more expensive than building for it up front.
Community-contributable. Since Notipa is open source, translation files are structured so a school or contributor can add a new language and submit it back, without needing to touch application logic.
Development plan
1String extraction & i18n scaffolding
Audit every template and UI-facing string in the Django app and wrap them with Django's translation tags ({% trans %} / gettext).
Set up the standard Django locale directory structure and message-file (.po/.mo) build process.
Add a language field to the user profile model, defaulting to the system/browser locale on first login.
2First translations
Ship with a small initial set of fully translated languages (candidates: Filipino/Tagalog, given the project's Philippines base, plus one or two widely-requested languages) as a proof that the pipeline works end to end.
RTL layout pass using one RTL language as a real test case, not just a checkbox.
3UI — language switcher
Language picker in account settings, applying immediately without requiring a logout.
Fallback behavior: any string missing from a translation file falls back to English rather than showing a raw translation key.
4Contribution workflow & testing
Document the process for adding a new language in the repository, so community contributors can submit translation files via pull request.
Visual regression pass across the app in each shipped language to catch overflow/truncation from longer translated strings.
QA the RTL layout specifically — form alignment, icon direction, navigation order.
Technical considerations
Uses Django's built-in i18n framework rather than a third-party translation service, keeping the self-hosted footprint dependency-light.
Per-user (not per-school) language selection, since a single self-hosted instance may serve a genuinely multilingual staff and family base.
Content authored by users (announcements, homework text, messages) is explicitly out of scope for automatic translation — machine-translating parent-facing content raises accuracy concerns better left to a future, separate feature if ever pursued.