- Welcome to Pelles C forum.
Pelles C forum
News:
Download Pelles C here: http://www.pellesc.se
Recent posts
#71
Work in progress / Re: Pelles C in russian
Last post by John Z - August 16, 2026, 09:45:08 PMQuote from: rubidus on August 15, 2026, 05:51:56 PMHi — same situation here. I'm working on a Korean (rsrc0012.dll, ko-KR) translation of the Pelles C IDE language pack and the compiler help.
If you are doing these translations professionally you might look at CHM EDITOR PRO, it purports to be able to edit .chm files intact with all html code untouched WYSIWYG and invisible much like an RTF editor. It also claims in line translation capability using a Google API. A bit pricey for a private individual perhaps, so I've not yet acquired it. I would like to though
- There is another thread or two about converting to Chinese which might have some tips, forum member ander_cc for example here: https://forum.pellesc.de/index.php?topic=11776.msg42219#msg42219.
John Z
#72
Work in progress / Re: Pelles C in russian
Last post by Dadatel - August 16, 2026, 03:26:04 AMwell i don't know but resource hacker works(but there's a lot of strings from what you've said( ) but i will try da things that you've said
thanks
thanks
#73
Work in progress / Re: Pelles C in russian
Last post by rubidus - August 15, 2026, 05:51:56 PMHi — same situation here. I'm working on a Korean (rsrc0012.dll, ko-KR) translation of the Pelles C IDE language pack and the compiler help. I've finished a first pass of both, and what's left is review. I don't want to publish anything without Pelle's permission, though, so I sent him a forum PM(personal message) a while back. No reply yet, and he doesn't seem to log in often, so I expect he's just busy.
Does anyone know a better way to reach him — a preferred email address, or a board he follows more closely? I'd rather wait for his answer than release anything without it.
Just to be clear, this isn't a request for help — the DLL and the CHM both work on my side; the only open question is Pelle's, and it's entirely his to answer whenever he has time.
[Edit] Since this thread is about translating Pelles C, here are notes from doing the Korean one. Some of these cost us real time.
--- LANGUAGE PACK (the DLL) ---
The number in rsrc00NN is the Windows primary language ID in hex: English is LANG_ENGLISH 0x09, hence rsrc0009. Korean is 0x12, so ours is rsrc0012; Russian is 0x19, so yours would be rsrc0019. Set LANGUAGE LANG_RUSSIAN,SUBLANG_DEFAULT in the .rc, rename eng.* to your prefix, and retarget the references in the .ppj and .ppx. Leave ids.h alone.
Don't hand-edit the .rc. Extract every quoted string together with its line and column span, translate in a table, and substitute back mechanically. The file is UTF-16LE with BOM and the line structure has to survive; a spreadsheet round trip is far safer than editing 2,800 strings in place.
Then verify mechanically, on every string:
- format specifiers (%d, %ls) — same ones, same order
- escapes (\t, \n)
- the accelerator & — same count, and no duplicates inside one dialog
- file filters like "Include file (*.h)|*.h|" — the | structure and patterns
- trailing colons, ellipses, and shortcut suffixes such as \tCtrl+X
We run this over all 2,834 strings; it catches things the eye slides past.
Watch for the same English string needing different translations in different dialogs — and the reverse. We shipped "Command line arguments:" translated two different ways in two dialogs before a check caught it. Keep the resource name and control symbol next to every string so you can tell them apart.
Finally, translated labels are usually longer than the English, and dialog controls are fixed size, so plan on checking dialogs in the IDE for clipping.
--- HELP FILE (the CHM) ---
chmls extracts, chmcmd compiles; both come with Free Pascal and script well. Microsoft's HTML Help Workshop also works.
Before translating anything, prove you can put it back: extract, reassemble unchanged, and compare byte for byte with the original. If that fails, whatever you translate afterwards sits on sand.
Cut at paragraphs, not at HTML text nodes. Our first attempt translated each text node separately, so "The <b>strcpy</b> function copies <i>src</i>." arrived as five fragments with no context, and nothing rescues that. Take the paragraph as one unit and turn inline markup into numbered placeholders, e.g. "The <g1>strcpy</g1> function copies <g2>src</g2>." — the translator keeps the count and numbering but may move them, which matters when word order differs.
Counting placeholders will not catch everything: we had one paragraph where <g1>string2</g1> came back as <g1>string1</g1>, so the wcsstr page described the wrong argument. Compare identifiers between source and translation separately.
Encoding: pages declare windows-1252. Rewrite the meta charset to your codepage and set Language= in the .hhp to match — the contents tree and the search index depend on it.
In the .hhp, don't list .hhc/.hhk under [FILES] if you already name them with Contents file= / Index file=; ours ended up stored twice. And compare your archive's internals against the original with `chmls list` before shipping.
Deduplicate: 61,793 paragraph blocks, but only 29,779 distinct. Translating each unique string once saved about 18% and made the result consistent.
Do the DLL first if you're doing both. The help names menu items constantly, and those names must read exactly as they do in your translated IDE. We found 157 places where the help had invented its own wording — correct translations, but not what the screen said.
One last thing: a finished CHM that opens blank or seems to hang is usually Windows' mark-of-the-web, not a bad build. Properties, then Unblock.
Does anyone know a better way to reach him — a preferred email address, or a board he follows more closely? I'd rather wait for his answer than release anything without it.
Just to be clear, this isn't a request for help — the DLL and the CHM both work on my side; the only open question is Pelle's, and it's entirely his to answer whenever he has time.
[Edit] Since this thread is about translating Pelles C, here are notes from doing the Korean one. Some of these cost us real time.
--- LANGUAGE PACK (the DLL) ---
The number in rsrc00NN is the Windows primary language ID in hex: English is LANG_ENGLISH 0x09, hence rsrc0009. Korean is 0x12, so ours is rsrc0012; Russian is 0x19, so yours would be rsrc0019. Set LANGUAGE LANG_RUSSIAN,SUBLANG_DEFAULT in the .rc, rename eng.* to your prefix, and retarget the references in the .ppj and .ppx. Leave ids.h alone.
Don't hand-edit the .rc. Extract every quoted string together with its line and column span, translate in a table, and substitute back mechanically. The file is UTF-16LE with BOM and the line structure has to survive; a spreadsheet round trip is far safer than editing 2,800 strings in place.
Then verify mechanically, on every string:
- format specifiers (%d, %ls) — same ones, same order
- escapes (\t, \n)
- the accelerator & — same count, and no duplicates inside one dialog
- file filters like "Include file (*.h)|*.h|" — the | structure and patterns
- trailing colons, ellipses, and shortcut suffixes such as \tCtrl+X
We run this over all 2,834 strings; it catches things the eye slides past.
Watch for the same English string needing different translations in different dialogs — and the reverse. We shipped "Command line arguments:" translated two different ways in two dialogs before a check caught it. Keep the resource name and control symbol next to every string so you can tell them apart.
Finally, translated labels are usually longer than the English, and dialog controls are fixed size, so plan on checking dialogs in the IDE for clipping.
--- HELP FILE (the CHM) ---
chmls extracts, chmcmd compiles; both come with Free Pascal and script well. Microsoft's HTML Help Workshop also works.
Before translating anything, prove you can put it back: extract, reassemble unchanged, and compare byte for byte with the original. If that fails, whatever you translate afterwards sits on sand.
Cut at paragraphs, not at HTML text nodes. Our first attempt translated each text node separately, so "The <b>strcpy</b> function copies <i>src</i>." arrived as five fragments with no context, and nothing rescues that. Take the paragraph as one unit and turn inline markup into numbered placeholders, e.g. "The <g1>strcpy</g1> function copies <g2>src</g2>." — the translator keeps the count and numbering but may move them, which matters when word order differs.
Counting placeholders will not catch everything: we had one paragraph where <g1>string2</g1> came back as <g1>string1</g1>, so the wcsstr page described the wrong argument. Compare identifiers between source and translation separately.
Encoding: pages declare windows-1252. Rewrite the meta charset to your codepage and set Language= in the .hhp to match — the contents tree and the search index depend on it.
In the .hhp, don't list .hhc/.hhk under [FILES] if you already name them with Contents file= / Index file=; ours ended up stored twice. And compare your archive's internals against the original with `chmls list` before shipping.
Deduplicate: 61,793 paragraph blocks, but only 29,779 distinct. Translating each unique string once saved about 18% and made the result consistent.
Do the DLL first if you're doing both. The help names menu items constantly, and those names must read exactly as they do in your translated IDE. We found 157 places where the help had invented its own wording — correct translations, but not what the screen said.
One last thing: a finished CHM that opens blank or seems to hang is usually Windows' mark-of-the-web, not a bad build. Properties, then Unblock.
#74
Work in progress / Re: Pelles C in russian
Last post by Dadatel - August 14, 2026, 10:55:53 PMwell im already translating it(well if this dll is da pack or i will just fuck everything up), but still thank you
may the source be with you
may the source be with you
#75
Work in progress / Re: Pelles C in russian
Last post by TimoVJL - August 14, 2026, 10:21:40 PMJust download translation project with rsrc file from http://www.pellesc.se/ and translate it for language dll.
#76
Work in progress / Pelles C in russian
Last post by Dadatel - August 14, 2026, 06:29:42 PMso, im gonna just patch rsrc0009.dll
right now not a bit of result is done but still
if ya can help me then just idk dm me on discord:
dadatel.cs
#77
Beginner questions / Re: Working Directory woes
Last post by PhilG57 - August 13, 2026, 12:52:56 AMSorry for the long delayed response; I work a bit during the summer and don't get to play as much as I would like.
Your ideas are spot on but don't seem to make a difference. When opening the dialog, I am shown as default one of my parent directories. This HAS to be a screw-uo on my part but it will take me some time to find my bug. Many thanks.
Your ideas are spot on but don't seem to make a difference. When opening the dialog, I am shown as default one of my parent directories. This HAS to be a screw-uo on my part but it will take me some time to find my bug. Many thanks.
#78
Tips & tricks / Re: An old code
Last post by Vortex - August 12, 2026, 08:41:05 AMHi Timo,
Nice work.
Nice work.
#79
Tips & tricks / An old code
Last post by TimoVJL - August 11, 2026, 04:04:21 PMAn IFileOpenDialog example from year 2015.
Not sure why i have even made test with this code
EDIT: IFileOpenDialog2.zip compiled with Pelles C 14.50
Not sure why i have even made test with this code
EDIT: IFileOpenDialog2.zip compiled with Pelles C 14.50
#80
Announcements / Re: CMake 4.4.0 Supports Pelle...
Last post by larryli - August 07, 2026, 08:53:54 AMCMake 4.4 adds native recognition of the Pelles C compiler (compiler id PellesC), so CMake can configure and drive Pelles C builds without extra toolchain files. However, this support is limited to CMake's own generators — specifically Ninja (and other CMake-generated build systems). CMake does not generate or drive Pelles C's native IDE project format (.ppj); building a .ppj still requires Pelles C's own pomake tool, independent of CMake.