Re: [help-gengetopt] Internationalisation

[Grégoire Scano]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 05/08/2012 03:35 AM, Lorenzo Bettini wrote:
> 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?
Hi,

getopt is part of the libc package under the posix directory. As libc is in the
GNU translation project then i18n is already available for getopt even if the
translation of libc is only achieved at 26% in average. As you said we cannot do
much about it.

Greg
> 
>>
>> 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
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPqVmVAAoJEAKcamzl92pJiOIQAJ0lC0Q08NtpCSPcmB7C3U/k
R7X6muYaq7l57K4b0AL/QhSdiph6Iqn9nkr7Uw68i0kzT+aPPc8u/+diU1dDmJn7
exPYpv0jav0KJfFrw1N43rdwq10Yzwa10Ap2U0PooyZ8LEGJbX/s/6hTbwM22CSy
gnDTza+i2LYQmVMYIgGd08MjIOCn1bByBtBLnw7gK8PaSC5N1gBX5RTcGwwMGjz3
ZCroHW0gJW5O4mNZn2VKtf0h+HG0E3lDwRUNgG3EIMieSbHPzTDSXWp+zD1N0PZ7
T0ZrzlilEAj5okuoG2qc+ppOzIpGuA3lzfmnRnjn9hYGFLC21RkhvKKBft7Zrwhg
Fdn/yQzIoKEIQnZGTawm/EnxO6m77R+fkOP5dwJpDKKbOmhwYB/Rx1R3J3p920lY
85ktBPzaKiVl6QAmBNAB5I7VVOMjP0/ZYVu5rNZBvJIp9XkD4bMwc/ygaTjbSV3t
9GtwrLt/mXd6hyevqy/njiA/xi5tPmJPDspdYbcERXXPGCMqc49pYRXJiUIDVyxQ
hLMvp+6iAqDugafX1KcYx3Wyc/sD1v3wdV8yk/iJtbrYOMfP1AoSkVg0TnsC2DDr
itd11nj//W/6soxwU1lGg6pbpMyc/RwIW84plYKLD/fxK/FfNIL1PThbWRnzeVs2
tPjDWf2kHgC3rYuScfaB
=BPzH
-----END PGP SIGNATURE-----