[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 'Language: LANG' will be moved in header

From: D. Barbier
Subject: Re: 'Language: LANG' will be moved in header
Date: Mon, 20 Feb 2012 09:33:59 +0100

Le 20 février 2012 06:49, Ineiev a écrit :
> On 02/19/2012 06:51 PM, Joerg Kohne wrote:
>> see also in www-commits, included in
>> 'www accessibility/ accessi...' of today 10:31)
>>>  "Language-Team: German <address@hidden>\n"
>>> -"Language: de\n"      <-------|
>>>  "MIME-Version: 1.0\n"
>>>  "Content-Type: text/plain; charset=utf-8\n"
>>>  "Content-Transfer-Encoding: 8bit\n"
>>> +"Language: de\n"      <-------|
>> These are most of all changes. Why?
> Could you find out why msgmerge do it?


The Language field is a recent addition.  Older gettext treats it like
all other unknown fields and moves it after known fields.

>>> Why do you actually want to move the field up?
>> Every PO editor (that I known; and support this) adds the line bellow
>> of 'Language-Team:' field.
> Lokalize and poedit preserve the field and don't move it; although this
> probably doesn't count as support (BTW what particular editors do
> you mean?).
> Of course we could add another sed script or two when msgmerging
> the files, however, I'm not sure whether it would be an improvement ---
> it would fix the issue (that is, GNUN won't modify the files)
> for some editors, but it would remain for other: for example, poedit
> writes long passages in a single line, and GNUN will limit the line
> length.
> If you care of unneeded CVS commits, you could msgmerge the files
> before committing. it would work for all editors.

This situation also happens within the French team, I use a recent
gettext (and thus have to deal with the problem Jörg describes), but
other contributors use an older one.  For me, the best option is to
patch our GNUMakefile in www-fr to move Language at the end, but never
took the time to implement it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]