61–70 of 300 posts
Earlier quoted context omitted.
For the record, it's a stark pronunciation difference as ł has drifted to a very different "w" sound
Yep. For example, the name of the third-largest city in Poland is "Łódź", which might look like it's pronounced "lods", but is actually pronounced more like "wootch".
Earlier quoted context omitted.
Their URL is even mikolaj-kaminski.com . I get its annoying, but I would never use non-ascii chars in a username / file path.
So, what does 阿部明仁 do in this case? Polish may be close enough that an approximation is available in English, but there's an awful lot of languages that don't have a large overlap with English characters. In the Asian case above, if someone with that name did try to "convert to English" they are ironically just as likely to end up with Ａｋｉｈｉｔｏ Ａｂｅ as the ASCII, which will be just as broken!
- IME On state. IME capture and interpret keypresses as engraved and generate corresponding Kana-Kanji texts.
- IME Off state. IME passes through keypresses as engraved on keytops.
- Direct Input state. IME becomes dormant.
In IME Off state, the keyboard behaves as a plain jp106(or ANSI if it is) keyboard, like I'm doing right now. The cases where you would use conversion with IME on for an English word is when you have reasons for the word to be in "full width"(usually for typesetting reasons).
Oh, it’s not a common knowledge that you should not UTF-8 in Windows username? That had been the case since 95 days. Only recently it had supposedly improved after Microsoft Account login become semi mandatory.
I don't think this bug is anything to do with Windows, rather it is due to the way the paths are handled in the IDE's codebase. Presumably the same problem exists when using these IDEs in conjunction with a path containing non-ascii characters in the Linux or macOS world.
Earlier quoted context omitted.
This is the modern, post-ASCII computing world, we should no longer be willing to settle for the lowest-common-denominator of ASCII-only strings. There's no excuse for actively supported, paid products to have these problems today.
True. But these actively supported, paid products build upon layers and layers of no-longer-supported, free/opensource products. Good luck fixing them. Not saying that this is OK, just explaining why using non-ascii characters, in this day and age, is still asking for trouble.
Windows 2000 is when the OS changed to UTF-16 by default. Before that Windows NT was UCS-2, IIRC only the DOS-based Windows versions were Windows-1252 internally, starting from Windows 1.0. So while ł wasn't supported in Windows 1, characters like ñ were. Windows has literally NEVER been an ASCII-based OS.
Earlier quoted context omitted.
So, what does 阿部明仁 do in this case? Polish may be close enough that an approximation is available in English, but there's an awful lot of languages that don't have a large overlap with English characters. In the Asian case above, if someone with that name did try to "convert to English" they are ironically just as likely to end up with Ａｋｉｈｉｔｏ Ａｂｅ as the ASCII, which will be just as broken!
Assuming that hypothetical guy is an average Japanese male(somewhat leaning right), he'd just turn IME off. Japanese input on desktop is consist of three following states: - IME On state. IME capture and interpret keypresses as engraved and generate corresponding Kana-Kanji texts. - IME Off state. IME passes through keypresses as engraved on keytops. - Direct Input state. IME becomes dormant. In IME Off state, the ke…
I'm sure a computer savvy speaker of a fully-non-Latin language may still guess this is a good idea, but "computer savvy" doesn't cover everyone... and they shouldn't have to.
"Just use 7-bit-clean ASCII English" is not a solution to this problem.
Earlier quoted context omitted.
True. But these actively supported, paid products build upon layers and layers of no-longer-supported, free/opensource products. Good luck fixing them. Not saying that this is OK, just explaining why using non-ascii characters, in this day and age, is still asking for trouble.
This is on the Windows version. Windows 2000 is when the OS changed to UTF-16 by default. Before that Windows NT was UCS-2, IIRC only the DOS-based Windows versions were Windows-1252 internally, starting from Windows 1.0. So while ł wasn't supported in Windows 1, characters like ñ were. Windows has literally NEVER been an ASCII-based OS.
Basically - I agree: This shouldn't be a problem, and 7 months is a long time to wait for a basic fix. But there are a lot of footguns hanging around in windows code with respect to character encodings.
Just looking at the first result on google for "c++ get windows home directory" shows this: https://docs.microsoft.com/en-us/windows/win32/api/userenv/n...
Which takes a long pointer to tchar string (LPTSTR) - so this behavior is dependent on the unicode settings of the project at compile time, even today.
Earlier quoted context omitted.
I don't know, it's just a Unicode character? Not even a newer one, it's just 2 utf8 bytes. Pretty much everything should support that in 2021. When I think of 100 things I think of stuff like "some people spell their name in all lowercase and get really funny if you change it"
Yeah so double byte characters costs extra. I don’t know, a checkbox or something default off. Always did still does. Double width costs even more.