Part of a series on what a district owns and what a family owns inside Bloomz — see what a district authors and what a school measures.
Every school communication platform asks, somewhere in onboarding, what language a family speaks. A dropdown, a pick-list, sometimes a browser guess a parent never confirms. Once the answer is in, the platform treats it as settled. Messages go out in that language. The box is checked.
The question underneath that one goes mostly unasked: who actually gets to answer it, and does the answer mean the same thing everywhere it’s used? Those turn out to be two separate problems, and most platforms quietly collapse them into one setting. That’s how a family ends up “translated for” on paper and locked out of the thing they actually needed to read.
Why a family’s language setting drifts
Picture the normal way a language preference gets set. A parent downloads the app during the first week of school and picks a language somewhere around screen four of onboarding. Or a front-office staff member sits a parent down at the check-in desk and sets it for them because it’s faster than walking through the picker together. Either way, a value gets written once, by whoever happened to be doing the setup that day, and then nothing touches it again.
Meanwhile the district has its own record. At registration, the family told the district — on a paper form, at an enrollment kiosk, through whatever intake process the front office runs — what language they wanted to be communicated in. That answer lives in the student information system, it’s the one the district is accountable for, and it can be different from what a parent tapped six months later trying to get through an onboarding flow as fast as possible. Nothing keeps the two in sync. The SIS doesn’t watch the app’s setting, and the app’s setting doesn’t watch the SIS. They just drift apart quietly, until a family says they never got a message they were owed.
Content and interface are not the same promise
Bloomz has always kept two language settings that look similar but aren’t: content language, what the school’s messages, posts, and announcements are delivered in, and app language, what the interface itself speaks — menus, buttons, labels, navigation.
A family can legitimately want these set differently. A parent who’s used the app for years might navigate an English interface comfortably — they know where the calendar tab is — while still wanting the school nurse’s message about their child’s health form to arrive in Vietnamese, because that’s the language they process something important in. The reverse happens too: a parent who reads a Spanish-language interface easily might not mind an English announcement about a bake sale, because getting that one slightly wrong costs nothing. Both combinations are normal. Neither is a misconfiguration to fix.
That distinction changes what the earlier drift actually costs. Getting the interface wrong is friction — icons are recognizable, layout is familiar, and worst case a parent taps the wrong thing once and corrects it. Getting the content wrong is a different order of problem: if the language a family is communicated in doesn’t match the language they read, they can miss an attendance notice, misunderstand a health alert, or fail to return a form they were required to send back — not from inattention, but because the words in front of them weren’t in a language they process. We’ve written elsewhere about the gap between translating a message and translating the whole app; that post is about how far a translation reaches. This one is about who has the authority to set the language in the first place, and whether that authority should be the same for both settings.
Why “let the SIS decide everything” is the wrong fix
The tempting fix, once you notice the drift, is to make the SIS authoritative across the board and be done with it — the district already collects the family’s language at registration, so let that value flow through to everything, every time.
The problem is what that takes away. A parent who set their app to English because that’s how they learned it — a teenager set it up for them, say, even though they read Spanish for everything else — would have that choice reset nightly by a sync they can’t see and didn’t ask for. It solves the district’s accountability problem by removing the one language setting a family has genuine, ongoing authority over: how the software looks to them, every day they use it. That’s a bad trade. The district is accountable for what it says to a family. It shouldn’t also be deciding what a parent’s own phone looks like.
The split that actually works
State it plainly: the system of record owns what the school says to you. The person owns what the software looks like to them.
Content language is a district accountability, tied to the language-access obligations a district carries and sourced from information the family gave the district directly — it should track that source of truth reliably, refreshed on a schedule rather than left to whoever set it up once. App language is a personal preference with no accountability attached to it at all; locking it defeats the entire point of it being a preference. Treating those as one setting is the mistake. Treating them as two, owned by two different parties, is what actually holds up.
What this looks like as a control
This split is now something a district can actually enforce rather than just aspire to. In Settings → Bulk Import → General Permissions, there’s a toggle: “Let your student information system overwrite a user’s preferred language.” It’s off by default, so a district that doesn’t touch it sees no change in behavior at all.
Turned on, the nightly SIS sync becomes authoritative for content language only — the language the family gave the district at registration becomes the language the school communicates in, refreshed automatically instead of drifting further from the source of truth every week it goes untouched. App language is never part of that lock; it stays the user’s own choice under every circumstance, including when the toggle is on. A family opening their language settings with the lock active sees the content-language picker as read-only, with an explanation of why, right next to an app-language picker they can still change freely.
It sits beside a setting districts will already recognize: “Let your student information system overwrite a guardian’s email & phone number.” Same location, same logic — the SIS is the system of record for the contact details a district is accountable for, and the toggle decides whether it’s treated that way. Language now gets the same treatment, deliberately framed as a statement about which system is authoritative rather than a permission being granted, because that’s what it actually is.
When to use it
Turn it on when your SIS language field is genuinely maintained — populated at registration, kept current, not a stale value nobody has looked at since a system migration — and your district is the party accountable for getting that language right. Leave it off if the field is a mess: unpopulated for a chunk of your families, free text with no standardization, or not something your registration process reliably captures. A dirty source of truth locked onto every family’s content language is worse than the drift it’s meant to fix.
The setting is per-school as well as district-wide, so a district with one building on a clean SIS feed and another still catching up doesn’t have to choose one answer for both — it can reflect where the data actually is, building by building, same as a district’s other authored settings already do.
The principle, not the feature
The interesting question was never “what language does this family speak.” Every platform asks that one. The interesting question is who gets to answer it — and whether that answer means the same thing whether it’s shaping a message or shaping a menu. A district earns the authority to answer for a family’s content language because it’s the party accountable for getting that message understood. Nobody earns the authority to answer for how a person’s own screen looks to them. Keeping those separate, deliberately, is the whole design.