Let’s not forget about compiler errors. They will obviously have to be in the same language as the translation unit and refer to the original i.e. untranslated program elements.

From: Tom Honermann <tom_at_[hidden]>
Sent: Tuesday, July 30, 2019 11:19 AM
To: JeanHeyd Meneide <phdofthehouse_at_[hidden]>; keld_at_[hidden]
Cc: Lev Minkovsky <lminkovsky_at_[hidden]>; unicode_at_[hidden] <unicode_at_[hidden]>
Subject: Re: [SG16-Unicode] Ideas for the future

On 7/30/19 10:57 AM, JeanHeyd Meneide wrote:

     At the moment, achieving language-specific keywords could be done as a translation layer just before the compiler actually grabs the source. That might be a worthwhile endeavor -- and something actually programmable in standard C++, come C++26 -- that will enable people of different languages to start in their native language when working with C++. And it could be accommodated in a similar fashion in the Standard itself: "translation" already happens of Unicode Characters in your source program to \U-escaped basic character set source blob. The compiler runs (theoretically, compilers are allowed to just skip this if they "understand" the characters anyhow) on this basic character set blob, allowing the processing to be portable. This could be one of the things included in that "{language specific keywords} -> basic source character set keywords" conversion.

Arguably, we already have a solution for this:

$ cat russian-keywords.h
#define цел int
#define главная main
#define печать printf

gcc -include russian-keywords.h ...

:)

(not really serious)

Tom.