From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.33) id 1Br2UZ-0004Hw-St for mharc-grub-devel@gnu.org; Sat, 31 Jul 2004 18:38:15 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Br2UY-0004Hh-5P for grub-devel@gnu.org; Sat, 31 Jul 2004 18:38:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Br2UX-0004HV-K8 for grub-devel@gnu.org; Sat, 31 Jul 2004 18:38:13 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Br2UX-0004HS-Fc for grub-devel@gnu.org; Sat, 31 Jul 2004 18:38:13 -0400 Received: from [212.43.237.68] (helo=kotoba.storever.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Br2Qr-0006VE-PP for grub-devel@gnu.org; Sat, 31 Jul 2004 18:34:26 -0400 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by kotoba.storever.com (Postfix) with ESMTP id 0D7AFF0D35A2 for ; Sat, 31 Jul 2004 18:34:25 -0400 (EDT) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Sun, 1 Aug 2004 00:34:30 +0200 User-Agent: KMail/1.6.1 References: <200407312032.27650.okuji@enbug.org> <87k6wkdkhf.fsf@marco.marco-g.com> In-Reply-To: <87k6wkdkhf.fsf@marco.marco-g.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408010034.30291.okuji@enbug.org> Subject: Re: usability X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 22:38:14 -0000 About internationalization: GRUB 2 has a goal of internationalization. Here, i18n means these things (in my definition): - Messages can be translated - Non-ASCII characters can be used in config files - Non-ASCII characters can be displayed - Non-ASCII characters can be used in file names The last one might not be important, because you don't use non-ASCII in OS image files normally (consider /boot/vmlinuz). But I think filesystems should be able to list up file names with non-ASCII characters at least, so that the user can see some useful information on the screen when she types "ls". The first one should be realized in the same way as gettext, but it is not implemented yet. The third is possible in my test environment. I tested it with Japanese, and worked fine. When you want i18n, you need to define something about character code and encodings. For now, I select Unicode as the standard character code and use UTF-8 and UCS-4 as the encodings. I think this is a good idea, because Unicode makes things a bit simpler than mixing a lot of code (like ISO2022-JP-2). UTF-8 is used in most places, because it has a good compatibility with ASCII. UCS-4 is used only in the console stuff at the moment. This makes the implementation of a console device easier, because you can represent each character in a fixed size (this is not completely true, because of ligatures). Therefore, you must assume that UTF-8 is used when you use strings in your code. And, you must not assume that the length of a string is equal to the size of the string on the screen. For example, many European characters are 2-byte in UTF-8, but they are shown as 1-column characters on the screen. So you must distinguish between the length and the column size carefully. In reality, what does the user want to do? I guess she wants to do these: - See messages in her own language - See titles in the menu in her own language - Write comments in config files in her own languages So I'd like to assume that config files are written in UTF-8. Maybe we can support other encodings, but this requires some heuristic methods or an explicit declaration of an used encoding. I feel that this is too much, since people normally do not use UCS-2 or UTF-7 in text files. But some people may want to use "legacy" chracter code, such as ISO-8859-1 and EUC-JP. I'm not sure if it is better to translate error messages from commands. This should be a bad idea from developers' point of view, but useful for ordinary users. More thoughts are needed. Do you have any idea or question? Okuji