Re: msgmerge and the handling of obsolete entries (Re: Updating pofiles on make dist)

[Bernd Groh <bgroh redhat com>]

Bruno Haible schrieb:

>Bernd Groh wrote:
>  
>
>>could we have msgmerge please NOT 
>>change the format of the po-entries, i.e. introducing new line-breaks?
>>    
>>
>
>You can avoid that by using the option --width=1000. The tools don't force
>a certain normalization on the translators - you can add the width option
>to $(MSGMERGE) in po/Makefile.in.in - but some normalization is useful so that
>  1. transfer of responsibility from one translator to the next one is
>     easier.
>  2. the developers can see what has changed (yes, although the developers
>     must not modify the translations, sometimes they look what changed),
>

I don't know whether I understand what you are saying? If I use the 
option --width=1000, then that means that "foo foo1 foo2 " "bar bar1 
bar2", independent from the length of the actual strings, will 
definitely end up as "foo foo1 foo2 " "bar bar1 bar2"? Is that correct?

>>Sometimes the line-breaking I do has a particular meaning.
>>    
>>
>
>And you cannot express it as a translator comment (a '#' line)?
>

If I am using a tool, such as KBabel, it is rather difficult to use a 
comment within a po-entry.
And even if I quickly use vi to edit the po-file directly, can I really 
do the following:

msgstr ""
"foo foo1 foo2 "
# here I'd like a nice break for better reading for purpose of translation
"bar bar1 bar2"

What I want to do, is to break sentences in a way, so that a url, for 
example, stands in its own line, so that I find it easier to read. If I 
am the designated translator of a certain module (and will be for quite 
a while), I find it of advantage, if I find my entries as I left them, 
just makes translating a little easier next time round.

>>Sometimes  I structure entries and group them into logical units, i.e. "foo foo1 
>>foo2 " "bar bar1 bar2"
>>    
>>
>
>Are these logical units already present in the msgid? Is it a bad msgid?
>

No, with logical units, I meant logical for me. A layout of the msgstr, 
that is easier to read for me. It's like laying out C code nicely. 
Regardless of how your layout looks, if the syntax is right, it'll 
compile and run correctly, irrespective of the layout. But if I have 
structured the code in a certain way, i.e. a new line for every command, 
a certain indent for embedded commands, a new line between groups of 
related commands, etc., then the code itself might be easier to maintain 
and update.

Now, I understand that another programmer might have another preference, 
but how'd you like it, if the compiler would change your layout every 
time you compile the code, since it doesn't really matter, since it's 
still the same syntax?

And I was simply asking, that, if the syntax remains the same, can we 
not leave the layout of the msgstr as the last translator left it as a 
default? And iff a new translator takes over, we might normalize it as 
it is currently done every time? Does that illustrate what I meant?

>Frankly I don't see the value of such logical units in the PO file if the end
>user later will not see them. Maybe you can achieve your goal with some
>punctuation - that would also be visible to the end user?
>

None of my layout is relevant to the end user, just like the layout of 
my C code isn't relevant to the users of my program. But it is relevant 
to me, the programmer. And that's all I am interested in for the moment. 
Can you now see what value these logical units (or call them semantic 
units if you prefer) have for me, the translator?

>>Also, if you should happen to forget the space at the end of the line 
>>(which, admittedly, I sometimes do -- though I *know* it's essential), 
>>and msgmerge is called on the file, I cannot revert it automatically, or 
>>at least semi-automatically, i.e. if I do the following:
>>
>>"foo foo1 foo2" "bar bar1 bar2"
>>
>>then I can later simply check for entries with no space at the end in 
>>the po-file self and fix them (if required)
>>    
>>
>
>You don't need to run msgmerge as often as you do. Usually an "msgfmt -c"
>is sufficient, and it is repeated until the translator submits or commits his/her
>new translations.
>

In general, I don't run msgmerge at all, since the developers do it 
anyway, when they do any changes to a po-file. Which kind of makes it 
difficult for me to use msgmerge with any options to start with. While 
it is not necessarily a problem to later on manually fix the entries of 
the ones where I forgot the space, the problem I had encountered was 
more with translations I took over. In such, I found about 50 missing 
spaces throughout several po-modules. Who knows, there might be more? 
Now, I don't think it's more likely that people actually do not put in 
any spaces in between words, but rather forgetting them at the end (if 
they shouldn't happen to use the right tools). Now, if msgmerge wouldn't 
have changed the layout, then I could simply pick up all such entries 
with a script and check these, which, given they've been merged I now 
cannot do. All I can do is leave the missing spaces, until somebody else 
finds them, or -- if I should ever get the time -- go through every 
entry of all po-modules I maintain manually (and ask other translators 
to please do the same with theirs) in order to find all these missing 
spaces and fix them manually.

Now, I do not simply ask you to change the behaviour of msgmerge, I 
simply said I can see a point to it and I personally would like to have 
it changed for above reasons. My question now, what exactly are the 
reasons to leave it as is, given nothing essential would change anyway, 
exactly because "foo foo1 foo2 " "bar bar1 bar2" is the same as "foo 
foo1 foo2 bar " "bar1 bar2" later on for the user?

Ok, easier transfer from one translator to the next is a good point. 
But, if a new translator shouldn't be happy with the format s/he finds, 
s/he could always normalize it her-/him-self (which doesn't necessarily 
mean s/he'd be happier then). I, as a translator, would be willing to do 
that. In a lot of cases, it's the same people who keep the same modules 
though.

The developers can see what has changed? What do you mean? If nothing 
has changed, nothing has changed. If I write "foo foo1 foo2 " "bar bar1 
bar2" and submit it and do not touch this translation anymore, won't you 
see what has changed and what not? Or do you say you can only see what 
has changed if it is in the format "foo foo1 foo2 bar " "bar1 bar2", for 
example? I'm not sure I understand you here.

Thank you for addressing this issue though.

Best Regards,
Bernd

-- 
Disclaimer: http://apac.redhat.com/disclaimer