<div dir="ltr"><div><div>     The &quot;hello world&quot; example with lots of languages looks nice to me. That can obviously be a goal of ours, in some form.<br></div><div><br>TL;DR of below: the premise of what the rest of what you&#39;re asking for is nice, but requires an insane amount of complexity in the compiler and for the language than is currently needed.<br></div><div><br>     We already have Unicode identifiers, we are already working on making text like that just work. My only problem with supporting keywords in every language means that you need to carve those keywords out of every single other language as well, reducing the amount of valid identifiers in the program by quite a bit for every language. The committee already struggles with adding even context-sensitive keywords to the standard: doing so for all languages, and writing standard library function names, concept names, variable names and class names in other languages that make sense and are not just Google Translated specifics will be a herculean effort.<br><br></div>     Your example is also lacking in examples from other languages: some of those languages are Right-To-Left, rather than Left-To-Right. Do the braces invert and show up on the other side of keywords? Do we require that a compiler needs full Bidi processing and localization handling, for each and every program? These are the hard parts of Unicode that aren&#39;t just &quot;oh, well the encoding was wrong&quot;, and requiring everyone to be mildly familiar with that so they can troubleshoot their programs and fix their compilers is probably not something that flies in the short term. We don&#39;t even have a portable &quot;char&quot; right now.<br><br></div><div>     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: &quot;translation&quot; 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 &quot;understand&quot; 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 &quot;{language specific keywords} -&gt; basic source character set keywords&quot; conversion.<br><br></div><div>     This would be difficult for the standard library, however. We already have severe problems with argument order (memcpy, anyone?): do RTL languages get them in reverse order? The same order? Is the function call on the left or the right of the function name? C++ already has a cramped parsing space. I&#39;m all for the non-English speakers having a vastly easier time, but we don&#39;t even have Named Parameters in the language to help make this less of a problem for them, let alone parsers capable of actually being able to handle more than a find-replace of keywords or function names.</div><div><br></div><div>Sincerely,</div><div>JeanHeyd<br></div><div><br></div></div>