Hello All!

Let's say I have compiled a new version of GoldED. Currently I have two groups (Group A and Group B).

My setup is:

OS uses UTF-8

GoldED is started through luit using, for example, a standard ISO charset

Groups A and B use XLATCHARSET for conversion between the OS charset and a non-standard charset

As I understand it, luit should no longer be necessary.How should I configure the new GoldED while remaining fully compatible with my existing setup?Ideally, I would like to:

Use iconv-based charset conversion for most groups.

Keep some groups using the existing OS non-standard charset conversion (including kludge lines).

I have checked the available documentation (for example, the documentation bundled with the GoldED binaries), but I still see references to the old approach involving luit and related settings.

Could someone explain the recommended way to configure this in current GoldED versions?

Karel

--- GoldED+/LNX 1.1.5-b20240209
* Origin: Plast DATA (2:423/39)

Hello Karel!

Sunday September 13 2026 08:58, you wrote to All:

Let's say I have compiled a new version of GoldED. Currently I have
two groups (Group A and Group B).

My setup is:

OS uses UTF-8

GoldED is started through luit using, for example, a standard ISO
charset

Groups A and B use XLATCHARSET for conversion between the OS charset
and a non-standard charset

As I understand it, luit should no longer be necessary.How should I configure the new GoldED while remaining fully compatible with my
existing setup?Ideally, I would like to:

Use iconv-based charset conversion for most groups.

Keep some groups using the existing OS non-standard charset
conversion (including kludge lines).

I have checked the available documentation (for example, the
documentation bundled with the GoldED binaries), but I still see references to the old approach involving luit and related settings.

Could someone explain the recommended way to configure this in current GoldED versions?

Just comment the all XlatCharSet settings.

// In the first line of config set the config chatset, e.g:
XlatConfigSet LATIN-2

// Set the defaults:

// Chatset of your OS:
XlatLocalSet UTF-8

// Set the default import and export charsets:
XlatImport LATIN-2
XlatExport LATIN-2

// For groups the same:
GROUP UTF-8:
MEMBER UTF-8, UTF8.FTN.MESSAGING
XLATIMPORT UTF-8
XLATEXPORT UTF-8
ENDGROUP

No luit is needed, just run the golded binary

Eugene

... It's full of stars!
--- GoldED+/BSD 2.0.0-b20260912 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hello Eugene!

13 Sep 26 13:32, you wrote to me:

// In the first line of config set the config chatset, e.g:
XlatConfigSet LATIN-2

// Set the defaults:

// Chatset of your OS:
XlatLocalSet UTF-8

// Set the default import and export charsets:
XlatImport LATIN-2
XlatExport LATIN-2

OK, started step by step. OS is UTF-8.

GROUP C
XLATPATH /home/fido/golded/xlat
XLATCHARSET CP895 LATIN-2 kam_il2.chs
XLATCHARSET LATIN-2 CP895 il2_kam.chs
XLATIMPORT CP895
XLATEXPORT CP895
XLATLOCALSET UTF-8
XlatConfigSet LATIN-2
ENDGROUP

In that group "CP895" is compulsory. Does not work. Kludge is OK, what I see is rubish.

(even if I try LANG=cs_CZ.ISO8859-2 - or even if I put original command - luit -encoding 'ISO-8859-2' ./golded -f I had before).

Karel

--- GoldED+/LNX 1.1.5-b20240209
* Origin: Plast DATA (2:423/39)

Hello Karel!

Tuesday September 15 2026 11:48, you wrote to me:

OK, started step by step. OS is UTF-8.

GROUP C
XLATPATH /home/fido/golded/xlat
XLATCHARSET CP895 LATIN-2 kam_il2.chs
XLATCHARSET LATIN-2 CP895 il2_kam.chs
XLATIMPORT CP895
XLATEXPORT CP895
XLATLOCALSET UTF-8
XlatConfigSet LATIN-2
ENDGROUP

In that group "CP895" is compulsory. Does not work. Kludge is OK, what
I see is rubish.

(even if I try LANG=cs_CZ.ISO8859-2 - or even if I put original
command - luit -encoding 'ISO-8859-2' ./golded -f I had before).

The config cannot work as written, and the reason is simple. GoldED+ 2.0.0 asks iconv first for every conversion.
A *.CHS table is used only when iconv has no converter for the pair, and it looks for an XLATCHARSET line naming exactly the pair it needs. In a UTF-8 session the pair for reading is CP895 -> UTF-8. Your tables are CP895 <-> LATIN-2, so nothing ever uses them: the log says "No recoder from CP895 to UTF-8; falling back to charset tables", finds none, and shows the text unconverted. That is the rubbish.

A few more things in what you posted. XLATCHARSET, XLATPATH, XLATLOCALSET and XLATCONFIGSET are global keywords.
Inside a GROUP they are read as global settings at that point of the file, and XLATLOCALSET/XLATCONFIGSET must be the first lines of golded.cfg, before anything non-ASCII, or everything above them is read in another charset.
Only XLATIMPORT and XLATEXPORT belong in a GROUP. XLATCONFIGSET LATIN-2 says golded.cfg itself is LATIN-2 - if the file is UTF-8, say UTF-8.
And luit or LANG=cs_CZ.ISO8859-2 translate the terminal while XLATLOCALSET UTF-8 tells GoldED+ the terminal is UTF-8. The two undo each other, use one or the other.

There are five tables in GoldED+'s CHS: kam_u8.chs (CP895 -> UTF-8), kam_852.chs and 852_kam.chs (CP895 <-> CP852), kam_il2.chs and il2_kam.chs (CP895 <-> LATIN-2). Letters follow the Kamenick² layout, 0xB0-0xFF are the CP437 box characters as in CP895:

https://drive.google.com/file/d/1WrQYRsw7p4q5yfceqgISClMHl_RLHuEJ/view?usp=sharing

For your UTF-8 session put at the top of golded.cfg

XLATLOCALSET UTF-8
XLATCONFIGSET UTF-8
XLATPATH /home/fido/golded/xlat
XLATCHARSET CP895 UTF-8 kam_u8.chs
XLATCHARSET CP895 LATIN-2 kam_il2.chs
XLATCHARSET LATIN-2 CP895 il2_kam.chs
XLATCHARSET CP852 CP895 852_kam.chs
XLATCHARSET CP895 CP852 kam_852.chs
XLATCHARSETALIAS CP895 KAMENICKY KEYBCS2 NEC-867 DOS-895

And in the group:

GROUP C
XLATIMPORT CP895
XLATEXPORT CP852
ENDGROUP

CP895 messages then read correctly and what you write goes out as CP852 with a proper CHRS kludge. Writing CP895 from a UTF-8 session is not possible with a table now (I'll add reverse-encoding later): a CHS table maps one byte to up to three, so it can turn a CP895 byte into a UTF-8 character but cannot read a UTF-8 character, which is several bytes. With XLATEXPORT CP895 in a UTF-8 session GoldED+ finds no converter and writes UTF-8 with "CHRS: UTF-8 4".

If an area REALLY has to stay CP895, run an 8-bit session instead:

XLATLOCALSET LATIN-2
XLATCONFIGSET LATIN-2
XLATPATH /home/fido/golded/xlat
XLATCHARSET CP895 UTF-8 kam_u8.chs
XLATCHARSET CP895 LATIN-2 kam_il2.chs
XLATCHARSET LATIN-2 CP895 il2_kam.chs
XLATCHARSET CP852 CP895 852_kam.chs
XLATCHARSET CP895 CP852 kam_852.chs
XLATCHARSETALIAS CP895 KAMENICKY KEYBCS2 NEC-867 DOS-895

Then XLATIMPORT and XLATEXPORT CP895 in the group:

GROUP C
XLATIMPORT CP895
XLATEXPORT CP895

And a any terminal showing ISO-8859-2 (or luit). Then both directions go through the tables and a written message carries "CHRS: CP895 2". CP852 works the same way with the 852 tables.

But PLEASE do not post CP895 messages to Fidonet!
Neither the Fidonet standard FTS-5003 nor IANA recognizes this encoding.
Nobody else has a table for it - iconv, Windows and OS/2 do not know the charset - so every other reader, GoldED+ without tables included, shows a CP895 message as rubbish, exactly what you saw.

Czech and Slovak messages in Fidonet are CP852 written on the DOS systems ("CHRS: CP852 2") or LATIN-2 (AKA ISO 8859-2) written on any other OS ("CHRS: LATIN-2 2"), and GoldED+ 2.0.0 reads and writes both without any tables:

GROUP C
XLATIMPORT LATIN-2
XLATEXPORT LATIN-2

The tables are for reading old CP895 mail. So, please write only in CP852, LATIN-2 or UTF-8.

Eugene

... It's full of stars!
--- GoldED+/BSD 2.0.0-b20260912 (NetBSD 11.0 Intel Xeon Icelake)
* Origin: FireFox Station (2:5075/35)

Hello Eugene!

15 Sep 26 14:06, you wrote to me:

1st of all - thank you for detaild explanation and help.

CP895 messages then read correctly and what you write goes out as
CP852 with a proper CHRS kludge. Writing CP895 from a UTF-8 session is
not possible with a table now (I'll add reverse-encoding later): a CHS

Then I will wait for it. I thought conversion between 1 byte and "more than one byte" encoding is that big move in new Golded+ approach.

If an area REALLY has to stay CP895, run an 8-bit session instead:

As I have now. In regio42 areas I can use encoding. In International keep 7bit virtual ASCII. And forget about UTF8.

But PLEASE do not post CP895 messages to Fidonet!

This I can not agree. It is about moderators of each echomail conference and its rules. For r42 is only alowed CP895 (since ever). I did some investigation since my rc42 and will not change.

Neither the Fidonet standard FTS-5003 nor IANA recognizes this

Checking that FTS - 7.4.2012 - far after CodePage was stabilized in r42. FTS should not be accepted in that shape, that time.

encoding. Nobody else has a table for it - iconv, Windows and OS/2 do
not know the charset - so every other reader, GoldED+ without tables included, shows a CP895 message as rubbish, exactly what you saw.

I am using that code page since ever (in fidonet). See proper and use characters. I wondered if new Golded+ can help me to live with OS in UTF - which can not so far.

What must be done: 1) add CP895 into iconv and 2) get Golded+ working with 1byte against UTF and back conversion

It reminded me situation I was supporting big International (ok, German) company starting to sell ecom in .cz They simply refused czech coding, using pure English... Until Czech Post (they contracted) simply refused to deliver ;-) We can say that CP895 is not alllowed in Fidonet since 2012 - but is used in r42 since ever and until now - on all (active) Nodes and Points.

Karel

--- GoldED+/LNX 1.1.5-b20240209
* Origin: Plast DATA (2:423/39)

Hello Karel!

Saturday September 19 2026 08:29, you wrote to me:

CP895 messages then read correctly and what you write goes out as
CP852 with a proper CHRS kludge. Writing CP895 from a UTF-8
session is not possible with a table now (I'll add
reverse-encoding later): a CHS

Then I will wait for it. I thought conversion between 1 byte and "more than one byte" encoding is that big move in new Golded+ approach.

Reverse encoding was added in the latest release

If an area REALLY has to stay CP895, run an 8-bit session
instead:

As I have now. In regio42 areas I can use encoding. In International
keep 7bit virtual ASCII. And forget about UTF8.

But PLEASE do not post CP895 messages to Fidonet!

This I can not agree. It is about moderators of each echomail
conference and its rules. For r42 is only alowed CP895 (since ever). I
did some investigation since my rc42 and will not change.

Neither the Fidonet standard FTS-5003 nor IANA recognizes this

Checking that FTS - 7.4.2012 - far after CodePage was stabilized in
r42. FTS should not be accepted in that shape, that time.

But it does.

encoding. Nobody else has a table for it - iconv, Windows and
OS/2 do not know the charset - so every other reader, GoldED+
without tables included, shows a CP895 message as rubbish,
exactly what you saw.

I am using that code page since ever (in fidonet). See proper and use characters. I wondered if new Golded+ can help me to live with OS in
UTF - which can not so far.

What must be done: 1) add CP895 into iconv and 2) get Golded+ working
with 1byte against UTF and back conversion

No one will ever add this encoding to iconv or the Windows distribution: it┤s used too rarely.
Reversible encoding should work, so this encoding can be used with a conversion table.

It reminded me situation I was supporting big International (ok,
German) company starting to sell ecom in .cz They simply refused czech coding, using pure English... Until Czech Post (they contracted)
simply refused to deliver ;-) We can say that CP895 is not alllowed in Fidonet since 2012 - but is used in r42 since ever and until now - on
all (active) Nodes and Points.

It's clear. Why didn┤t they switch to the standardized CP850?

Eugene

... It's full of stars!
--- GoldED+/BSD 2.0.0-b20260912 (NetBSD 11.0 Intel Xeon Icelake)
* Origin: FireFox Station (2:5075/35)

Hello Karel,

On 19 Sep 26 08:29, you wrote to Eugene Subbotin:

Then I will wait for it. I thought conversion between 1 byte and "more than one byte" encoding is that big move in new Golded+ approach.

You have to realize that in many cases conversion between one byte set and UTF-8 is a one way street. Ever so often conversion from UTF-8 to one byte set is not possible because it does not fit.

But PLEASE do not post CP895 messages to Fidonet!

This I can not agree. It is about moderators of each echomail
conference and its rules. For r42 is only alowed CP895 (since ever). I
did some investigation since my rc42 and will not change.

That is for the sysops of R42 to decide.

Neither the Fidonet standard FTS-5003 nor IANA recognizes this

Checking that FTS - 7.4.2012 - far after CodePage was stabilized in
r42. FTS should not be accepted in that shape, that time.

If the sysops of Region 42 wanted CP895 included they should have spoken in april 2012 when the draft for FTS-5003.001 was published. Now that the FTSC has stopped documenting current practise it is too late.

encoding. Nobody else has a table for it - iconv, Windows and
OS/2 do not know the charset - so every other reader, GoldED+
without tables included, shows a CP895 message as rubbish,
exactly what you saw.

I am using that code page since ever (in fidonet). See proper and use characters. I wondered if new Golded+ can help me to live with OS in
UTF - which can not so far.

What must be done: 1) add CP895 into iconv

Considering that CP895 is a bit of an oddball not recognised in most of the rest of the world, that is not likely to happen. Also because almost anywone outside Fidonet has already made the switch to UTF-8 many years ago. Nobody will invest time and energy in reviving obsolete 8 bit characters sets.

and 2) get Golded+ working with 1byte against UTF and back conversion

That will be a waste of time and energy. Just skip that fase and go directly to UTF-8. That is the future for Fidonet. For the rest of the digital world UTF-8 already is the present.


Cheers, Michiel

--- GoldED+/W32-MINGW 2.0.0-b20260917
* Origin: Nieuw Schnøørd (2:280/5555)

Hello Eugene,

On 19 Sep 26 09:35, you wrote to Karel Kral:

@MSGID: 2:5075/35@fidonet 6aae2e54
@REPLY: 2:423/39 6aae2bd1
@CHRS: LATIN-2 2
@TZUTC: 0300
@REALNAME: ??????? ????????

So... Conversion from UTF-8 to LATIN-2 does no work in this case...

Answering in the charset of the message that was answered to may not be the answer...


Cheers, Michiel

--- GoldED+/W32-MINGW 2.0.0-b20260917
* Origin: Nieuw Schnøørd (2:280/5555)

Hello Michiel!

codepage 895 is not well standardized. The Japan implementation of it is quite different from the Czech one.

Chris


--- Binkd, FMail, Golded+
* Origin: https://drschrisjacobs.nl (2:280/5555.11)

Hello Michiel!

Saturday September 19 2026 12:21, you wrote to me:

@MSGID: 2:5075/35@fidonet 6aae2e54
@REPLY: 2:423/39 6aae2bd1
@CHRS: LATIN-2 2
@TZUTC: 0300
@REALNAME: ??????? ????????

MvdV> So... Conversion from UTF-8 to LATIN-2 does no work in this case...

MvdV> Answering in the charset of the message that was answered to may not
MvdV> be the answer...

Yes. It makes sense that I can't transmit Russian characters in ASCII/CP437/CP850.


Eugene

... It's full of stars!
--- GoldED+/BSD 2.0.0-b20260912 (NetBSD 11.0 Intel Xeon Icelake)
* Origin: FireFox Station (2:5075/35)

Hello Eugene!

19 Sep 26 09:35, you wrote to me:

What must be done: 1) add CP895 into iconv and 2) get Golded+
working with 1byte against UTF and back conversion

No one will ever add this encoding to iconv or the Windows
distribution: it┤s used too rarely. Reversible encoding should work,
so this encoding can be used with a conversion table.

Somebody told me "never say never" ;-) In use of linux - why I could not add module in gconv by myself? Not sure about Windows nor OS/2.

Again, thank you for your work.

Karel

--- GoldED+/LNX 1.1.5-b20240209
* Origin: Plast DATA (2:423/39)

Hello Michiel!

19 Sep 26 11:46, you wrote to me:

That will be a waste of time and energy. Just skip that fase and go directly to UTF-8. That is the future for Fidonet. For the rest of the digital world UTF-8 already is the present.

You are (as usual) right.

Majority in r42 agreed to wait a bit longer. But that is OK.

Karel

--- GoldED+/LNX 1.1.5-b20240209
* Origin: Plast DATA (2:423/39)

Hello Karel!

Sunday September 20 2026 07:51, you wrote to me:

What must be done: 1) add CP895 into iconv and 2) get Golded+
working with 1byte against UTF and back conversion

No one will ever add this encoding to iconv or the Windows
distribution: it┤s used too rarely. Reversible encoding should
work, so this encoding can be used with a conversion table.

Somebody told me "never say never" ;-) In use of linux - why I could
not add module in gconv by myself? Not sure about Windows nor OS/2.

Again, thank you for your work.

Of course in Linux, you can write whatever you want for yourself. But I'm not sure that code like this will ever be accepted into the upstream repository. In Windows and OS/2, the set of included charsets is determined by Microsoft and IBM.

Eugene

... It's full of stars!
--- GoldED+/BSD 2.0.0-b20260912 (NetBSD 11.0 Intel Xeon Icelake)
* Origin: FireFox Station (2:5075/35)