# [Bug] Missing Translations in Geography Module – Cuba Country Summary #1113

New Issue

2026-08-27T22:42:24Z

enjin2310 commented

2026-08-27 22:42:24 +00:00

Summary

The Geography module displays English text in the Cuba Country Summary section while the selected language is Spanish. The issue affects multiple content blocks, including cultural and historical descriptions.

Issue Description

When viewing the country summary for Cuba in the Geography module, several text elements remain in English despite the interface being set to Spanish. The problem occurs in the “Resumen del país” panel, where entries such as “Santa Ifigenia Cemetery honors national heroes,” “French coffee plantations dot the mountains,” and “Sugar production remains important” are not localized.

Environment

Property	Value
Application	SpikerSoft Learn
Module	Geography
Country	Cuba
Environment	Production
Browser	Firefox
Operating System	Windows 11
Version	v2026.08.27e
Device	Desktop

Preconditions

User must be logged in and have Spanish selected as the display language.

Steps to Reproduce

Log in to the SpikerSoft platform.
Navigate to Learn > Geography.
Select Cuba from the country list.
Observe the Resumen del país section.

Expected Result

All text within the country summary should appear in Spanish, consistent with the selected language.

Actual Result

Several entries remain in English, including:

“Santa Ifigenia Cemetery honors national heroes”
“French coffee plantations dot the mountains”
“Sugar production remains important”

Evidence

The screenshot shows the Resumen del país panel with English text under the Spanish interface.
The navigation bar and other UI elements are correctly localized, confirming the language setting is active.

Impact

Breaks language consistency across the Geography module.
Reduces accessibility and comprehension for Spanish-speaking users.
Suggests incomplete localization coverage for country data entries.

Frequency

Always

Reproducibility

100%

Severity

Medium

Notes

The issue likely stems from missing or untranslated content in the country data source. It is recommended to verify the localization mapping for country summaries and ensure all entries are properly translated.

## Summary The **Geography** module displays English text in the **Cuba Country Summary** section while the selected language is Spanish. The issue affects multiple content blocks, including cultural and historical descriptions. ## Issue Description When viewing the country summary for Cuba in the Geography module, several text elements remain in English despite the interface being set to Spanish. The problem occurs in the “Resumen del país” panel, where entries such as “Santa Ifigenia Cemetery honors national heroes,” “French coffee plantations dot the mountains,” and “Sugar production remains important” are not localized. ## Environment | Property | Value | |-----------|--------| | Application | SpikerSoft Learn | | Module | Geography | | Country | Cuba | | Environment | Production | | Browser | Firefox | | Operating System | Windows 11 | | Version | v2026.08.27e | | Device | Desktop | ## Preconditions User must be logged in and have Spanish selected as the display language. ## Steps to Reproduce 1. Log in to the SpikerSoft platform. 2. Navigate to **Learn > Geography**. 3. Select **Cuba** from the country list. 4. Observe the **Resumen del país** section. ## Expected Result All text within the country summary should appear in Spanish, consistent with the selected language. ## Actual Result Several entries remain in English, including: - “Santa Ifigenia Cemetery honors national heroes” - “French coffee plantations dot the mountains” - “Sugar production remains important” ## Evidence - The screenshot shows the **Resumen del país** panel with English text under the Spanish interface. - The navigation bar and other UI elements are correctly localized, confirming the language setting is active. ## Impact - Breaks language consistency across the Geography module. - Reduces accessibility and comprehension for Spanish-speaking users. - Suggests incomplete localization coverage for country data entries. ## Frequency Always ## Reproducibility 100% ## Severity Medium ## Notes The issue likely stems from missing or untranslated content in the country data source. It is recommended to verify the localization mapping for country summaries and ensure all entries are properly translated.

Screenshot 2026-08-27 184027.png

427 KiB

spikerj referenced this issue from a commit

2026-08-30 18:25:00 +00:00

feat: machine-translate geography facts with a review gate (fixes #781)

spikerj commented

2026-08-30 18:25:49 +00:00

Confirmed — and this one goes much wider than Cuba.

What you found. The Geography module has the translation machinery fully built: every fact has Spanish fields and the reader picks them with an English fallback. What it does not have is any Spanish content. Measured on production:


Geography facts total	3040
Facts with Spanish content	0

So it is not Cuba, and it is not a few missed entries — every fact of every country falls back to English under a Spanish UI. You happened to open Cuba first.

What is being done. spikerj/spikersoft-backend#782 adds a translation job that runs the corpus through the model this platform already runs, stamps each fact with which model translated it and when, and leaves a review flag so a human pass can follow. A few properties worth knowing as a tester:

A fact that fails to translate is left fully English rather than half-translated — so if you see a Spanish title over English body text, that is a bug worth reporting.
Quiz options translate all-or-nothing: mixed-language answer choices should never appear.
Once a human reviews a translation, re-running the job will not overwrite it.

Note this is the mechanism, not the content. The actual corpus run is a separate deliberate step (and the first pass will be capped and spot-checked), so Geography will keep showing English until that runs. I would rather tell you that plainly than have you re-report it next week.

Thank you for this one in particular — a single screenshot exposed a platform-wide content gap.

Confirmed — and this one goes much wider than Cuba. **What you found.** The Geography module has the translation machinery fully built: every fact has Spanish fields and the reader picks them with an English fallback. What it does not have is any Spanish *content*. Measured on production: | | | |---|---| | Geography facts total | **3040** | | Facts with Spanish content | **0** | So it is not Cuba, and it is not a few missed entries — **every fact of every country** falls back to English under a Spanish UI. You happened to open Cuba first. **What is being done.** spikerj/spikersoft-backend#782 adds a translation job that runs the corpus through the model this platform already runs, stamps each fact with which model translated it and when, and leaves a review flag so a human pass can follow. A few properties worth knowing as a tester: - A fact that fails to translate is left fully English rather than half-translated — so if you see a Spanish title over English body text, that is a bug worth reporting. - Quiz options translate all-or-nothing: mixed-language answer choices should never appear. - Once a human reviews a translation, re-running the job will not overwrite it. **Note this is the mechanism, not the content.** The actual corpus run is a separate deliberate step (and the first pass will be capped and spot-checked), so Geography will keep showing English until that runs. I would rather tell you that plainly than have you re-report it next week. Thank you for this one in particular — a single screenshot exposed a platform-wide content gap.

spikerj commented

2026-08-30 23:55:24 +00:00

Status update — not fixed yet, deliberately.

The backend work merged (spikerj/spikersoft-backend#782), but that PR shipped the translation mechanism and its review queue, not translated text. The corpus itself has never been run through it, so the symptom you reported is still live.

Just verified against production:

GET /api/geography/facts?countryCode=CUB&contentLocale=es
  -> 12 facts, content byte-identical to contentLocale=en

So Cuba summaries still come back in English under Spanish. Leaving this open until the corpus is actually translated and spot-reviewed — closing it on the merge alone would have marked a visible bug as fixed when nothing had changed for you. Good catch; it stays on the list.

Status update — **not fixed yet, deliberately.** The backend work merged (spikerj/spikersoft-backend#782), but that PR shipped the translation *mechanism* and its review queue, not translated text. The corpus itself has never been run through it, so the symptom you reported is still live. Just verified against production: ``` GET /api/geography/facts?countryCode=CUB&contentLocale=es -> 12 facts, content byte-identical to contentLocale=en ``` So Cuba summaries still come back in English under Spanish. Leaving this open until the corpus is actually translated and spot-reviewed — closing it on the merge alone would have marked a visible bug as fixed when nothing had changed for you. Good catch; it stays on the list.

spikerj commented

2026-09-21 04:15:11 +00:00

Still valid — and considerably wider than Cuba. Leaving open, because the remaining work is content rather than code.

It is not Cuba, it is every fact

The seed corpus has no Spanish at all:


seed files (`Domain/Geography/Commands/SeedGeographicFacts/`)	12
`F(...)` facts defined	3,038
facts carrying any Spanish text	0

The reason is the seed record signatures — there is nowhere to put a translation:

public record SeedFact(string Title, string Content, DateTime Date, List<string> Interests, …);
public record SeedCountry(string Code, string Name, string Description, …);

Neither has a Spanish field, so no fact or country name can carry one today. The three strings you quoted are simply the ones you happened to scroll past.

The plumbing is already built and unused

This is the encouraging part — nothing is broken, it is just empty. The Mongo model already has the columns:

public string? CountryNameEs { get; set; }
public string? TitleEs { get; set; }
public string? ContentEs { get; set; }

and GeographyLocalization.Pick(english, spanish, locale) returns Spanish when present and falls back to English when it is not — which is exactly the behaviour you saw. So the API is correct; it is answering with the only content it has.

Outside geography the same pattern is populated: CurriculumTextSeed.cs sets TitleEs on lesson text ("Por qué C#, contado por gente que escribía C antes de que tuviera sostenido", etc.). So the convention exists and works — geography just never got the content.

What it would take

Three separable pieces:

Add TitleEs / ContentEs to SeedFact and a Spanish name to SeedCountry (small, mechanical).
Wire them through the seeding command into the fields the model already has (small).
Translate 3,038 title + content pairs. This is the real cost, and it is a content decision — machine translation, a translator, or a prioritised subset (say, the Spanish-speaking countries first, which is likely where it matters most to your users).

I have not started (1) and (2), because shipping the plumbing with no content changes nothing on screen, and the shape of (3) should decide what the fields look like — a per-fact string pair is right for hand translation, a separate catalog keyed by fact id may be better if this gets generated.

Related: the same "English-only content behind working localisation" question is open for Practice decks in spikerj/spikersoft-angular#913. Worth deciding both together.

Still valid — and considerably wider than Cuba. Leaving open, because the remaining work is content rather than code. ## It is not Cuba, it is every fact The seed corpus has **no Spanish at all**: | | | | --- | --- | | seed files (`Domain/Geography/Commands/SeedGeographicFacts/`) | 12 | | `F(...)` facts defined | **3,038** | | facts carrying any Spanish text | **0** | The reason is the seed record signatures — there is nowhere to put a translation: ```csharp public record SeedFact(string Title, string Content, DateTime Date, List<string> Interests, …); public record SeedCountry(string Code, string Name, string Description, …); ``` Neither has a Spanish field, so no fact or country name can carry one today. The three strings you quoted are simply the ones you happened to scroll past. ## The plumbing is already built and unused This is the encouraging part — nothing is broken, it is just empty. The Mongo model already has the columns: ```csharp public string? CountryNameEs { get; set; } public string? TitleEs { get; set; } public string? ContentEs { get; set; } ``` and `GeographyLocalization.Pick(english, spanish, locale)` returns Spanish when present and **falls back to English when it is not** — which is exactly the behaviour you saw. So the API is correct; it is answering with the only content it has. Outside geography the same pattern is populated: `CurriculumTextSeed.cs` sets `TitleEs` on lesson text ("Por qué C#, contado por gente que escribía C antes de que tuviera sostenido", etc.). So the convention exists and works — geography just never got the content. ## What it would take Three separable pieces: 1. Add `TitleEs` / `ContentEs` to `SeedFact` and a Spanish name to `SeedCountry` (small, mechanical). 2. Wire them through the seeding command into the fields the model already has (small). 3. **Translate 3,038 title + content pairs.** This is the real cost, and it is a content decision — machine translation, a translator, or a prioritised subset (say, the Spanish-speaking countries first, which is likely where it matters most to your users). I have not started (1) and (2), because shipping the plumbing with no content changes nothing on screen, and the shape of (3) should decide what the fields look like — a per-fact string pair is right for hand translation, a separate catalog keyed by fact id may be better if this gets generated. Related: the same "English-only content behind working localisation" question is open for Practice decks in spikerj/spikersoft-angular#913. Worth deciding both together.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#1113