Comment by zahlman
8 hours ago
I knew from the headline that this would be the Turkish I thing, but I couldn't fathom why a compiler would care about case-folding. "I don't know Kotlin, but surely its syntax is case-sensitive like all the other commonly used languages nowadays?"
> The code is part of a class named CompilerOutputParser, and is responsible for reading XML files containing messages from the Kotlin compiler. Those files look something like this:
"Oh."
"... Seriously?"
As if I didn't hate XML enough already.
what do you propose to handle translation messages? how do you think they should map the compiler codes to human messages?
.NET ResX localization generates a source file. So localized messages are just `Resources.TheKey` - a named property like anything else in the language. It also catches key renaming bugs because the code will fail to compile if you remove/rename a key without updating users.
... Just about anything else? The baseline expectation in other data formats is that keys are case-sensitive. (Also, that there are keys, specifically designed for lookup of the needed data, rather than tag names.)
>https://www.w3.org/TR/REC-xml/
>match
>[Definition: (Of strings or names:) Two strings or names being compared are identical. Characters with multiple possible representations in ISO/IEC 10646 (e.g. characters with both precomposed and base+diacritic forms) match only if they have the same representation in both strings. No case folding is performed.
I'm quite fond of XML myself, and this is not an issue in XML.
I mean, yes, the standard says that parsing should be case sensitive (I also found https://stackoverflow.com/questions/7414747). But people parse it as if it were case insensitive all the time, in part thanks to tradition established by HTML. In this case, the XML looked like
and other code would try to filter the messages for presentation. And it appears that even if their spec demanded uppercase tag names, they were case-folding them for lookup purposes (to map "INFO" to some constant like CompilerMessageSeverity.INFO, or something like that).