DEV Community: MeetAndPlay

Building a free embeddable widget that earns attribution honestly: iframe + credit line design

MeetAndPlay — Thu, 05 Nov 2026 23:56:15 +0000

We ship small embeddable widgets (a club availability view, a court-cost calculator, a data chart) that other sites can put on a page. This post is about the design decisions: how the iframe is locked down, how it resizes without hand-tuning, and how the credit line is built so the attribution is visible, optional to remove, and not a trick.

Two pieces: a loader and an embed route

The host page adds a script and a placeholder:

<script src="https://meetandplay.mx/embed.js" async></script>
<div data-meetandplay-club="club-slug"></div>

The script finds each placeholder, builds an iframe pointing at a dedicated /embed/... route on our domain, and inserts it. Options come from data-* attributes (data-locale, data-accent, data-bg, data-sport) and every one is re-validated in the loader and again on the server, since a data attribute is user input:

const HEX = /^(?:[0-9a-f]{3}|[0-9a-f]{6})$/i;
const LOCALE = /^[a-z]{2,3}(?:-[A-Za-z0-9]{2,8})?$/;

function buildSrc(host, slug) {
  const params = new URLSearchParams();
  const accent = (host.getAttribute("data-accent") || "").replace("#", "");
  if (HEX.test(accent)) params.set("accent", accent.toLowerCase());
  const locale = host.getAttribute("data-locale") || "es-MX";
  const safe = LOCALE.test(locale) ? locale : "es-MX";
  return `${origin}/embed/${safe}/club/${encodeURIComponent(slug)}?${params}`;
}

Make only the embed routes frameable

The easy mistake is to relax framing for the whole site. Instead, everything except /embed/* gets X-Frame-Options: SAMEORIGIN and frame-ancestors 'self', and the embed group replaces the CSP with one that allows any ancestor. In Next.js that is two header rules:

export const EMBED_SOURCE = "/embed/:path*";
// every path that is NOT under /embed
export const FRAME_GUARD_SOURCE = "/:path((?!embed(?:/|$)).*)";

X-Frame-Options has no "allow all" value, so you cannot override it away on the embed routes; they must be excluded from the group that sets it. Allowing any ancestor is only reasonable because the widget holds nothing worth clickjacking: it shows public data, has no login or payment form, and links open the full app in a new tab (target="_blank" with rel="noopener").

We also send X-Robots-Tag: noindex, nofollow on the embed routes. The framed page is a fragment of someone else's page, not a result in its own right.

Auto-resizing with postMessage

Hand-tuned iframe heights break the moment content changes. The embed page reports its height; the loader applies it:

// inside the embed page
useEffect(() => {
  if (window.parent === window) return;
  const post = () =>
    window.parent.postMessage(
      { type: "meetandplay:height", height: document.documentElement.scrollHeight },
      "*"
    );
  post();
  const ro = new ResizeObserver(post);
  ro.observe(document.documentElement);
  return () => ro.disconnect();
}, []);

// in the loader
window.addEventListener("message", (event) => {
  if (event.origin !== origin) return;               // only our origin
  if (event.data?.type !== "meetandplay:height") return;
  const h = Number(event.data.height);
  if (!Number.isFinite(h)) return;
  const clamped = Math.min(4000, Math.max(200, Math.ceil(h)));
  for (const frame of frames)
    if (frame.contentWindow === event.source)        // only frames we created
      frame.style.height = `${clamped}px`;
});

Two details: the target origin "*" on the sender is acceptable because the payload is one number about a public page, and the receiver checks both event.origin and that event.source is one of its own frames, then clamps the value so a spoofed message cannot make the host layout absurd.

The credit line

An embed that gives the host something useful can reasonably ask for a credit. Rules we set ourselves:

Visible. A normal caption under the widget, not hidden, not tiny, not off-screen.
Brand-only anchor text. The link text is the product name, not a keyword phrase. Keyword-stuffed anchors are exactly what makes embed credits look like link schemes.
A plain link. It is a normal link with a utm_source parameter, so the target site can see where visits come from. No cloaking, no redirects.
Where it lives. The snippet we give people includes the credit inside the placeholder div. The loader inserts the iframe above existing content, so the line reads as a caption:

// host.insertBefore(frame, host.firstChild)

<div data-meetandplay-club="club-slug">
  <p><a href="https://meetandplay.mx/?utm_source=embed">MeetAndPlay</a></p>
</div>

A side benefit of this design: with JavaScript disabled or the script blocked, the placeholder still renders a useful link rather than an empty box.

Things I would check before copying this

Don't put anything stateful in a frameable route. Login, payments, forms with side effects: keep them out and open the main app in a new tab.
Keep the loader dependency-free and wrapped in an IIFE so it leaks no globals onto the host page.
Clamp every number you accept from postMessage.
Be willing to be ignored. If someone removes the credit, the widget should still work. Attribution that has to be forced is not worth having.

The pattern is small enough to reuse for any read-only widget. If you want to see it in action, the club availability widget from MeetAndPlay uses exactly this loader.

Scheduling a padel americana: a rotation algorithm that lets everyone partner everyone

MeetAndPlay — Thu, 05 Nov 2026 23:55:59 +0000

An americana is a padel social format: a group of players turns up, and for each round the pairs change so that you play with as many different people as possible. The scheduling problem sounds trivial until you try it with 7 players and 2 courts. This post walks through the algorithm we use in a TypeScript domain package, what it guarantees, and where it deliberately does not.

The core idea: partners come from the circle method

Round-robin tournaments use the "circle method": pin one slot, rotate the others one seat per round, and pair each slot with the one opposite. For an even number m of slots, over m - 1 rounds every unordered pair appears exactly once.

An americana needs the same property, but applied to partners instead of opponents. If the pairs from each round are used as that round's partnerships, then across a full rotation every player partners every other player exactly once. That is a 1-factorization of the complete graph, and it gives the main guarantee of the format for free.

type Slot = string | null;

// Pin slot 0, rotate the rest by (round - 1) places.
function rotate(slots: Slot[], round: number): Slot[] {
  const [pinned, ...rest] = slots;
  if (pinned === undefined || rest.length === 0) return [...slots];
  const period = rest.length;
  const shift = (((round - 1) % period) + period) % period;
  const cut = period - shift;
  return [pinned, ...rest.slice(cut), ...rest.slice(0, cut)];
}

function rotationPairs(slots: Slot[], round: number): [Slot, Slot][] {
  const ordered = rotate(slots, round);
  const half = ordered.length / 2;
  const front = ordered.slice(0, half);
  const back = ordered.slice(half).reverse();
  return front.map((slot, i) => [slot, back[i]] as [Slot, Slot]);
}

Calling rotationPairs for rounds 1..n-1 with 8 players gives 7 rounds of 4 partnerships each, 28 distinct pairs in total, which is every pair of 8 players.

Odd counts: pad with a bye, and pad in the pinned seat

With an odd number of players you add a null slot so the rotation has an even size. Where you put it matters. The pinned slot's opposite partner changes every round, so putting the null in the pinned position makes the sit-out walk through every real player in turn. Put it anywhere else and the pinned player sits out every single round.

const padToEven = (ids: string[]): Slot[] =>
  ids.length % 2 === 0 ? [...ids] : [null, ...ids];

// A partnership that contains null is a bye for the other player.
function partnerships(ids: string[], round: number) {
  const pairs: [string, string][] = [];
  const sittingOut: string[] = [];
  for (const [a, b] of rotationPairs(padToEven(ids), round)) {
    if (a !== null && b !== null) pairs.push([a, b]);
    else sittingOut.push((a ?? b) as string);
  }
  return { pairs, sittingOut };
}

The rotation length is therefore n - 1 for even n and n for odd n (the padded field has n + 1 slots). After that the schedule wraps and round k + length repeats round k.

const rotationLength = (n: number) =>
  n < 2 ? (n === 1 ? 1 : 0) : n % 2 === 0 ? n - 1 : n;

Courts: fewer courts than pairs

Pairs are not matches. Two pairs make a match, so 8 players give 4 pairs and 2 matches. If the venue only has 1 court, one match is played and the other two pairs rest.

A pair rests as a unit, so we pick which ones by accumulated bye load: the pairs whose members have sat out the fewest rounds rest next. A seeded random value breaks ties so the same low-index pair is not chosen every round.

function splitByCourts(
  pairs: [string, string][],
  byeLoad: Map<string, number>,
  courts: number,
  rng: () => number
) {
  const pooled = pairs.map((pair) => ({ pair, tie: rng() }));
  const playingCount = Math.min(Math.floor(pairs.length / 2), courts) * 2;
  const restCount = pairs.length - playingCount;
  if (restCount <= 0) return { playing: pooled, resting: [] };

  const ranked = pooled
    .map((p, index) => ({
      index,
      load: (byeLoad.get(p.pair[0]) ?? 0) + (byeLoad.get(p.pair[1]) ?? 0),
      tie: p.tie,
    }))
    .sort((a, b) => a.load - b.load || a.tie - b.tie);

  const resting = new Set(ranked.slice(0, restCount).map((r) => r.index));
  return {
    playing: pooled.filter((_, i) => !resting.has(i)),
    resting: pooled.filter((_, i) => resting.has(i)).map((p) => p.pair),
  };
}

Note the honest consequence: because pairs rest together, byes are balanced greedily but not exactly. In our implementation a field of 7 over a full rotation ends up between 2 and 4 byes per player rather than 3 each. Making it exact needs lookahead over the whole schedule and costs partner diversity, which is the thing the format exists for.

Opponents: greedy, and honest about it

Partners are fixed by the rotation. Who plays whom is a second, softer problem. We match the round's partnerships onto courts greedily: take the first pair, then choose the remaining pair whose four players have met the fewest times so far.

const pairKey = (a: string, b: string) => (a < b ? `${a}|${b}` : `${b}|${a}`);

function meetingCost(
  home: [string, string],
  away: [string, string],
  meetings: Map<string, number>
) {
  let cost = 0;
  for (const a of home)
    for (const b of away) cost += meetings.get(pairKey(a, b)) ?? 0;
  return cost;
}

This is not optimal, because committing pair by pair can strand a repeat for the last court. Measured on our implementation, a full 8-player rotation covers 26 of the 28 possible opponent pairings, and a 12-player one covers 62 of 66. A schedule where everyone meets everyone equally often as partner and as opponent only exists for particular n, so we do not promise it.

Determinism

The round is a pure function of (playerIds, roundNumber, seed, previousRounds): no clock and no Math.random. That means you can regenerate round 4 on its own, print the same sheet twice, or replay a disputed night. Stats are then just counting:

function maxPartnerRepeats(rounds: { fixtures: { sideA: string[]; sideB: string[] }[] }[]) {
  const seen = new Map<string, number>();
  for (const r of rounds)
    for (const f of r.fixtures)
      for (const side of [f.sideA, f.sideB])
        if (side.length === 2) {
          const k = pairKey(side[0], side[1]);
          seen.set(k, (seen.get(k) ?? 0) + 1);
        }
  return Math.max(0, ...seen.values());
}

Within one full rotation this returns 1.

When the field changes mid-event

The circle-method guarantee assumes a fixed set of players. A late arrival or an early leaver breaks it. We detect that by comparing the players named in earlier rounds with the current list. If any earlier round was drawn for a different field, we switch to a greedy repair: lowest bye count rests, and partnerships are built by minimising repeats against the partner history. It does not restore the exactly-once guarantee, but it avoids repeats a repeat-free pairing could avoid. One bug worth knowing about: our first version switched back to the circle method as soon as the field looked complete again, which re-paired people who had already partnered earlier in the night. Staying on the repair for the rest of the event fixed it.

What this does not do

No level balancing: the rotation reads no ratings. If you want matched teams, you need a different pairing mode.
No moving winners up courts. That is the mexicano format, which depends on results.
Doubles only. A singles "americana" is just a round robin.

Try it without writing code

If you just need a sheet for tonight, we put this algorithm behind a free tool: the americana generator takes a player list and number of courts and prints the rounds.

Building a nationwide court directory for Mexico from OpenStreetMap

MeetAndPlay — Thu, 05 Nov 2026 17:57:44 +0000

We needed a list of every place to play padel, tennis and pickleball in Mexico. Nobody sells a good one, so we built it from OpenStreetMap, and learned that an open map is a mirror of the people who edited it.

MeetAndPlay is a padel, tennis and pickleball app that launches in Cancún on 1 December 2026. An app that helps people find a game needs to know where the courts are, in a country with 32 states and a lot of places that never made it into a booking platform. We built a nationwide directory, the court directory at meetandplay.mx/canchas, on top of OpenStreetMap. This post covers the pipeline, the licence, and the quality problems we found, with the real numbers from our latest snapshot.

Why OpenStreetMap

The alternatives were scraping a booking marketplace, buying a commercial POI dataset, or using a map provider's places API. We rejected each for a different reason: terms of service, price, and licences that forbid storing and re-publishing the data. OpenStreetMap is the only source that lets you pull the data, keep it, build pages from it, and re-publish what you derive, provided you follow the Open Database Licence (ODbL 1.0) and credit contributors.

The pipeline

The pipeline is a plain script, run by hand when we want a refresh. There is no scheduler and no live dependency on the Overpass API at request time.

Pull. Query the Overpass API for features tagged with a racket sport (sport=tennis, sport=padel, sport=pickleball). Our latest pull has the snapshot timestamp 2026-09-25T20:14:17Z. The timestamp travels with the data, so every page and every number can say how old it is.
Filter. The most important step. Tennis courts are everywhere in OSM: schools, universities, apartment complexes. We keep facilities that make sense as a place to play and exclude school and university campuses. One filter function is shared by every consumer, because two copies of "what counts as a venue" drift apart within a week.
Locate. Assign each place to a state and municipality from OSM's administrative boundaries, matched against INEGI's municipality list. Reverse-geocode a colonia and street with Nominatim, because an OSM point alone is not an address. Compute the distance to a coastline from Natural Earth, which turns out to be useful on a beach-heavy market.
Sanitize. OSM contact tags are free text edited by anyone. A "website" value can be a javascript: URL; a "phone" can have no digits. We drop anything that cannot be a safe link at build time, and the render layer checks again.
Aggregate. Write state and city indexes as generated TypeScript modules. Static data means no database call to render a directory page.

The rule that guided everything: no invented data. If OSM has no name for a place, the page gets no name. We label it from its sport and colonia at render time instead of guessing. That sounds like a small thing and it prevents the whole class of bug where an app confidently shows a made-up club.

What the snapshot says

Counting everything in the snapshot, OSM has 1,052 places across all 32 states and 255 cities, carrying a total of 2,307 courts. Only 354 places have a name, a third of the total.

Per sport, counted as places carrying that sport tag:

Sport	Places in OSM
Tennis	1,005
Padel	51
Pickleball	14

A caution that cost us an embarrassing correction in draft: OSM counts places per sport, not courts per sport. A club with a padel court and two tennis courts is one place in the padel column and one in the tennis column. So our tables say "places with padel", never "padel courts". The 2,307 courts figure is the total across every sport and cannot be split.

Two results made us rethink the directory:

Padel is almost invisible on the open map. 51 places in the whole country is far below what the sport's own federation says exists. The International Padel Federation published, in March 2025, "more than 630 clubs" and 2,300 courts for Mexico. Those are their figures, from their research department, and we label them directional: we cannot audit them and we do not divide one number by the other. But the gap exists, and it is the finding.
Cancún looks like a tennis town on OSM. The map has 35 places and 58 courts in Cancún, all of them tagged tennis, none tagged padel, and none with a name. A city where padel is the headline sport has no padel in OSM. By state, the places with padel are concentrated where a few mappers care: Yucatán 8, Sonora 7, Coahuila 6, Jalisco 5. Quintana Roo, which has 71 places, has 0.

An open map reflects who edits it. That is the lesson to carry to any OSM-derived project: your coverage is a coverage of mappers, not of the world.

The licence, in practice

I am not a lawyer and this is not legal advice, but here is how we handled ODbL, which is the thing people get wrong.

Attribution on every page that uses the data, as "© OpenStreetMap contributors", linked to the licence. No exceptions for a footer you can't see.
Share-alike applies to derived databases. Anything we publish as data (our per-state CSV, our dataset markup) is offered under ODbL with the same credit.
Keep the licensed data separate from data that isn't. We also research venues by hand from public sources, each row citing its source URL. Those rows are not OSM's and are not ODbL. If we merged them into the same published dataset, we would either relicense them or contaminate the OSM-derived release. So the published report and CSV read only the OSM-derived modules. The directory's own totals, which also count the hand-researched venues, never appear in the ODbL-labelled outputs. In code this is the difference between two exported objects, and a comment in the module saying not to mix them.

Publishing the result

Because the dataset is ODbL, we put it out as a report with a downloadable CSV: per-state places, courts, and places per sport, plus the methodology and the caveats above. The CSV has Spanish snake_case column names and is served from a path with a dot in it on purpose, so our locale-rewriting middleware leaves it alone and it is the same in every language.

All numbers on the page are derived from the same module that builds the CSV. We never type a figure by hand. If we re-pull OSM, the page, the file and the structured data move together.

Quality problems you will hit

Duplicates. The same club mapped as a point, a polygon and a relation. Dedupe by proximity and name, not by ID.
Wrong sport tags. A tennis court re-lined for pickleball keeps the tennis tag. Do not infer sport counts beyond what is tagged.
Closed and abandoned places. OSM has lifecycle prefixes, and not everyone uses them. We say clearly that the directory is what mappers recorded, not what any club verified.
Municipality edges. Border points flip between adjacent municipalities in different data vintages.

What we would tell you to do

Version your snapshot and print its timestamp wherever a number appears.
Decide what counts as a venue once, in one function.
Never mix licences in one published file.
Treat a gap between OSM and an outside source as a feature of your report, not a bug in your pipeline. That is also an invitation: if you play in Cancún and you know where the padel courts are, adding them to OpenStreetMap makes the map better for everyone, not just us.

If you want to poke at the data, the CSV is public, the code is in the canchas-mexico repo on GitHub, and we would like to hear what you build from it.

Data © OpenStreetMap contributors, ODbL 1.0. Snapshot 2026-09-25T20:14:17Z. External figure: FIP, "Focus en… México", 11 March 2025.

Shipping a sports app in Nahuatl, Maya, Tzeltal and Tzotzil: i18n lessons from 60 locales

MeetAndPlay — Thu, 05 Nov 2026 17:56:35 +0000

We build MeetAndPlay, a padel, tennis and pickleball matchmaking and court-booking app that launches in Cancún on 1 December 2026. Here is what we learned adding indigenous Mexican languages to a Next.js app, including the parts that are still unfinished.

When we started, the plan was ordinary: Spanish first, English for tourists, a handful of European languages for the people who fly into Cancún. Then a directive changed the scope: support every language that is actually popular in Mexico. Taken literally, that does not mean French and Dutch. It means Nahuatl, Yucatec Maya, Tzeltal, Tzotzil and a long tail after them.

The locale list started smaller and has grown to 60 tags today, so treat any number in this post as a moving target. This post is about the engineering and the judgment calls, written for anyone who has to ship a language that your tooling does not know exists. It is also about what we have not done, because that is the part most i18n posts skip.

If you want to see the result, the MeetAndPlay site has a language switcher where the indigenous languages sit in their own group.

Why these languages at all

The criterion we ended up with is demographic, and it comes from Mexico's statistics institute. INEGI's 2020 census counted 7,364,645 people aged three and over who speak an indigenous language, across 68 languages. About 866,000 of them (11.8%) do not speak Spanish. Nahuatl has 1,651,958 speakers, Maya (Yucatec) 774,755, Tseltal 589,144 and Tsotsil 550,274.

For a Cancún product, two of those matter for a reason beyond the national numbers. Yucatec Maya is native to Quintana Roo. And in our own research notes, Tseltal and Tsotsil came out as the second and third most spoken indigenous languages in Cancún after Maya (4,098 and 3,208 speakers in the Benito Juárez municipality), with the highest monolingual rates of the four. Those are Chiapas migrants who work in hospitality, including at sports clubs. For them a Spanish-only screen may be no screen at all.

We are not claiming these readers are our customers today; a product built for a Mexican city should simply be usable by the people who live in it.

Lesson 1: locale tags are a permanent public decision

A locale tag ends up in four places you cannot easily change: the URL segment, <html lang>, hreflang, and Open Graph's og:locale. Once other sites link to /xyz/, renaming it costs real money. So we audited every tag against two registers, the ISO 639-3 code set and the IANA language subtag registry, before shipping any copy. Three findings, in increasing order of annoyance:

Some languages map to one code cleanly. yua (Yucatec Maya), tzh (Tzeltal) and tzo (Tzotzil) are individual languages with one code each. Easy.

Nahuatl has no individual code. nah is a collection code: ISO 639-3 splits Nahuatl into about 29 individual languages and none of them is "Nahuatl". RFC 5646 says a collection subtag may be used when more specific information is unavailable, but that it SHOULD NOT be used for content better tagged with an individual language. We kept nah anyway, because picking one variety (say, the Huasteca one) would tell a reader from Guerrero that we chose someone else's Nahuatl for them. The cost is real and we document it: a browser sending Accept-Language: nhe will not match nah. Content negotiation is where this bites.

One of our tags was simply the wrong language. mix looks like "Mixtec" but ISO 639-3 defines it as Mixtepec Mixtec, the speech of one municipality in Oaxaca, with on the order of ten thousand speakers. Mixtec as a whole has over half a million speakers in the census and 52 individual codes with no macrolanguage above them. If we ever served <html lang="mix"> for a translated Mixtec site, we would tell screen readers and search engines something false about roughly 98% of the intended readers. It is still open as a decision; the lesson is that a tag that "looks right" is not a tag that has been checked.

A smaller one: ISO prints "Tzeltal" and "Tzotzil"; the modern INALI orthography is "Tseltal" and "Tsotsil". We show the latter in the switcher and keep the ISO codes in the markup.

Lesson 2: your date and number libraries do not know these languages

Not one indigenous tag we ship has CLDR date or number data, and only Nahuatl has plural rules. Intl.DateTimeFormat("tzh") falls back silently, usually to the runtime default, which is not what you want. We route every date and number through a formattingLocale() helper that maps each locale to the nearest language that has data. For these audiences that means formatting like Mexican Spanish. It is a pragmatic answer, not a right one; native speakers should decide how a date reads.

Plural rules are the quieter problem: for a language with no CLDR rules the engine falls back to a default that may be wrong, so we avoid plural-sensitive phrasing where we can, and our check script treats broken ICU syntax as a hard error.

Lesson 3: honest status beats a complete-looking list

This is the part we most want other teams to copy. The tempting move is to generate a catalogue for every language and ship it. A machine-drafted sentence in a language the model barely knows can be confidently wrong, and the reader cannot tell. So each locale has an explicit status:

reviewed: a human who reads the language checked the catalogue. Seven locales: Spanish, English, Portuguese, French, German, Italian, Russian.
machine: generated and not reviewed by a native speaker. It carries a "beta" badge in the switcher. Nineteen locales are here, including Chinese, Korean, Japanese, Dutch, Arabic, Yucatec Maya, Nahuatl, Tzeltal and Tzotzil.
pending: the file exists, but its contents are a structural copy of the fallback language. For a Mexican indigenous language the fallback is Spanish, because those readers already navigate in Spanish, and a Spanish screen is more honest than invented text.

Thirty-four indigenous catalogues are in the pending state today (7 reviewed + 19 machine + 34 pending = 60). They are in the list because the directive was to cover the languages, and they are pending because we would rather say so than pretend.

The part that matters for engineering is that "pending" is derived, not hand-flagged. A pending locale renders <html lang="es-MX">, is excluded from hreflang and the sitemap, gets noindex, and reports og:locale as es_MX, so the markup never claims a language the page does not contain. The trap: the moment someone translates a pending file, the whole lang/hreflang/sitemap cluster switches on automatically, and nobody re-decides the tag. That is why the mix problem matters now, while it is cheap to fix.

Lesson 4: make the build enforce the boring invariants

You cannot review 60 catalogues by eye. Our check script treats key parity, placeholder parity ({count}, {club}) and valid ICU syntax as hard errors in every locale. For pending locales it downgrades only two rule families to warnings: "identical to another locale" and CJK script purity. That lets us hold Spanish text in a Tzeltal file without failing the build, while still failing a catalogue that drops a key or a placeholder.

One pitfall worth stealing: surfaces like our OG cards and the WhatsApp share layer once kept their own hand-maintained list of pending locales, and went stale on every promotion. We now derive every such list from the single status file and pin it with a test.

What we have not done

Being straight about this, because writing "60 locales" in a headline invites a different reading than the truth.

No native-speaker review yet for any indigenous locale. The status is machine, and it says beta on the screen. Finding reviewers is the actual work.
Dozens of locales are Spanish text in disguise. They are a commitment and a structure, not a finished product.
Not every language is covered. We excluded languages when ISO 639-3 splits them into many coordinate varieties with no obvious standard, and later accepted that risk for some by choosing the largest variety, with a requirement that a native reviewer confirms it before promotion. That decision can be wrong, and we say so in the repo.
We have no usage numbers for these locales, and will not make any up.

If you are a speaker of Nahuatl, Yucatec Maya, Tseltal or Tsotsil and want to correct our strings, we would like to hear from you at hola@meetandplay.mx.

Takeaways

Audit tags against ISO 639-3 and IANA before building on them; keep each catalogue's status in one file and derive everything else from it; prefer a labeled fallback to confident gibberish; and test keys, placeholders and ICU in every locale. The app is MeetAndPlay: find a game, find players, book a court.

Sources: INEGI, Censo de Población y Vivienda 2020 (press release 430/22); ISO 639-3 code set (SIL); IANA Language Subtag Registry; RFC 5646.