Sunrise 2027 in Canada
One printed code, two official languages, and a resolver that has to choose between them. The language decision is the part of GS1 Digital Link that Canadian brands have to get right, and almost nobody writes about it.
GS1 Digital Link is a way of writing a product identifier as a web address. The same symbol on a package can hand a GTIN to a checkout system and open a web page on a shopper's phone. Behind that address sits a resolver: the service that receives the request and decides what to return.
That mechanism is explained well in a lot of places, including QRbolt's explainer, which walks through the URI structure in detail. There is no reason to write it a second time here. If the terms in this page are unfamiliar, the glossary has short definitions, and the Sunrise 2027 overview covers what Sunrise 2027 is and is not.
This page is about the part that guidance written for single-language markets leaves out entirely. In Canada, a resolver is not only deciding which page to return. It is deciding which language to return it in. That decision pulls in obligations that have nothing to do with barcodes, and it is made hundreds of times a day by a system most brand teams never look at.
A printed symbol encodes one address. That is not a limitation of the standard, it is a property of ink. You cannot print a code that leads a francophone shopper to a French page and an anglophone shopper to an English one, because the shopper is not part of what gets printed.
The split therefore has to happen after the scan. Whatever else your packaging team decides, the resolver and the page behind it are the only places where two languages can come out of one symbol. This is worth stating plainly because the opposite assumption keeps surfacing in artwork reviews: someone proposes two codes, one per language, and the idea has to be walked back. Two codes means two identifiers or two destinations for one product, more panel space consumed rather than less, and a shopper who has to work out which square is meant for them.
There is a reason this lands harder here than elsewhere. Canadian packaging already carries English and French, so the panel is already crowded before anyone adds a 2D code. That crowding is exactly why the scannable code is attractive: it moves detail off a surface that has run out of room. But moving information off the panel moves it into a system that now has to make the language choice correctly, every time, for a person who cannot see how the choice was made and has no way to tell you it was wrong.
This part is for the people who implement the destination, and the short version for everyone else is one sentence: pick a default from the browser language setting, then put a visible language switch on the page, because the automatic guess will be wrong often enough to matter.
When a phone opens the URL, the browser sends an Accept-Language header. It carries the language tags the device is configured to prefer, in order, sometimes with weightings. On a Canadian device you might see fr-CA first, or en-CA, or a generic fr or en, or a longer list that includes both.
That header is the honest starting point for a default. It is also unreliable in ways that matter:
fr alone does not tell you whether you should be serving Quebec French or European French. Those are not the same thing for a Canadian label.So the header is a reasonable default and a poor decision-maker. Treat it as a first guess that you expect to be wrong a meaningful share of the time.
Automatic detection has a structural flaw: it is invisible and it has no feedback loop. The shopper cannot see what was decided, cannot tell you it was wrong, and in most implementations cannot correct it without hunting.
The design that holds up is unglamorous. Use the header to pick a default, then put a visible, obvious language control on the page, and remember the choice for that person. A few things make the difference between a toggle that works and one that annoys:
Accept-Language needs a Vary header, or a CDN will happily serve one shopper's language to everyone behind that cache node. This is a genuinely common failure and it fails at regional scale rather than one scan at a time.lang attribute and cross-references between the two versions are cheap, and they help both assistive technology and crawlers understand that these are two versions of one thing rather than duplicates.The standard is generally not the obstacle here, and it is worth confirming the current resolver specification directly with GS1 rather than taking any vendor's word for what it permits. The obstacle is usually that nobody specified the behaviour, so the platform's default quietly became the policy.
Here is the question that actually determines how much of this matters, and it is not a technical one.
There are two very different things a scanned page can be. It can be marketing: brand story, recipes, a campaign, provenance narrative. Or it can be carrying label content: ingredients, allergens, net quantity, instructions for use, warnings, nutrition information, claims about the product.
Those attract different expectations. Mandatory label information on prepackaged consumer products in Canada is already subject to bilingual requirements under federal packaging, labelling and food regulation. Promotional material is governed differently. If the page behind your code is functioning as label content, the sensible working assumption is that it inherits the expectations attached to label content rather than the looser ones attached to a brochure.
The genuinely unsettled part is where the boundary falls for a page a consumer reaches by scanning. Is it part of the label, a document accompanying the product, or a commercial publication? The answer plausibly depends on what the page contains, whether the packaging directs the shopper there for required information, and what is or is not still printed on the panel. I am not going to give you a bright line, because I do not think there is one that I could defend.
It is an editorial summary written for packaging and brand teams so they know which questions to raise. Whether any specific obligation applies to your product, your page and your market is a fact-specific legal question. Get advice from qualified Canadian counsel, and from Quebec counsel specifically if you sell in Quebec.
What follows from the uncertainty is a governance point, not a legal one. Once label-like content lives on a page, anyone who can edit that page can change label content without a print run, without artwork review, and without anyone in regulatory noticing. If the scanned destination is going to carry that kind of content, it needs the change control that artwork already has: versioning, an approval step, and a record of what was live on a given date.
Quebec's Charter of the French Language is the piece of this that Canadian brands most often discover late.
At a level I am comfortable stating: the Charter requires French on inscriptions on a product and on documents supplied with it, and where another language also appears, French is not to be given less prominence. It also addresses commercial publications and material a business makes available to the public, and the expectation in practice has been that a business operating in Quebec does not offer a French experience that is thinner or harder to reach than its English one. Amendments in recent years, commonly referred to as Bill 96, strengthened the regime and changed the enforcement posture around it.
Whether a page reached by scanning a code on the pack is an inscription, an accompanying document, a commercial publication, or something the Charter did not contemplate, is exactly the kind of question where I would not trust a confident answer from a vendor, including a confident answer that it does not apply. Ask counsel. Put the question precisely: not “can we use a QR code”, but “if this specific content moves from the panel to the scanned page, what changes about our obligations in Quebec”.
There is a design posture that is defensible regardless of how that question resolves, and it is the one I would recommend on customer experience grounds even if no statute existed. Make the French version complete, not a reduced subset of the English one. Make it reachable in no more steps. Have it translated for Quebec rather than adapted from European French, which reads as foreign in ways that matter for a market that notices. A brand whose French page is equal in substance and equally easy to reach is not the brand that ends up explaining itself.
Scan logging is on by default in many platforms in this space, and the log is more interesting than people assume. A scan event can carry an IP address, an approximate location derived from it, a device and browser fingerprint, a timestamp, the product scanned, and frequently an identifier that persists across scans.
Depending on what is collected and how identifiable it is, that may be personal information. Which statute applies depends on where you operate and who you are: PIPEDA federally, Quebec's private sector privacy legislation as amended by Law 25, and the provincial private sector statutes in Alberta and British Columbia. Health-adjacent products can bring other regimes into play again.
On Law 25 specifically, at a level of generality I can stand behind: it modernised Quebec's private sector privacy law in phases, tightened transparency and consent expectations, introduced breach reporting and a designated person responsible for privacy, and added an assessment obligation around information that flows outside Quebec. It also addresses technology that can identify, locate or profile a person, requiring a business to inform the person that the technology is in use and of the means available to activate those functions. The practical reading is that identification, location and profiling are expected to be inactive unless the person activates them, which is a stricter default than providing an opt out. Whether any of that attaches to your particular scan logging depends on what you actually collect. Confirm it with counsel rather than with a vendor datasheet.
Two things are worth saying bluntly. First, nobody is “fully compliant with PIPEDA” in any certified sense. There is no certification or attestation scheme behind that phrase, so treat it as marketing wherever you see it. Second, the most effective privacy measure available here is usually a product decision rather than a legal one: decide whether you need per-scan identity at all. There is a large difference between knowing a product was scanned twelve thousand times last month and knowing that one device scanned these five products in this order. The first answers nearly every business question a brand actually has. The second is what creates the obligations.
And the privacy notice itself is content on the page. If you collect anything at the destination, the explanation of what you collect belongs in both languages, for the same reason the rest of the page does.
These are procurement questions, not legal ones. Crisp answers do not make anyone compliant. They are the inputs your counsel needs in order to tell you anything useful. Related questions about data residency in general are on the Canada readiness page.
Accept-Language is absent or generic?fr-CA and en-CA as distinct, stable, linkable URLs?The francophone shopper who lands on an English page. This gets dismissed as cosmetic. It is not. As customer experience it is a person told, at the moment they wanted information about what they are eating, that the brand did not plan for them. As a compliance matter it depends entirely on what was on that page, which is why the labelling question above is not academic.
Silent fallback. A missing French page that quietly serves English is worse than one that errors, because nothing surfaces it. It will be discovered by a customer or a regulator rather than by you.
The half-translated page. French headings over an English ingredient table is a common outcome when translation is scoped as a content task rather than a labelling one. The untranslated part is usually the mandatory part, because that is the content that came from a different system.
The cached language. One miscached response and an entire region gets the wrong language until the cache expires. This failure is invisible from your own devices, which are almost certainly configured correctly.
The campaign destination. A code pointed at a microsite for a campaign that ends in eight months, printed on packaging with a three year shelf life. The pack outlives the campaign, and the scan lands on nothing.
Privacy raised after launch. Scan logging is easy to turn on and awkward to unwind once analytics dashboards depend on it. The cheap moment to decide what you collect is before the first code is printed, which is also roughly when the migration guide would have you running a pilot.
The bilingual question is not really a Sunrise 2027 question. Nothing about the 2027 target requires a brand to do any of this, and nothing is expiring, a point the Sunrise 2027 overview makes at more length. The language decision matters because a scanned page is a new surface for talking to Canadian shoppers, and Canada has long standing expectations about the language that happens in.
What is different about this surface is that the decision is made by software, silently, at a moment nobody observes. A packaging error is caught in proofing. A resolver that serves the wrong language is caught by a shopper, or by nobody. That asymmetry is the argument for specifying the behaviour deliberately, writing down what should happen when the header is absent, and testing the French path as carefully as the English one. It is cheaper to decide while the artwork is still open, not because a deadline is coming, but because everything about packaging gets more expensive once it is printed.