Content deleted Content added
→Decimal input (Windows): Workarounds there are plenty; but why are they needed? |
→Decimal input (Windows): worse than misleading while it remains unqualified |
||
Line 156:
:::::{{re|Ozaru}} Have you considered using a [[script language]]? I have an [[Autohotkey]] script that runs by default; I use it for [[em dash]]es among many other things. The Autohotkey script to make {{keypress|Cntl|F}} produce a {{char|£}} would be just {{code|^f::£}}. [[User:Peter M. Brown|Peter Brown]] ([[User talk:Peter M. Brown|talk]]) 00:37, 15 September 2020 (UTC)
::::::There are plenty of ''workarounds'' (e.g. {{key press|Windows}}+{{key press|Space}} to switch to UK/US, {{key press|Alt}}+{{key press|0}}{{key press|1}}{{key press|6}}{{key press|3}} then {{key press|Windows}}+{{key press|Shift}}+{{key press|Space}} to switch back; or phonetically entering ぽんど into the [[Input method|IME]] and hitting {{key press|Space}} one or more times to select the right symbol, or Autohotkey as you say). The issue is more that despite the best intentions of moving from 8-bit [[SBCS]] to 16-bit [[DBCS]] and standardizing with Unicode while computers themselves become 32 and 64-bit... it still seems impossible to break free from the 8-bit codepage legacy, which I find incredible. It's amazing (not to say inconvenient) that even now, [[Visual Basic for Applications|VBA]] Editor doesn't support Unicode, [[Microsoft Excel|Excel]] can't save Unicode CSV files, and basic Windows 10 dialogs etc. don't have a simple, in-built way for Unicode input. So much for [[I18N]]. [[User:Ozaru|Ozaru]] ([[User talk:Ozaru|talk]]) 05:55, 15 September 2020 (UTC)
:::::::Couldn't put it better myself (I didn't!). As already noted, the £ glyph is just a random example, the issue is widespread. Which takes me back to my first challenge to the section. It is worse than misleading while it remains unqualified. --[[User:John Maynard Friedman|John Maynard Friedman]] ([[User talk:John Maynard Friedman|talk]]) 16:05, 15 September 2020 (UTC)
| |||