grub4dos0.45c/0.46a最新版底部说明汉化

lgl007

本汉化版是采用chenall大和yaya 大2015-05-18版本部分文件源码进行汉化,然后重新编译而成,这里要感谢无忧启动论坛的各位高手大侠们。
这次对上次网友提出的汉化语句表达问题进行改进，请各位继续试用。谢谢

photor

devilma

拿走了谢楼主(･ิϖ･ิ)っ

2010win5xp

感谢楼主的无私奉献

jyf007

回车间去无私奉献了

看见飞机场

谢谢楼主分享啦！！

不点

我觉得这个可以集成到正式发布版中。以下是我的思路，供 chenall 参考。

grub4dos 要处理菜单，这是肯定的。无论内置还是外置，它都是菜单，也都要经过 grub4dos 的菜单读取程序进行处理。在读取菜单的时候，可以通过分析，确定菜单的 title 中是否含有 utf8 编码的汉字，如果有，就记录在某个全局变量中，比如说 lang=zh 之类的。同时，修改菜单显示程序，让它在 lang=zh 时显示中文信息，而不是显示英文信息。

nbv

grub4dos-0.4.6a 的启动后，按“E”键无法进行编辑，也没有显示任何菜单，也无法退回菜单。貌是进入死机状态。

lgl007

我试了一下，用上下箭头选择菜单后，再按E键就可以进入命令行，刚刚进入后按E键进入死机状态。这还得请chenall和yaya来测试一下英文版是否有这种情况。

lgl007

我只是把部分文件中的英文汉化了一下，别的还是源程序编译的

chenall

nbv 发表于 2015-5-27 08:25
grub4dos-0.4.6a 的启动后，按“E”键无法进行编辑，也没有显示任何菜单，也无法退回菜单。貌是进入死机 ...

麻烦你用原版的先测试一下看看是否有一样的问题.

不点

lgl007 发表于 2015-5-27 22:09
我试了一下，用上下箭头选择菜单后，再按E键就可以进入命令行，刚刚进入后按E键进入死机状态。这还得请chen ...

你自己就能测试啊，你有测试条件。换成别人测试，即使成功了，也不能证明在你的机器上也成功。

lgl007

C大和不点老大，你们好：
   刚才我实际启动了一下，没有汉化的版本没有问题，按E键能够编辑，汉化版本不显示菜单内容，无法编辑，且按任何键没有反应。看来， 测试和实际启动之间还是有差别的。不知我哪里出错了，我是下载了C大的colinux系统进行编译的，不知哪里出错了，上次我是在win7下进行编译的，这次是xp，这有区别吗?

lgl007

两位老大，我只是把菜单中底部说明改成了中文，别的源文件没有改动，这有关系吗？0.45C版本的grub4dos也是这种情况，原版没有问题，但改成中文后，按E键后，进入死机状态，无法进行编辑。

不点

lgl007 发表于 2015-5-28 09:10
两位老大，我只是把菜单中底部说明改成了中文，别的源文件没有改动，这有关系吗？0.45C版本的grub4dos也是 ...

你确信你的改动不会对程序本身产生影响吗？我猜测恐怕是你的改动有 bug 吧？

要不你换编译器（或者换操作系统）再试一次，因为以前也确实因为编译器的问题产生过错误。

或者你让别人在别的环境进行编译（比如在某个 Linux 系统下编译）。

chenall

你可以把你修改的DIFF文件传上来,看看是不是有改错了.

lgl007

我是在widwos下把源码包下载后，在colinux系统下解压，然后在widow中用notepad++把cmdline.c和stage2.c两个文件中的相关的显示英文的地方改成了中文，别的文件没有动。然后在colinux系统下编译而成。没有diff文件生成。

不点

还是 chenall 自己弄吧，不用再麻烦楼主了。

把某些东西汉化。如果时间不够，就只把菜单部分汉化。如果时间充裕，就连 help 中的信息也可汉化。

2012zcsh

感谢楼主。。。

2011yaya2007777

你可以把你修改的DIFF文件传上来,看看是不是有改错了.

同感

通过菜单设置标志，分别显示帮助菜单的中英文。这个我来处理吧。
想问一下，是通过 if 语句，还是宏？如果是宏，怎么写？

lgl007

chenall、不点、yaya各位老大你好：
   附件为在colinux系统下用git clone下载的0.45c的源码，然后在cdlinux下修改cmdline.c和stage2.c文件产生的diff文件。烦请你们给看一下，哪里出错了。谢谢！
   注：直接在grub4dos.chenall.net网站上下载的源码编译后不生成diff文件。

不点

2011yaya2007777 发表于 2015-5-29 06:34
同感

通过菜单设置标志，分别显示帮助菜单的中英文。这个我来处理吧。

可能是我没把意思表达清楚吧（我现在语文水平也在下降，这是自然规律）。

我的意思是，grub4dos 内核在读取菜单的时候，要处理 title （和 iftitle）命令并且保存 title 的内容到内存数组中。

在处理 title 的过程中（或者也可在全部 title 数组保存之后），立即检查 title 的字符串数组中是否含有 UTF8 格式的汉字。如果有，就把默认的 lang 变量设置为 zh。

lang 变量需要重新建立，它的默认值是 0 或者是空的字符串。lang 的变量名只是举例，我不懂 linux 和 windows 关于地区语言设置方面的约定，所以，你可以寻找一个更恰当的名字。lang 的变量类型可以是整数型，也可以是字符串型，依你的权衡而定。同样，其值可以是 zh 或 cn 或 zh_CN 之类的，我也不知道究竟怎么才好。也可以查阅有关语言设置方面的 RFC 文档。

这整个过程是在 grub4dos 的内核中处理的（是在内核的菜单处理部分进行处理的；也就是说，是自动的，无需用户干预），不是在菜单中由用户设置来处理的。当然用户也可以在菜单中设置 lang 变量，这样就强制覆盖了 grub4dos 从 title 中探测到的语言类型。

当读取一个 menu.lst 时，grub4dos 都要给出一个探测到的 lang 值。目前可以只探测中文，不探测别的语言。当未探测到中文时，lang 应该保持默认值（即空的字符串值；如果是整数，则为0）。在 menu.lst 中，当遇到用户设置 lang 变量时，以用户的设置为准。

lang 变量可以放在 grub4dos 的固定变量区。甚至也可以在 builtins.c 中为它创建一条同名的命令（添加lang_func() 函数）。

如果把 lang 放在固定变量区，我觉得最好不要放在 0x8200 处的区域，因为这个区域是在常规内存中，很宝贵。我们应该节约常规内存，因此，可以放在第二块固定变量区中，即，放在 0x307000 至 0x308200 这个区域中。其实我已经在第二个固定变量区中放置了几个变量。比如说，我在 0x308000 处放置了 cpu 的信息，占用 32 字节（即 8 个四字节整数的长度）：

unsigned int *sig = (unsigned int *)0x308000; //&vm_cpu_signature;

在 0x307FFC 处放置了 preset_menu 变量（四字节整数）。
在 0x307FF8 处放置了 use_preset_menu 变量（四字节整数）。

我不知道 chenall 后来有没有使用这个空间。如果没有使用，你可以接着使用 0x307FF4，0x307FF0，……，一直到 0x307000，都是可以使用的。个别大块的字符串变量，可以使用 0x308020 至 0x308200 的空间（因为 刚才说了，0x308000 处的 32 字节已经用于 cpu 信息了）。

内核在显示菜单的时候，可以根据 lang 变量的值，来决定显示中文或英文。举例来说，如果 lang 的值是 zh，就显示中文，否则，显示英文。当然，如果是文本模式，那只能显示英文。必须进入 VBE 图形模式以后，才可以显示中文。

整个过程是自动的，不需要用户在菜单中有任何设置。用户以前的菜单不需要进行任何修改，只要换成新版，就能够自动处理中文。用户唯一需要保证的是，title 行上能够找到一个 UTF-8 编码的中文字符。只要满足这个条件，剩余的事都是 grub4dos 内核的工作了。

希望这次我说明白了。如果还有不清楚的，请继续交流。


关于汉字探测，再提醒一点需要注意。grub4dos 只支持 65536 个 Unicode 字符，也就是 BMP 的 unicode 字符。超过这个范围的汉字是不支持的，无需探测。

chenall

我倒是有另外一个想法.

首先把内核里面的英文资源全部提取出来到某个文件或数组中(也比较方便进行翻译等).内核在默认情况下直接调用这里面的资源,或根据菜单内容显示.指定资源.
另外也要充许用户通过某些命令来调用显示自己翻译的资源,这样就实现了多语言.

外置的翻译考虑使用INI格式.比如如下,通过数字编号确定资源对应关系.类似如下.
1=某菜单信息
101=某错误提示
1001=某命令帮助

不点

chenall 发表于 2015-5-29 10:31
我倒是有另外一个想法.

首先把内核里面的英文资源全部提取出来到某个文件或数组中(也比较方便进行翻译等 ...

这也不错。现在上了年纪，不再研究新知识了，我不知道其他国际化的软件，通常都是怎么做的。可以参考借鉴别的软件的做法。

如果需要放在文件里面，可以考虑放在 unifont.hex 的开头，与字库共用一个文件。

另外，我觉得，英文是默认的，应该内嵌到二进制文件的程序体里面（就像目前这样）。

其他主要语言（中、法、西、俄等）也都可以内嵌（可以采用数组的方式）。

help 的内容不翻译，因为内容太多，其占用空间太大。使用 help 的人大多都是有一定基础的，可以看懂英文。可以搞个外部的 txt 文件，用 cat 命令来看文档（需要不同语言的翻译者来翻译文档；现在是网络时代，也可以使用谷歌翻译）。

如果不翻译 help，那么，剩下的那些与语言有关的字符数已经不多了，完全可以支持所有的语言（需要有不同国家的贡献者才能支持相应的语言；现在是网络时代，也可以使用谷歌翻译）。

以前我还提到过一个想法，就是把倒计时的秒数显示在靠近高亮条的最右端（与高亮条处于同一行）。倒计时所使用的阿拉伯数字是全球通用的，因此不用任何提示信息。

不点

lgl007 发表于 2015-5-29 08:20
chenall、不点、yaya各位老大你好：
   附件为在colinux系统下用git clone下载的0.45c的源码，然后在cdlin ...

buff 的缓冲区只有 256 个字节。UTF8 汉字太长，每个汉字占用 3 字节，整个字符串超过了 256 字节，造成字符串溢出，引起程序错乱和死机。

你把 buff 的定义扩大为 512 字节，应该不会出问题了。

2011yaya2007777

看了一下 diff 文件，没见端倪。按说修改显示信息，最多是翻译错误，不可能引起按键出错。

能内部自动判断是否加载汉字，是最好不过的。这需要比对菜单项标题。
我觉得既然本软件主要由国人开发，那首先应当做好汉化工作。他国人员也可通过谷歌自己翻译。
对于‘汉’鸭子，我觉得首先应当汉化帮助信息，其次是错误信息。菜单汉化内容小，直接内嵌就好了。

我觉得 chenall 想法很好。把要显示的英文字符串放在一个文件里。汉化，法化，日化...后，使用不同的文件名存放。使用时修改为默认文件名即可。

不点

2011yaya2007777 发表于 2015-5-29 13:10
看了一下 diff 文件，没见端倪。按说修改显示信息，最多是翻译错误，不可能引起按键出错。

能内部自动判 ...

世上什么事都有可能。不可能的事发生了。前面我已经指出了错误的根源。

buff 这个变量的空间只有 256 个字节。strcpy 函数把 utf8 汉字字符串拷贝到 buff 上，导致溢出，立即死机。

buff 是在堆栈上，所以，溢出是会导致立即死机的。像这样的错误是最容易调试出来的了。

死机有利于排错。只要死机，这个错误就不难查到。

2011yaya2007777

grub4dos-0.4.6a 的启动后，按“E”键无法进行编辑，也没有显示任何菜单，也无法退回菜单。貌是进入死机状态。

我这里，使用提供的 diff 修改源码，编译后测试，没有问题。

不点

2011yaya2007777 发表于 2015-5-29 14:43
我这里，使用提供的 diff 修改源码，编译后测试，没有问题。

数数拷贝到 buff 上的字节数，看看是否溢出。如果没有溢出，那就不是这里的问题。

那就可能是编译器的问题了。你的编译环境与楼主的不同？也许是 Windows 的问题？

我刚刚数了一遍，确实是超限了。

光是拷贝到 buff 上的汉字（中文标点符号也是一个汉字），就满满 80 个。这占用 UTF-8 的字节长度 = 80 × 3 = 240 个。再数数其中的英文字符和空格，很快就知道超过 16，没有精确去数。但超过 16 个字节。两者相加就超过 256 字节了。

你没遇上死机，是不是因为你没有按 e 键进入编辑状态？你按 e 键试试看？

2011yaya2007777

进入菜单后，直接按 e 键，没有问题。再按 e 键也没有问题。
那里有个判断语句 config_entries ？... : ...，没有全部加载到缓存。
使用 grub_strlen 函数，返回 233 ，缓存没有溢出。