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!
Ing. Anton Lerchster
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!
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!
.claude\skills\edit-strings\SKILL.md
---
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`).FWH 26.08 day 9 fivedbu or testlang, compiled with Harbour and BCC or MSVC 32 problem not solved?
Dear Anton,
strings.prg seems ok with proper CP1252 enconding
What error do you get ?
many thanks
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...
FWH 26.08 day 10 :idea:
fivedbu or testlang, compiled with Harbour and BCC or MSVC 32 problem solved!
Dear Anton,
Please download it again
many thanks
solved