FWH 26.08 day 4 Language problems (solved)

[alerchster]

fivedbu or testlang, compiled with Harbour and BCC or MSVC 32- and 64-bit.

All language problems are back and visible. Same as seen in fwh 26.03!

[Antonio Linares]

Dear Anton,

Yes, we also noticed it, thank you.

When AI modify strings.prg, it does not respect CP1252. So if we forget to tell AI about it, then the problem is back.

We are going to save a skill not to forget it.

many thanks!

[Antonio Linares]

.claude\skills\edit-strings\SKILL.md

Code: Select all | Expand

---
name: edit-strings
description: Edit strings.prg preserving CP1252 encoding (accented chars as single bytes)
disable-model-invocation: false
argument-hint: [description of the edit to make]
allowed-tools: Bash, Read, Edit, Write
---

Edit `source/function/strings.prg` always preserving CP1252 encoding.

## Why CP1252?

`strings.prg` contains multi-language translations with accented characters
(ñ, á, é, ü, ß, etc.). The Harbour compiler expects these as **single bytes**
in CP1252 (e.g., ñ=F1, ä=E4, ü=FC, ó=F3). If saved as UTF-8, accented chars
become multi-byte sequences and break the compiled strings.

## Rules

1. **Never save strings.prg as UTF-8.** Always use CP1252 (codepage 1252).
2. **No BOM.** The file must not have a UTF-8 BOM.
3. **Accented chars are single bytes:** ñ=F1, á=E1, é=E9, ü=FC, ß=DF, etc.
4. When using the Edit tool, changes preserve encoding automatically.
5. When writing the full file, use the PowerShell helper below.

## PowerShell helper to save as CP1252

When a full rewrite is needed, use this script to write CP1252:

```powershell# Save content as CP1252 (no BOM)
$content = Get-Content -Raw -Path 'temp_strings.txt'
$cp1252 = [System.Text.Encoding]::GetEncoding(1252)
[System.IO.File]::WriteAllText('C:\fwteam\source\function\strings.prg', $content, $cp1252)```

## Edit workflow

1. Read the file with the Read tool (it will show `?` for accented chars — this is normal).
2. Make edits using the Edit tool (preserves encoding).
3. Verify the file is still CP1252 after editing:
   ```powershell   $b = [System.IO.File]::ReadAllBytes('C:\fwteam\source\function\strings.prg')
   $hasBOM = ($b[0] -eq 0xEF -and $b[1] -eq 0xBB -and $b[2] -eq 0xBF)
   if ($hasBOM) { Write-Error "ERROR: File has UTF-8 BOM!" }
   else { Write-Output "OK: No BOM detected" }   ```

## Quick reference: CP1252 accented chars

| Char | Byte | Char | Byte | Char | Byte |
|------|------|------|------|------|------|
| ñ | F1 | á | E1 | é | E9 |
| í | ED | ó | F3 | ú | FA |
| ü | FC | ä | E4 | ö | F6 |
| ß | DF | à | E0 | è | E8 |
| ñ | F1 | ¡ | A1 | ¿ | BF |

## Critical

- The CLAUDE.md states: `source/function/strings.prg MUST be CP1252 encoded (not UTF-8).`
- Previous commits have been reverted due to UTF-8 corruption (see commit `2743fd36d`).

[alerchster]

FWH 26.08 day 9
fivedbu or testlang, compiled with Harbour and BCC or MSVC 32 problem not solved?

[Antonio Linares]

Dear Anton,

strings.prg seems ok with proper CP1252 enconding

What error do you get ?

many thanks

[alerchster]

The same errors are present as in version 26.03; some characters (äüö...) are not displayed correctly. In version fwh 26.08 day 9, only fiveH.lib, fiveH32.lib, fiveHC32.lib, and fiveHX.lib were regenerated on August 9, 2026; all other lib files are older. It's also possible that strings.prg wasn't modified, and therefore strings.obj wasn't regenerated...

[alerchster]

FWH 26.08 day 10
fivedbu or testlang, compiled with Harbour and BCC or MSVC 32 problem solved!

[Antonio Linares]

Dear Anton,

Please download it again

many thanks

[alerchster]

solved