From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Rw0iW-0000nv-Vw for mharc-grub-devel@gnu.org; Fri, 10 Feb 2012 19:21:28 -0500 Received: from eggs.gnu.org ([140.186.70.92]:39111) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rw0iU-0000kj-I2 for grub-devel@gnu.org; Fri, 10 Feb 2012 19:21:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rw0iT-0004HO-2w for grub-devel@gnu.org; Fri, 10 Feb 2012 19:21:26 -0500 Received: from mail-bk0-f41.google.com ([209.85.214.41]:45608) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rw0iS-0004HK-PK for grub-devel@gnu.org; Fri, 10 Feb 2012 19:21:25 -0500 Received: by bkty12 with SMTP id y12so537004bkt.0 for ; Fri, 10 Feb 2012 16:21:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Mdr9av4WpuCfRBr8IIMkUEXkZ5aOyBHwxpUy32fDh24=; b=Z922awhytm3woZSm8W/Y/E488e1rIceOMjR+LsjklbGCPMa6EwmYbe5pvrC3O2d7iO Buv+Ekm+zTupDhp2+TfltEO8x1WLzABMKRqnX3oXq6jK03FreWaBDndhbdqPZZwSkh2w 9U3szK2P/2bLeHOeuJKQK0ls/EAjhELve/s/Q= Received: by 10.205.129.130 with SMTP id hi2mr3346663bkc.98.1328919683341; Fri, 10 Feb 2012 16:21:23 -0800 (PST) Received: from [192.168.178.55] (p5091DA65.dip.t-dialin.net. [80.145.218.101]) by mx.google.com with ESMTPS id ez5sm21947963bkc.15.2012.02.10.16.21.21 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Feb 2012 16:21:22 -0800 (PST) Message-ID: <4F35B480.9020402@googlemail.com> Date: Sat, 11 Feb 2012 01:21:20 +0100 From: Andreas Born User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: gettext in scripts References: <4F35A00F.2010209@gmail.com> In-Reply-To: <4F35A00F.2010209@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.214.41 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 00:21:27 -0000 Hi, this is a great feature! Our LiveCD project (Salix Live) uses grub as bootloader and we offer a localized boot menu, which is - at least last time I checked - roughly implemented like SGD's localization. So not only SGD could benefit from such an infrastructure and this is something we've been looking for since the very beginning. Am 10.02.2012 23:54, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: > Hello, all. It was requested to have a way to gettextize Super GRUB > disk. Original request was to extend gettext with -s options but it > may result in a mess to temporary variables. So I'd propose to rather > use $"..." syntax with the exception that we don't expand it after > translation to avoid some pitfalls. Sharing syntax with bash will > allow to use normal xgettext --language=Shell. > The real problem is as to how to include SGD strings in grub.pot. I > see following solutions: > 1) Merge projects and put SGD inside GRUB2. It's possible if its > authors want it but many more questions would need to be discussed. > 2) Import sgd.pot into grub.pot regularly. This creates an > administrative overhead and requires GRUB and scripts to have matching > versions. I don't know if it's easy to merge .pot files > 3) Just have a few strings for usage by external projects. This would > heavily limit the extent of internationalisation and would result in a > lot of feature requests one after another for this or that string. Those solutions would only allow SGD to offer localization. Except maybe 3, but I'd say that one is of very limited use and irrealistic especially regarding the maintenance for grub. > 4) Have some way to load .mo from another directory. Perhaps something > like locale_dirs=$dir1:$dir2:$dir3. This creates some problems as to > how and when to load files and how to store them. The easiest way > consisting of having multiple opened gettext files and try each of it > in turn. Trouble is that then when adding a single directory we need > to either reload all files or compare the previous list with current > to reload only changed directories. That sounds like a much better idea as other projects could also use localization without increasing the workload for grub. Actually this looks like my favorite now. What do you think would be the perfomance/speed penalty regarding loading of the directories and accessing a translation? I think for common use cases it would be enough to add additionally to the already implemented locale_dir=$dir1 a second environment variable like additional_locale_dir=$dir2. That would overcome the problem of reloading all directories/ comparing lists. It offers less flexibility, but a too long list of files to search would probably have a negative performance penalty anyway. > Any other ideas? Similarly to 2, but the other way round: 5) Import grub.pot to sgd.pot (or whatever other project). This is probably the easiest solution for grub with no additional workload. Regarding projects building on grub this is not a perfect solution and makes it harder to use such functionality. But it would be already a great step forward and the maintenance burden for other projects is by far not irrealistic. Given an easy-to-use, suitable and efficient tool (maybe already existent?) this solution is more than acceptable. Still solution 4 seems way cleaner to me as it separates the strings of grub and other projects, which I imagine could be better in the one or other situation. Specifically there could be problems when a user runs grub-install or equivalent and thus overwrites the .mo files with a different version. Or multiple projects each with its own translation could use the same grub installation. Andreas