Re: gettext util

[Carles Pina i Estany]

Hi,

On Mar/27/2010, Jordi Mallach wrote:

> On Sat, Mar 27, 2010 at 12:54:16AM +0000, Carles Pina i Estany wrote:
> > > According to gettext manual usage messages must be internationalised on
> > > per-option basis to allow reuse of e.g. --help desciption and to avoid
> > > the whole big message to be marked as fuzzy if only one option changes.
> > 
> > I'm surprised, specially because if I get the gettext project as a
> > reference:
> > http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/src/gettext.c?id=c81a5234a673f6fbc0f8b7ea8f18ef73021b0a2e#n252
> > 
> > They are not doing. Other projects that I can remember where my LUG has
> > done things (e.g. tar) is not done in this way.
> > 
> > I don't have any probem to change in Grub, I just wonder if people is
> > expecting it :-/
> > 
> > I'm adding Jordi Mallach to the CC
> 
> Whether gettext itself is doing it or not, I'll stick to my
> experience.  As a translator, I am *really* fed up of trying to fish
> in a huge help output to find a tiny change that made the whole string
> fuzzy and so on.

These changes doesn't happen often

> This is now less of a problem with the tools that support showing the
> "previous" string (#|), but it's a huge pain nevertheless.
> 
> If you want to make translator's life easier, I'd totally go with per
> option messages. If alignment is a problem (how?), I guess translation
> comments could be useful to describe how the translated string should
> look like.
> 
> I assume you mean:
> 
>   --help                          Show this help string.
>   --eggs                          Get two eggs from the fridge, crack them
>                                   and put them on hot olive oil.
> 
> It'd be difficult to align "Show" with "Get". I'd say that this
> depends a lot on the editor you use. Emacs at least makes it easy to
> calculate if you got it right or wrong.

I'm not convinced to change it (yet :-) ).

gettext manual says:
"""
Translatable strings should be limited to one paragraph; don't let a
single message be longer ***than ten lines.*** The reason is that when
the translatable string changes, the translator is faced with the task
"""
[...]
( http://www.gnu.org/software/gettext/manual/gettext.html ) 

I have not seen any program (again, yet, maybe Grub will be the first
one) to split the messages in this way. Emacs helps to calculate the
alignment, but other programs helps to compare the current and the
previous message. So the gettext manual is maybe a bit outdated. Plus,
these messages in Grub doesn't change often.

10 lines is reasonable in most cases.

So my concerns:
a) It change a common practise (even when it's not the best one).
Translators expects the way that it has been done until now, and I would
like that somebody that it's not Grub (small i18n project) starts the
change

b) Makes the alignment more difficult

c) Makes the code a bit less clear

Comment: sadly our grub.po already has someo of these long messages.
Would you change it and "force" the translators to change? Or have the
Grub domain with some long strings as short strings?

Maybe Colin has things to say too.

If next messages goes to the same direction (splitting) I'll propose a
way to split some non-gettexted message in Grub and then apply the same
to the other ones.

(Mmm... a nice start would be to split the very-repeated:
"  -h, --help                display this message and exit\n"
"  -V, --version             print version information and exit\n"
"  -v, --verbose             print verbose messages\n"
"\n"
"Report bugs to <%s>.\n"

In different sentences for all messsages.
)

Cheers,

-- 
Carles Pina i Estany
        http://pinux.info