On May 15, 2013, at 7:17 AM, David Woodhouse <[email protected]> wrote:
> On Tue, 2013-05-14 at 09:57 -0700, Andrew Fish wrote: >> I've not seen a lot of requests for setup pages localized to languages >> that have not been spoken in the last thousand years. > > It's not just about localising setup pages; we end up dealing with > arbitrary input from the OS and, ultimately, the user in this form too, > don't we? In environment variables and other input/output. > Well the firmware only deals with the variables in the UEFI spec that are in English. For variables created for others, the string might as well be a binary key, it makes no difference to the firmware as long as the GUID and the string are the same it all works. So in crazy variable name cases it is up to the publisher of the GUID to do the right thing, or at least be self consistent. From a setup point of view the output and input are known. It is also possible that a platform may only carry a sparse font to save space. So for example you cary only the Chinese characters displayed in the setup page, not the entire font. From an Simple Text In point of view the platform generally carries the mappings (USB keyboard) and fonts to display for a given language, so it is self consistent. I guess you could argue that a VT-UTF8 serial terminal (we also support xterm-256color) could have an issue. > I've seen at least one suggestion which would have the bootloader (and > hence UEFI) handling characters outside the Basic Multilingual Plane, > albeit somewhat tongue-in-cheek: https://lwn.net/Articles/545741/ > Well way before you hit this pedantic extreme you would more likely run into the issue that there is a large number unicode characters where UEFI will not carry a glyph for the character and it will just display a box. It would make it hard to type a filename at the shell. > But you're right that the immediate practical impact of changing it to > be UTF16LE instead of UCS2LE would be almost zero. That's what makes it > a practicable suggestion. rather than simply an "oh, I wish we hadn't > done this". You'll note I'm *not* suggesting we switch to UTF-8, even > though I wish we could. > Well this is a subject for uefi.org, not tianocore.org. > But it *does* seem like it would be sensible to follow the Windows > example, and retroactively declare "oh, we meant it was UTF16LE all > along; you just never noticed". And then we *remain* consistent with > Windows — and the strings it hands to UEFI, and the strings we hand back > to it, will be interpreted correctly even if someone *does* include a 😻 > in them. > D83D DE3B >> I don't know that it really matters what encoding is actually used as >> long as there are tools support to edit the text file that contains >> the Unicode string. If this is causing folks issues I'm guessing it >> would be easy enough to have a version of the uni file that was >> encoded in UTF-8 and supported by the tools. > > That's an orthogonal issue. In fact, emacs seems to cope automatically > with the .uni files. I didn't even *notice* they were in a weird format > until I ran 'git diff' and it treated the file as a binary instead of > text. So yes, it might be nice to have the source code of the .uni files > in EDK2 as UTF-8 and converted as necessary at build time or whatever, > but that isn't what I was suggesting — and I haven't looked at *how* > they get processed to see if that's even a sane thing to talk about. > > -- > dwmw2 ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
