Suggestion for all the "Language" files

[Pairi Daiza]

Hello everyone,

Since all "Language" files are encoded in" UTF-8", the value of "LanguageCodePage=" should not be: "LanguageCodePage=0", nor "LanguageCodePage=932", nor "LanguageCodePage=1252", etc...

It should be uniform: "LanguageCodePage=65001" for all "Language" files encoded in" UTF-8".

Simply because the CodePage for "UTF-8 encoding" (with or without a BOM) is "65001".

Sincerely,

[Gavin Lambert]

On Wednesday, August 27, 2025 at 5:40:51 AM UTC+12 Pairi Daiza wrote:

Since all "Language" files are encoded in" UTF-8", the value of "LanguageCodePage=" should not be: "LanguageCodePage=0", nor "LanguageCodePage=932", nor "LanguageCodePage=1252", etc...

It should be uniform: "LanguageCodePage=65001" for all "Language" files encoded in" UTF-8".

Is this just for philosophical reasons, or did you encounter a specific issue because of this?

AFAIK, having an ANSI-encoded MessagesFile is still supported, and the LanguageCodePage is required in order to decode these.  Bear in mind that beyond the files provided with Inno itself, there may be additional unofficial language files around, as well as application-specific files (where they've chosen to use an external file instead of inlining custom messages within the script).  What you're proposing would break any of these legacy files that haven't already been converted to UTF-8.

This also applies to other supporting files like license files and info files, incidentally, which are even more likely to have application-specific legacy ANSI files floating around.

Note that the value of LanguageCodePage is ignored for files that are already UTF-8, so simply converting the language file itself is not a good reason to change it.

[Pairi Daiza]

>>  Is this just for philosophical reasons, or did you encounter a specific issue because of this?

It was just a suggestion.
No particular problem. All my language files have been encoded in UFT-8 for a long-time.

Now I can understand that you're keeping LanguageCodePage=nnnn for compatibility reasons.

Keep in mind: "ANSI encoded" is the past and "UTF-8 encoded" is the future...

This post may be closed.

[Martijn Laan]

Hi,

Op 27-8-2025 om 09:36 schreef Pairi Daiza:

All my language files have been encoded in UFT-8 for a long-time.

As Gavin explained, you should always set LanguageCodePage properly, it doesn’t matter if your language file is UTF-8 encoded or not.

Setting it to 65001 is always wrong, so don't do that.

Greetings,
Martijn

[Pairi Daiza]

>>   Setting it to 65001 is always wrong, so don't do that.

OK, I will follow your advice.

Greetings

hpwamr