Re: Internationalisation

On 02/22/2012 08:24 PM, Tim Marston wrote:
> Hi,

Hi!

I'll try to comment on your emails (again, sorry for the delay O:)

>
> OK, the first thing I wanted to discuss was internationalisation.
> Reading back through the mail archives, I see it's been discussed
> previously. I'll try to summarise the situation, as I understand it
> (correct me if I miss anything or get anything wrong!).
>
> The way I understand it, it breaks down in to three parts.
>
> 1. internationalisation of the getopt library, which is probably beyond
> the scope of this discussion.

well, yes, if getopt library itself is not internationalized we can't do 
much about that... besides propose the internationalization yourself; I 
haven't been following the evolution of GNU getopt library for some time 
now... are we sure they haven't internationalized it yet?

>
> 2. internationalisation of gengetopt's own strings. The problem here is
> that, since getopt isn't currently localised, you'll end up with a
> mixture of english and localised errors, depending on whether they come
> from getopt or gengetopt. The question I have here is whether this is
> enough of an issue to defer internationalisation of gengetopt until
> something happens to getopt.

well uniformity is quite important, isn't it?

>
> 3. internationalisation of application strings.
>
>> From the point of view of gtypist this last part is really the one I'm
> interested in (although I'd be happy to work on the second part as
> well). Currently, gtypist has localisations of argument descriptions, so
> we'd lose them (for better of worse) by switching to gengtopt.
>

can you make some examples?  I'm not sure I understand

> If this is something that is seen as a good idea, it would also seem
> simple enough to implement. Basically it would involve:
>
> - detecting the use of gettext. This could be done via config.h or,
> perhaps, via a command-line argument. Then #defining _() appropriately.
>

and the corresponding Automake/Autoconf macros for detecting it during 
configure

> - wrapping application strings with _(). This would probably mean that
> the gengetopt_args_info_help[] array would have to be changed, which
> would break compatibility. I am unsure of the use-cases for this array,
> though. How much of a problem would this be?

how would this array be changed?

>
> - doing line-wrapping at runtime. Which means that line-wrapping code
> would have to be added to the generated file.
>

this would require adding a wrapping function in the generated code, right?

> What are your thoughts? Is this something that you would want adding to
> gengetopt?
>

For the moment, I cannot add any new feature to gengetopt myself: it's 
such a busy moment that I really can't work on it... especially if it 
requires to write C code (as opposite to C++ code), as in the case of 
the runtime wrapping...

Of course, if you can provide patches (and unit test cases) I'll be 
happy to collaborate :)

cheers
	Lorenzo


-- 
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134     (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com  http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net