bug: Knowledge page titles not switching with language (except proper names) #21

Closed
opened 2026-04-08 00:08:49 +00:00 by KnallerKalle · 1 comment
KnallerKalle commented 2026-04-08 00:08:49 +00:00 (Migrated from github.com)

Bug Report

Affected Page: https://testing.atm.apps.hoerstudio-puchinger.de/de/knowledge

Problem Description

Knowledge entry titles remain in the default language when switching languages. The app should display content in the currently selected language (German/English).

Current Behavior

  • User switches from /en/knowledge to /de/knowledge
  • Knowledge entry titles remain in English
  • Content language doesn't update

Expected Behavior

  • Knowledge entry titles should translate when language switch occurs
  • Proper names and trademarks should remain untranslated
    • Example: "Awareness Through Movement" (trademark)
    • Example: "Functional Integration" (trademark term)

Investigation

Current Implementation

File: src/components/knowledge/KnowledgeList.tsx

Current code displays entry titles directly from database:

{entries.map(entry => (
  <div>
    <h3>{entry.title}</h3>  // Problem: Not translatable
  </div>
))}

Knowledge Database Schema

interface KnowledgeEntry {
  id: string
  title: string  // Currently single language
  content: string
  category: string
  tags: string[]
  created_at: number
  updated_at: number
}

Proposed Solutions

Schema Update:

interface KnowledgeEntry {
  id: string
  title: {                  // Translatable title
    en: string
    de: string
  }
  content: {                // Translatable content
    en: string
    de: string
  }
  category: string          // Static category
  tags: string[]
  proper_names: boolean       // Flag: Is this a proper name?
  created_at: number
  updated_at: number
}

Display Logic:

const displayTitle = entry.proper_names 
  ? entry.title.en  // Keep original for proper names/trademarks
  : entry.title[locale]  // Use current locale

Migration:

  • Existing entries: Add de: "" field (fill later)
  • Proper names: Set proper_names: true manually
  • Translations: Add UI for translating entries

Option B: Separate Translation Table

Schema:

CREATE TABLE knowledge_translations (
  id TEXT PRIMARY KEY,
  entry_id TEXT REFERENCES knowledge(id),
  locale TEXT,  // 'en', 'de'
  title TEXT NOT NULL,
  content TEXT,
  UNIQUE(entry_id, locale)
);

Query:

SELECT * FROM knowledge_t
LEFT JOIN knowledge_translations kt 
  ON knowledge_t.id = kt.entry_id AND kt.locale = 'de'

Option C: i18n Integration with Translation Keys

Use next-intl translation keys for knowledge base:

// messages/en.json
{
  "knowledge": {
    "entries": {
      "moshe-feldenkrais": {
        "title": "Dr. Moshe Feldenkrais",
        "content": "..."
      },
      "atm": {
        "title": "Awareness Through Movement",  // proper name, not translated
        "content": "..."
      }
    }
  }
}

Recommendation: Option A is most practical for dynamic content

Implementation Plan

Phase 1: Database Schema Update (High Priority)

  1. Update KnowledgeEntry interface with translatable fields
  2. Create migration script for existing entries
  3. Update API/Database layer to handle locales

Phase 2: UI Language Detection & Display

  1. KnowledgeList component reads locale from URL
  2. Display appropriate language version
  3. Fall back to English if translation missing

Phase 3: Content Migration Tool

  1. Admin tool to mark proper names
  2. Admin tool to translate entries (AI-assisted)
  3. Bulk translation import tool

Phase 4: AI-Assisted Translation (Optional - v0.4.0)

Use AI to auto-translate content:

async function translateEntry(entry: KnowledgeEntry, targetLocale: string) {
  const prompt = `Translate this Feldenkrais knowledge entry to ${targetLocale}:
  Title: ${entry.title}
  Content: ${entry.content}
  
  CRITICAL: Do NOT translate proper names, trademarks, or specific Feldenkrais terminology:
  - Keep "Awareness Through Movement"
  - Keep "Functional Integration"
  - Keep "Dr. Moshe Feldenkrais"`;
  
  const translation = await AIProvider.generate(prompt);
  return JSON.parse(translation);
}

Acceptance Criteria

  • Database schema supports multilingual titles/content
  • UI displays content in current language
  • Proper names/trademarks remain untranslated when flagged
  • Fallback to original language if translation missing
  • Settings page shows language preference
  • Migration script for existing entries

Questions

  1. Should we support more than English/German initially?
  2. Should translations be mandatory or optional?
  3. Who will be responsible for translations (admin vs AI)?
  4. Should we track translation quality/completeness?
  • #22: AI-generated knowledge base content (this relates to translation)
  • #19: Lesson Detail View (may need same multilingual approach)

Priority

High - Language switching is core feature, currently broken


Suggested Label: bug,i18n,Phase3,priority:high

## Bug Report **Affected Page**: https://testing.atm.apps.hoerstudio-puchinger.de/de/knowledge ## Problem Description Knowledge entry titles remain in the default language when switching languages. The app should display content in the currently selected language (German/English). ### Current Behavior - User switches from `/en/knowledge` to `/de/knowledge` - Knowledge entry titles remain in English - Content language doesn't update ### Expected Behavior - Knowledge entry titles should translate when language switch occurs - Proper names and trademarks should remain untranslated - Example: "Awareness Through Movement" (trademark) - Example: "Functional Integration" (trademark term) ## Investigation ### Current Implementation File: `src/components/knowledge/KnowledgeList.tsx` Current code displays entry titles directly from database: ```typescript {entries.map(entry => ( <div> <h3>{entry.title}</h3> // Problem: Not translatable </div> ))} ``` ### Knowledge Database Schema ```typescript interface KnowledgeEntry { id: string title: string // Currently single language content: string category: string tags: string[] created_at: number updated_at: number } ``` ## Proposed Solutions ### Option A: Add Translatable Fields to Database (Recommended) **Schema Update**: ```typescript interface KnowledgeEntry { id: string title: { // Translatable title en: string de: string } content: { // Translatable content en: string de: string } category: string // Static category tags: string[] proper_names: boolean // Flag: Is this a proper name? created_at: number updated_at: number } ``` **Display Logic**: ```typescript const displayTitle = entry.proper_names ? entry.title.en // Keep original for proper names/trademarks : entry.title[locale] // Use current locale ``` **Migration**: - Existing entries: Add `de: ""` field (fill later) - Proper names: Set `proper_names: true` manually - Translations: Add UI for translating entries ### Option B: Separate Translation Table **Schema**: ```sql CREATE TABLE knowledge_translations ( id TEXT PRIMARY KEY, entry_id TEXT REFERENCES knowledge(id), locale TEXT, // 'en', 'de' title TEXT NOT NULL, content TEXT, UNIQUE(entry_id, locale) ); ``` **Query**: ```typescript SELECT * FROM knowledge_t LEFT JOIN knowledge_translations kt ON knowledge_t.id = kt.entry_id AND kt.locale = 'de' ``` ### Option C: i18n Integration with Translation Keys Use next-intl translation keys for knowledge base: ```typescript // messages/en.json { "knowledge": { "entries": { "moshe-feldenkrais": { "title": "Dr. Moshe Feldenkrais", "content": "..." }, "atm": { "title": "Awareness Through Movement", // proper name, not translated "content": "..." } } } } ``` **Recommendation**: Option A is most practical for dynamic content ## Implementation Plan ### Phase 1: Database Schema Update (High Priority) 1. Update `KnowledgeEntry` interface with translatable fields 2. Create migration script for existing entries 3. Update API/Database layer to handle locales ### Phase 2: UI Language Detection & Display 1. KnowledgeList component reads locale from URL 2. Display appropriate language version 3. Fall back to English if translation missing ### Phase 3: Content Migration Tool 1. Admin tool to mark proper names 2. Admin tool to translate entries (AI-assisted) 3. Bulk translation import tool ### Phase 4: AI-Assisted Translation (Optional - v0.4.0) Use AI to auto-translate content: ```typescript async function translateEntry(entry: KnowledgeEntry, targetLocale: string) { const prompt = `Translate this Feldenkrais knowledge entry to ${targetLocale}: Title: ${entry.title} Content: ${entry.content} CRITICAL: Do NOT translate proper names, trademarks, or specific Feldenkrais terminology: - Keep "Awareness Through Movement" - Keep "Functional Integration" - Keep "Dr. Moshe Feldenkrais"`; const translation = await AIProvider.generate(prompt); return JSON.parse(translation); } ``` ## Acceptance Criteria - [ ] Database schema supports multilingual titles/content - [ ] UI displays content in current language - [ ] Proper names/trademarks remain untranslated when flagged - [ ] Fallback to original language if translation missing - [ ] Settings page shows language preference - [ ] Migration script for existing entries ## Questions 1. Should we support more than English/German initially? 2. Should translations be mandatory or optional? 3. Who will be responsible for translations (admin vs AI)? 4. Should we track translation quality/completeness? ## Related Issues - #22: AI-generated knowledge base content (this relates to translation) - #19: Lesson Detail View (may need same multilingual approach) ## Priority **High** - Language switching is core feature, currently broken --- **Suggested Label**: bug,i18n,Phase3,priority:high
KnallerKalle commented 2026-04-08 12:59:20 +00:00 (Migrated from github.com)

✅ Issue #21 COMPLETED - Language switching for knowledge pages is now fully implemented.

What was fixed:

  • Database schema now supports multilingual fields (title: {en, de}, content: {en, de})
  • Helper functions added: , in
  • component now uses locale-aware rendering ( hook)
  • Reloads entries when language changes (added LANG=C.UTF-8
    LANGUAGE=
    LC_CTYPE="C.UTF-8"
    LC_NUMERIC="C.UTF-8"
    LC_TIME="C.UTF-8"
    LC_COLLATE="C.UTF-8"
    LC_MONETARY="C.UTF-8"
    LC_MESSAGES="C.UTF-8"
    LC_PAPER="C.UTF-8"
    LC_NAME="C.UTF-8"
    LC_ADDRESS="C.UTF-8"
    LC_TELEPHONE="C.UTF-8"
    LC_MEASUREMENT="C.UTF-8"
    LC_IDENTIFICATION="C.UTF-8"
    LC_ALL= to useEffect dependency)
  • Proper names flag () prevents translation of trademarks

Files changed:

    • Multilingual KnowledgeEntry interface
    • Updated type handling
    • Locale-aware title/content rendering
    • NEW - Helper functions for multilingual display
    • Updated to handle multilingual content

Testing:

  • Switch between /en/knowledge and /de/knowledge
  • Titles and content should translate
  • Proper names (e.g., "Awareness Through Movement") remain unchanged

Commits: 27a2506, 4aebd06, 039a83f, 136ef0d

✅ **Issue #21 COMPLETED** - Language switching for knowledge pages is now fully implemented. **What was fixed:** - Database schema now supports multilingual fields (title: {en, de}, content: {en, de}) - Helper functions added: , in - component now uses locale-aware rendering ( hook) - Reloads entries when language changes (added LANG=C.UTF-8 LANGUAGE= LC_CTYPE="C.UTF-8" LC_NUMERIC="C.UTF-8" LC_TIME="C.UTF-8" LC_COLLATE="C.UTF-8" LC_MONETARY="C.UTF-8" LC_MESSAGES="C.UTF-8" LC_PAPER="C.UTF-8" LC_NAME="C.UTF-8" LC_ADDRESS="C.UTF-8" LC_TELEPHONE="C.UTF-8" LC_MEASUREMENT="C.UTF-8" LC_IDENTIFICATION="C.UTF-8" LC_ALL= to useEffect dependency) - Proper names flag () prevents translation of trademarks **Files changed:** - - Multilingual KnowledgeEntry interface - - Updated type handling - - Locale-aware title/content rendering - - NEW - Helper functions for multilingual display - - Updated to handle multilingual content **Testing:** - Switch between /en/knowledge and /de/knowledge - Titles and content should translate - Proper names (e.g., "Awareness Through Movement") remain unchanged Commits: 27a2506, 4aebd06, 039a83f, 136ef0d
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Kalle/ATM#21
No description provided.