gettext

gettext

[Robert Millan]

Are there any plans to implement gettext ?  If not, I'd like to send a
proposal.

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: gettext

[Yoshinori K. Okuji]

On Saturday 19 May 2007 12:21, Robert Millan wrote:
> Are there any plans to implement gettext ?  If not, I'd like to send a
> proposal.

Only a plan. Nothing has been done until now. I think we have three main 
issues:

- how to prevent calling getttext before loading it (note: I don't want to put 
gettext in the kernel)

- what should be translated (how about error messages?)

- what should be done if a terminal is not capable of displaying most 
characters (falling back to original messages? just displaying garbage?)

Technically, it is not hard to implement gettext, but the policy side requires 
some more attention.

Okuji

Re: gettext

[Robert Millan]

On Sat, May 19, 2007 at 07:30:26PM +0200, Yoshinori K. Okuji wrote:
> On Saturday 19 May 2007 12:21, Robert Millan wrote:
> > Are there any plans to implement gettext ?  If not, I'd like to send a
> > proposal.
> 
> Only a plan. Nothing has been done until now. I think we have three main 
> issues:
> 
> - how to prevent calling getttext before loading it (note: I don't want to put 
> gettext in the kernel)

We could put a gettext() stub in the kernel, then have gettext.mod replace it.

> - what should be translated (how about error messages?)

I would suggest starting with the userland part.  Currently, update-grub (well,
10_linux) already generates a translatable string, which ends up showing in the
menu.  This can be l10n'ed before implementing the gettext module, and it would
get it started by implementing the build system part of things (I assume both
userland and kernel are going to use the same message catalogs).

> - what should be done if a terminal is not capable of displaying most 
> characters (falling back to original messages? just displaying garbage?)

I think update-grub should detect wether the system locale is using utf-8,
and if not, set it to C.  It can also detect whether gfxterm is being
enabled.

For users writing grub.cfg by hand, it's their responsability to enable
gfxterm/whatever if they put utf-8 chars in it.

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: gettext

[Vesa Jääskeläinen]

Robert Millan wrote:
> On Sat, May 19, 2007 at 07:30:26PM +0200, Yoshinori K. Okuji wrote:
>> - what should be done if a terminal is not capable of displaying most 
>> characters (falling back to original messages? just displaying garbage?)
> 
> I think update-grub should detect wether the system locale is using utf-8,
> and if not, set it to C.  It can also detect whether gfxterm is being
> enabled.
> 
> For users writing grub.cfg by hand, it's their responsability to enable
> gfxterm/whatever if they put utf-8 chars in it.
> 

Just a note that as character set is Unicode based it could be possible
that some glyphs are not included in fonts. So either we just try to
draw it with specified glyph (and get dummy glyph) or it should be
detected by some party and just use glyphs that are included. Actually
it is also possible to have 0 glyphs loaded ;). I am not so sure is this
so nice, but thats the current state.

gettext

[Carles Pina i Estany]

Hello,

I was thinking to implement some kind of internalization in Grub2. We
discussed some months ago, but now I have been playing with something
and thinking a bit more how to do it.

I have done a "draft" program (working, not shareable -needs some
clenaup-, in standalone C) that getting a .mo file and string translates
the string.

I've based my implementation on:
http://www.gnu.org/software/autoconf/manual/gettext/MO-Files.html
(the basic one is about 200 lines)

I'm not using the gettext hash table so I safe some space (in the .mo
files and code), and Grub doesn't have so much strings to need the hash.
Also, I'm using bisection to search a bit faster. I'm using msgmft
--no-hash to not include the hash in the .mo file.

* SCRIPTS (userland)
We could add gettext support using external gettext program like I
commented here:
http://lists.gnu.org/archive/html/grub-devel/2008-12/msg00030.html

or we could use the Grub2 "gettext mo reader" program (already
implemented the basic version): so we would be testing our mo reader
even in userland, and have one less dependency: gettext binary (in
Debian it comes with gettext-base package).

Which are your thoughts for it?

* GRUB2
My idea is to create in Grub2 a function called _("..."). This function
will exist in standard Grub2 and return the same string that it's
passed.

Then I would implement a module that overwrites this function and does
something like:
a) get Grub2 language variable (to decide the language)
b) open the language file and search for the string that the function
received
c) return the translation (or same string if could not be find)

Thing to maybe improve:
not open the .mo file everytime and read a couple of headers (just a few
fseek and fread, actually) and do it only when the variable is changed.
So I would need a hook to reopen the .mo file and load some .mo file
information when the user changes the variable or perhaps check the
previous variable value with the current one and reopen the file if it's
different.

Would someone do it in a different way? Which way?

Thanks,

-- 
Carles Pina i Estany		GPG id: 0x17756391
	http://pinux.info

Re: gettext

[Carles Pina i Estany]

Hello,

On Jan/13/2009, Carles Pina i Estany wrote:

> I have done a "draft" program (working, not shareable -needs some
> clenaup-, in standalone C) that getting a .mo file and string translates
> the string.

I'm happy to say that I have ported my mo reader to Grub2 (has been
quite easy). I hope that on weekend (Friday evening or Saturday) I will
send the first patch and we can improve it...

-- 
Carles Pina i Estany		GPG id: 0x17756391
	http://pinux.info