When a learner can reproduce a familiar example but a small variation causes confusion, the problem is usually an incomplete model rather than a lack of effort. The fastest useful response is to expose the hidden state and test one boundary at a time.

Intl.Locale turns a locale identifier into a structured, canonical locale object. It can expose language, script, region and variants, carry Unicode extension preferences, add or remove likely subtags, and report locale-dependent calendars, numbering systems, time zones, week data and text direction where supported. Mastery means treating locale as user preference metadata rather than a flag, country or translation guarantee. This guide begins with that mechanism, then develops it through worked traces, deliberate mistakes, explained practice and transfer decisions.

The aim is independent reasoning. A learner should be able to predict behaviour, locate the earliest wrong assumption, use a safe diagnostic procedure and defend a design choice in a new project.

Punggol families can use the guide in short sessions around homework, CCAs and rest. The activities are proposed learning exercises, not claims about a physical branch, timetable, class size, fee, school relationship or guaranteed result.

Use disposable data and repositories, preserve backups, and check version-sensitive details against the official source. Current documentation settles a technical contract; observation and explanation turn that contract into usable knowledge.

Construction validates and canonicalises a BCP 47 tag while retaining locale semantics for later Intl APIs. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is treating input as an arbitrary underscore-separated language string. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Construct one valid tag, print toString and inspect components.

For the Intl.Locale parses a locale identifier chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on treating input as an arbitrary underscore-separated language string. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const loc=new Intl.Locale('en-sg');
console.log(loc.toString(),loc.language,loc.region);

Four purposeful transfer cases

Case 1: family portal. Predict the rule using carrying language and regional preferences across a Punggol household. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: school calendar. Contrast the rule using reasoning about first day, weekend and regional conventions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: reading interface. Stress-test the rule using choosing text direction and display labels. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: mathematics app. Explain the rule using passing numbering-system preferences to formatters. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers treating input as an arbitrary underscore-separated language string.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Construct one valid tag, print toString and inspect components.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from Intl.Locale parses a locale identifier?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing treating input as an arbitrary underscore-separated language string be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny data import with canonicalising and validating stored locale tags. Include one ordinary case, one boundary and one deliberate failure caused by treating input as an arbitrary underscore-separated language string. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Intl.Locale parses a locale identifier, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Language identifies a linguistic form, script a writing system and region regional conventions; none proves a user location. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is reading region as GPS location or language as nationality. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Label each subtag and the limited decision it may influence.

For the Language, script and region are different chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on reading region as GPS location or language as nationality. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const loc=new Intl.Locale('zh-Hans-SG');
console.log(loc.language,loc.script,loc.region);

Four purposeful transfer cases

Case 1: reading interface. Contrast the rule using choosing text direction and display labels. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: mathematics app. Stress-test the rule using passing numbering-system preferences to formatters. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: travel plan. Explain the rule using separating language, script, region and time-zone choices. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: data import. Transfer the rule using canonicalising and validating stored locale tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers reading region as GPS location or language as nationality.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Label each subtag and the limited decision it may influence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from Language, script and region are different?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing reading region as GPS location or language as nationality be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny test laboratory with checking likely subtags, extensions, arrays and unsupported tags. Include one ordinary case, one boundary and one deliberate failure caused by reading region as GPS location or language as nationality. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Language, script and region are different, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Canonicalisation regularises casing and preferred tag representation but does not create translations or verify resources. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is claiming a canonical tag means the app has a matching translation. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Canonicalise the identifier, then check the resource catalogue separately.

For the Canonicalisation does not translate content chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on claiming a canonical tag means the app has a matching translation. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

console.log(new Intl.Locale('EN-sg').toString());

Four purposeful transfer cases

Case 1: travel plan. Stress-test the rule using separating language, script, region and time-zone choices. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: data import. Explain the rule using canonicalising and validating stored locale tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Transfer the rule using checking likely subtags, extensions, arrays and unsupported tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design review. Predict the rule using separating locale, translation, geography and identity. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers claiming a canonical tag means the app has a matching translation.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Canonicalise the identifier, then check the resource catalogue separately.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from Canonicalisation does not translate content?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing claiming a canonical tag means the app has a matching translation be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design review with separating locale, translation, geography and identity. Include one ordinary case, one boundary and one deliberate failure caused by claiming a canonical tag means the app has a matching translation. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Canonicalisation does not translate content, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Constructor options can set language, script, region and Unicode-related preferences to produce a new Locale. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is mutating an existing Locale as if it were a settings record. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Construct a second Locale from the first plus options and compare strings.

For the Options can add or override fields chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on mutating an existing Locale as if it were a settings record. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const a=new Intl.Locale('en');
const b=new Intl.Locale(a,{region:'SG'});
console.log(a.toString(),b.toString());

Four purposeful transfer cases

Case 1: test laboratory. Explain the rule using checking likely subtags, extensions, arrays and unsupported tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design review. Transfer the rule using separating locale, translation, geography and identity. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: family portal. Predict the rule using carrying language and regional preferences across a Punggol household. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: school calendar. Contrast the rule using reasoning about first day, weekend and regional conventions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers mutating an existing Locale as if it were a settings record.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Construct a second Locale from the first plus options and compare strings.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from Options can add or override fields?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing mutating an existing Locale as if it were a settings record be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family portal with carrying language and regional preferences across a Punggol household. Include one ordinary case, one boundary and one deliberate failure caused by mutating an existing Locale as if it were a settings record. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Options can add or override fields, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Exposed properties read initialized locale data; semantic changes require constructing another Locale. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is assigning loc.region and expecting downstream formatters to change. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep application state outside and construct a replacement value.

For the Locale objects are immutable values chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assigning loc.region and expecting downstream formatters to change. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const loc=new Intl.Locale('en-SG');
console.log(loc.region);

Four purposeful transfer cases

Case 1: family portal. Transfer the rule using carrying language and regional preferences across a Punggol household. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: school calendar. Predict the rule using reasoning about first day, weekend and regional conventions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: reading interface. Contrast the rule using choosing text direction and display labels. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: mathematics app. Stress-test the rule using passing numbering-system preferences to formatters. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers assigning loc.region and expecting downstream formatters to change.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Keep application state outside and construct a replacement value.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from Locale objects are immutable values?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assigning loc.region and expecting downstream formatters to change be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny school calendar with reasoning about first day, weekend and regional conventions. Include one ordinary case, one boundary and one deliberate failure caused by assigning loc.region and expecting downstream formatters to change. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Locale objects are immutable values, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Calendar, collation, hour cycle, case-first, numbering system and numeric preferences may be encoded in the tag. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is concatenating extension text without knowing supported keys. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use constructor options and inspect the canonical string and properties.

For the Unicode extensions carry preferences chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on concatenating extension text without knowing supported keys. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const loc=new Intl.Locale('en-SG',{hourCycle:'h23',numberingSystem:'latn'});
console.log(loc.hourCycle,loc.numberingSystem,loc.toString());

Four purposeful transfer cases

Case 1: reading interface. Predict the rule using choosing text direction and display labels. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: mathematics app. Contrast the rule using passing numbering-system preferences to formatters. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: travel plan. Stress-test the rule using separating language, script, region and time-zone choices. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: data import. Explain the rule using canonicalising and validating stored locale tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers concatenating extension text without knowing supported keys.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Use constructor options and inspect the canonical string and properties.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from Unicode extensions carry preferences?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing concatenating extension text without knowing supported keys be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny reading interface with choosing text direction and display labels. Include one ordinary case, one boundary and one deliberate failure caused by concatenating extension text without knowing supported keys. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Unicode extensions carry preferences, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

The numeric option requests numeric-aware collation where a collator uses the locale; it does not parse numbers. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using Locale.numeric as validation or arithmetic. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Pass the locale to Intl.Collator and compare digit-containing labels.

For the numeric is a collation preference chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using Locale.numeric as validation or arithmetic. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const loc=new Intl.Locale('en',{numeric:true});
console.log(new Intl.Collator(loc).compare('item2','item10'));

Four purposeful transfer cases

Case 1: travel plan. Contrast the rule using separating language, script, region and time-zone choices. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: data import. Stress-test the rule using canonicalising and validating stored locale tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Explain the rule using checking likely subtags, extensions, arrays and unsupported tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design review. Transfer the rule using separating locale, translation, geography and identity. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using Locale.numeric as validation or arithmetic.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Pass the locale to Intl.Collator and compare digit-containing labels.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from numeric is a collation preference?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using Locale.numeric as validation or arithmetic be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny mathematics app with passing numbering-system preferences to formatters. Include one ordinary case, one boundary and one deliberate failure caused by using Locale.numeric as validation or arithmetic. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For numeric is a collation preference, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

maximize applies likely-subtag data and returns a new Locale, often filling script and region. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is treating likely subtags as verified facts about the user. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Compare minimal and maximized strings and label additions as defaults.

For the maximize adds likely subtags chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on treating likely subtags as verified facts about the user. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const a=new Intl.Locale('zh');
console.log(a.toString(),a.maximize().toString());

Four purposeful transfer cases

Case 1: test laboratory. Stress-test the rule using checking likely subtags, extensions, arrays and unsupported tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design review. Explain the rule using separating locale, translation, geography and identity. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: family portal. Transfer the rule using carrying language and regional preferences across a Punggol household. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: school calendar. Predict the rule using reasoning about first day, weekend and regional conventions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers treating likely subtags as verified facts about the user.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Compare minimal and maximized strings and label additions as defaults.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from maximize adds likely subtags?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing treating likely subtags as verified facts about the user be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny travel plan with separating language, script, region and time-zone choices. Include one ordinary case, one boundary and one deliberate failure caused by treating likely subtags as verified facts about the user. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For maximize adds likely subtags, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

minimize removes subtags when likely-subtag reconstruction preserves the same maximized form. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using minimize as generic string shortening. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Verify that original and minimized locales maximize to the same form.

For the minimize removes redundant subtags chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using minimize as generic string shortening. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const a=new Intl.Locale('en-Latn-US');
const b=a.minimize();
console.log(b.toString(),b.maximize().toString());

Four purposeful transfer cases

Case 1: family portal. Explain the rule using carrying language and regional preferences across a Punggol household. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: school calendar. Transfer the rule using reasoning about first day, weekend and regional conventions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: reading interface. Predict the rule using choosing text direction and display labels. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: mathematics app. Contrast the rule using passing numbering-system preferences to formatters. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using minimize as generic string shortening.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Verify that original and minimized locales maximize to the same form.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from minimize removes redundant subtags?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using minimize as generic string shortening be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny data import with canonicalising and validating stored locale tags. Include one ordinary case, one boundary and one deliberate failure caused by using minimize as generic string shortening. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For minimize removes redundant subtags, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Both methods construct Locale objects and leave the source unchanged. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is calling maximize then reading added fields from the original. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Store the returned value and print both objects.

For the maximize and minimize do not mutate chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on calling maximize then reading added fields from the original. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const a=new Intl.Locale('en');
const b=a.maximize();
console.log(a.region,b.region);

Four purposeful transfer cases

Case 1: reading interface. Transfer the rule using choosing text direction and display labels. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: mathematics app. Predict the rule using passing numbering-system preferences to formatters. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: travel plan. Contrast the rule using separating language, script, region and time-zone choices. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: data import. Stress-test the rule using canonicalising and validating stored locale tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers calling maximize then reading added fields from the original.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Store the returned value and print both objects.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from maximize and minimize do not mutate?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing calling maximize then reading added fields from the original be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny test laboratory with checking likely subtags, extensions, arrays and unsupported tags. Include one ordinary case, one boundary and one deliberate failure caused by calling maximize then reading added fields from the original. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For maximize and minimize do not mutate, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

toString returns the internal locale identifier and is safer than manually rebuilding components. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is losing variants or extensions through string surgery. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Round-trip toString through a new Locale.

For the toString is the canonical interchange form chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on losing variants or extensions through string surgery. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const a=new Intl.Locale('en-SG-u-hc-h23');
const b=new Intl.Locale(a.toString());
console.log(a.toString()===b.toString());

Four purposeful transfer cases

Case 1: travel plan. Predict the rule using separating language, script, region and time-zone choices. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: data import. Contrast the rule using canonicalising and validating stored locale tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Stress-test the rule using checking likely subtags, extensions, arrays and unsupported tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design review. Explain the rule using separating locale, translation, geography and identity. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers losing variants or extensions through string surgery.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Round-trip toString through a new Locale.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from toString is the canonical interchange form?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing losing variants or extensions through string surgery be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design review with separating locale, translation, geography and identity. Include one ordinary case, one boundary and one deliberate failure caused by losing variants or extensions through string surgery. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For toString is the canonical interchange form, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

baseName contains language, script, region and variants without Unicode extension settings. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using baseName when a cache must distinguish calendar preferences. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Print baseName beside the full string and name each cache decision.

For the baseName excludes Unicode extensions chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using baseName when a cache must distinguish calendar preferences. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const loc=new Intl.Locale('en-SG-u-ca-gregory');
console.log(loc.baseName,loc.toString());

Four purposeful transfer cases

Case 1: test laboratory. Contrast the rule using checking likely subtags, extensions, arrays and unsupported tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design review. Stress-test the rule using separating locale, translation, geography and identity. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: family portal. Explain the rule using carrying language and regional preferences across a Punggol household. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: school calendar. Transfer the rule using reasoning about first day, weekend and regional conventions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using baseName when a cache must distinguish calendar preferences.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Print baseName beside the full string and name each cache decision.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from baseName excludes Unicode extensions?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using baseName when a cache must distinguish calendar preferences be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family portal with carrying language and regional preferences across a Punggol household. Include one ordinary case, one boundary and one deliberate failure caused by using baseName when a cache must distinguish calendar preferences. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For baseName excludes Unicode extensions, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Where implemented, getWeekInfo returns first day, weekend and minimal days from locale data. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is hard-coding one familiar week globally. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Query the locale and keep business rules separate from display defaults.

For the getWeekInfo reports regional conventions chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on hard-coding one familiar week globally. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const loc=new Intl.Locale('en-SG');
console.log(loc.getWeekInfo?.());

Four purposeful transfer cases

Case 1: family portal. Stress-test the rule using carrying language and regional preferences across a Punggol household. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: school calendar. Explain the rule using reasoning about first day, weekend and regional conventions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: reading interface. Transfer the rule using choosing text direction and display labels. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: mathematics app. Predict the rule using passing numbering-system preferences to formatters. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers hard-coding one familiar week globally.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Query the locale and keep business rules separate from display defaults.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from getWeekInfo reports regional conventions?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing hard-coding one familiar week globally be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny school calendar with reasoning about first day, weekend and regional conventions. Include one ordinary case, one boundary and one deliberate failure caused by hard-coding one familiar week globally. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For getWeekInfo reports regional conventions, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

getTextInfo can report ltr or rtl, informing layout without replacing semantic HTML direction handling. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is guessing direction from the first two tag letters. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Query the API and test RTL and LTR interfaces.

For the getTextInfo reports direction chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on guessing direction from the first two tag letters. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

console.log(new Intl.Locale('ar').getTextInfo?.().direction);
console.log(new Intl.Locale('en').getTextInfo?.().direction);

Four purposeful transfer cases

Case 1: reading interface. Explain the rule using choosing text direction and display labels. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: mathematics app. Transfer the rule using passing numbering-system preferences to formatters. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: travel plan. Predict the rule using separating language, script, region and time-zone choices. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: data import. Contrast the rule using canonicalising and validating stored locale tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers guessing direction from the first two tag letters.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Query the API and test RTL and LTR interfaces.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from getTextInfo reports direction?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing guessing direction from the first two tag letters be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny reading interface with choosing text direction and display labels. Include one ordinary case, one boundary and one deliberate failure caused by guessing direction from the first two tag letters. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For getTextInfo reports direction, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Methods can report calendars, collations, hour cycles, numbering systems and time zones relevant to a locale. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is assuming the first item is the only valid user choice. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Treat results as capabilities and let explicit settings override defaults.

For the Locale data methods return preference arrays chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming the first item is the only valid user choice. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const loc=new Intl.Locale('en-SG');
console.log(loc.getCalendars?.(),loc.getNumberingSystems?.());

Four purposeful transfer cases

Case 1: travel plan. Transfer the rule using separating language, script, region and time-zone choices. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: data import. Predict the rule using canonicalising and validating stored locale tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Contrast the rule using checking likely subtags, extensions, arrays and unsupported tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design review. Stress-test the rule using separating locale, translation, geography and identity. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers assuming the first item is the only valid user choice.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Treat results as capabilities and let explicit settings override defaults.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from Locale data methods return preference arrays?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming the first item is the only valid user choice be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny mathematics app with passing numbering-system preferences to formatters. Include one ordinary case, one boundary and one deliberate failure caused by assuming the first item is the only valid user choice. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Locale data methods return preference arrays, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

getTimeZones can return undefined without a region because time-zone lists are regional. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is expecting a language tag to identify one clock setting. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Add a region explicitly and compare observations.

For the Language alone may not yield time zones chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on expecting a language tag to identify one clock setting. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const a=new Intl.Locale('en');
const b=new Intl.Locale('en-SG');
console.log(a.getTimeZones?.(),b.getTimeZones?.()?.length);

Four purposeful transfer cases

Case 1: test laboratory. Predict the rule using checking likely subtags, extensions, arrays and unsupported tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design review. Contrast the rule using separating locale, translation, geography and identity. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: family portal. Stress-test the rule using carrying language and regional preferences across a Punggol household. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: school calendar. Explain the rule using reasoning about first day, weekend and regional conventions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers expecting a language tag to identify one clock setting.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Add a region explicitly and compare observations.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from Language alone may not yield time zones?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing expecting a language tag to identify one clock setting be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny travel plan with separating language, script, region and time-zone choices. Include one ordinary case, one boundary and one deliberate failure caused by expecting a language tag to identify one clock setting. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Language alone may not yield time zones, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Intl constructors accept Locale objects through locale-list processing, avoiding manual string surgery. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is extracting only language and discarding other preferences. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use the complete Locale and inspect resolvedOptions.

For the Pass Locale objects to Intl formatters chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on extracting only language and discarding other preferences. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const loc=new Intl.Locale('en-SG',{numberingSystem:'latn'});
const nf=new Intl.NumberFormat(loc,{style:'currency',currency:'SGD'});
console.log(nf.resolvedOptions().locale);

Four purposeful transfer cases

Case 1: family portal. Contrast the rule using carrying language and regional preferences across a Punggol household. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: school calendar. Stress-test the rule using reasoning about first day, weekend and regional conventions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: reading interface. Explain the rule using choosing text direction and display labels. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: mathematics app. Transfer the rule using passing numbering-system preferences to formatters. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers extracting only language and discarding other preferences.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Use the complete Locale and inspect resolvedOptions.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from Pass Locale objects to Intl formatters?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing extracting only language and discarding other preferences be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny data import with canonicalising and validating stored locale tags. Include one ordinary case, one boundary and one deliberate failure caused by extracting only language and discarding other preferences. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Pass Locale objects to Intl formatters, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Intl.Locale represents one locale; selecting the best supported application locale from a list remains negotiation. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is assuming every valid Locale is supported exactly by every catalogue. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use supportedLocalesOf and define a fallback chain.

For the Locale negotiation is separate chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming every valid Locale is supported exactly by every catalogue. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

console.log(Intl.NumberFormat.supportedLocalesOf(['en-SG','xx-YY']));

Four purposeful transfer cases

Case 1: reading interface. Stress-test the rule using choosing text direction and display labels. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: mathematics app. Explain the rule using passing numbering-system preferences to formatters. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: travel plan. Transfer the rule using separating language, script, region and time-zone choices. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: data import. Predict the rule using canonicalising and validating stored locale tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers assuming every valid Locale is supported exactly by every catalogue.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Use supportedLocalesOf and define a fallback chain.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from Locale negotiation is separate?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming every valid Locale is supported exactly by every catalogue be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny test laboratory with checking likely subtags, extensions, arrays and unsupported tags. Include one ordinary case, one boundary and one deliberate failure caused by assuming every valid Locale is supported exactly by every catalogue. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Locale negotiation is separate, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Structurally invalid language tags throw RangeError, making construction useful at an input boundary. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is silently accepting arbitrary profile text as a locale. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Catch RangeError and preserve the original value for correction.

For the Invalid tags fail early chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on silently accepting arbitrary profile text as a locale. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

try{ new Intl.Locale('not_a_locale'); }
catch(e){ console.log(e.name); }

Four purposeful transfer cases

Case 1: travel plan. Explain the rule using separating language, script, region and time-zone choices. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: data import. Transfer the rule using canonicalising and validating stored locale tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Predict the rule using checking likely subtags, extensions, arrays and unsupported tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design review. Contrast the rule using separating locale, translation, geography and identity. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers silently accepting arbitrary profile text as a locale.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Catch RangeError and preserve the original value for correction.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from Invalid tags fail early?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing silently accepting arbitrary profile text as a locale be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design review with separating locale, translation, geography and identity. Include one ordinary case, one boundary and one deliberate failure caused by silently accepting arbitrary profile text as a locale. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Invalid tags fail early, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

A locale can guide formatting and language selection but does not establish nationality, proficiency, address or translation. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using one locale field for high-stakes assumptions. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Store language, region, time zone and accessibility preferences separately.

For the Locale is metadata, not identity chapter on JavaScript Intl.Locale, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using one locale field for high-stakes assumptions. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const profile={locale:'en-SG',timeZone:'Asia/Singapore',languages:['en','zh']};
console.log(profile);

Four purposeful transfer cases

Case 1: test laboratory. Transfer the rule using checking likely subtags, extensions, arrays and unsupported tags. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design review. Predict the rule using separating locale, translation, geography and identity. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: family portal. Contrast the rule using carrying language and regional preferences across a Punggol household. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: school calendar. Stress-test the rule using reasoning about first day, weekend and regional conventions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using one locale field for high-stakes assumptions.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Store language, region, time zone and accessibility preferences separately.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final JavaScript Intl.Locale syntax. For this chapter, useful prompts are: “What did you expect from Locale is metadata, not identity?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using one locale field for high-stakes assumptions be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family portal with carrying language and regional preferences across a Punggol household. Include one ordinary case, one boundary and one deliberate failure caused by using one locale field for high-stakes assumptions. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Locale is metadata, not identity, separate the documented JavaScript Intl.Locale mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Start with evidence, not a label such as careless. Ask for one prediction and one trace. If the first transition is wrong, rebuild the model. If the model is sound but syntax fails, practise reference use. If routine cases are correct but boundaries fail, vary ties, defaults, unsupported inputs, ownership or missing paths. If explanations transfer, move to a small project.

Keep a weekly record with four lines: concept, prediction, observed difference and next test. Stop when fatigue replaces reasoning. A smaller case tomorrow is more useful than another hour of copying tonight.

Seek specialist help when cause and effect remain invisible after examples are reduced, when accessibility or data-loss implications are unclear, or when an important repository, database or application state may be at risk. Good support should make the learner’s reasoning more independent.

1. family portal: model, boundary and recovery

Create a small family portal using carrying language and regional preferences across a Punggol household. Combine “Intl.Locale parses a locale identifier” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

2. school calendar: model, boundary and recovery

Create a small school calendar using reasoning about first day, weekend and regional conventions. Combine “Options can add or override fields” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

3. reading interface: model, boundary and recovery

Create a small reading interface using choosing text direction and display labels. Combine “numeric is a collation preference” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

4. mathematics app: model, boundary and recovery

Create a small mathematics app using passing numbering-system preferences to formatters. Combine “maximize and minimize do not mutate” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

5. travel plan: model, boundary and recovery

Create a small travel plan using separating language, script, region and time-zone choices. Combine “getWeekInfo reports regional conventions” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

6. data import: model, boundary and recovery

Create a small data import using canonicalising and validating stored locale tags. Combine “Language alone may not yield time zones” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

7. test laboratory: model, boundary and recovery

Create a small test laboratory using checking likely subtags, extensions, arrays and unsupported tags. Combine “Invalid tags fail early” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

8. design review: model, boundary and recovery

Create a small design review using separating locale, translation, geography and identity. Combine “Language, script and region are different” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

Frequently asked questions

How long should a practice session be?

Use one complete prediction–observation–explanation cycle while attention remains good. Ten to twenty focused minutes can be enough.

Should every option or function be memorised?

No. Memorise the governing distinctions and practise retrieving the official reference. Understanding means predicting and explaining, not reciting a parameter list.

What if the result is correct but the explanation is weak?

Treat it as partial success. Ask for a trace and change one boundary. A reliable model survives controlled variation.

Is the shortest solution the best?

Not automatically. Prefer the solution whose semantics, failure modes and maintenance cost are easiest to justify for the actual project.

When should official documentation be used?

Use it whenever syntax, supported types, SQL dialect behaviour or Git version details matter. Primary documentation settles the current contract.

How can a parent help without technical expertise?

Ask what was predicted, where the first difference appeared, what evidence matters and which smaller example could isolate it.

How do we test transfer?

Change the context, vocabulary and one boundary. Require the learner to identify the invariant before using a tool.

What should be saved after practice?

Keep the corrected rule, one trace, one boundary case and the next question. Avoid storing pages of unexplained output.

Can these exercises replace backups?

No. Use disposable examples and proper backups. Learning should not endanger schoolwork, repositories or personal data.

What counts as mastery?

The learner can predict, verify, diagnose, recover and justify a choice across more than one context, while knowing when to consult the current reference.

Official and supporting references

• Primary technical documentation for JavaScript Intl.Locale
• eduKatePunggol: How Studying Works

Return to contents