Re: PO format and libgettextpo: comment leading spaces

[Dwayne Bailey]

On Mon, 2007-10-22 at 03:48 +0200, Bruno Haible wrote:
> Hi,
> 
> Dwayne Bailey wrote:
> > The PO spec is not clear on leading space in comments.  In libgettextpo
> > the following translator comment:
> > 
> > # Comment1
> > # Comment2
> > 
> > Is returned as the following string when you ask for the translator
> > comment:
> > 
> > " Comment1\n Comment2"
> > 
> > I think the same happens for extracted comments "#."
> > 
> > Yet if a send msgcat this file:
> > 
> > #Comment1
> > # Comment2
> > 
> > It will change it to the first example by adding a space before
> > "Comment1"
> > 
> > This seems to indicate that this is the spec:
> > 
> > #[space]COMMENT
> > #.[SPACE]COMMENT
> > 
> > That space is part of the marker and shouldn't be returned when querying
> > the comment.  I should in fact get back:
> > 
> > "Comment1\nComment2"  i.e with no leading whitespace on any line.
> 
> It's convincing.
> 
> Indeed, I would myself have not guessed that when searching for Comment2
> using msggrep I had to use
>   msggrep -C -E -e '^ Comment2'
> Everyone will have thought
>   msggrep -C -E -e '^Comment2'
> should work. Your proposal thus also fixes msggrep.

Excellent :) This was the most difficult one to work around while we run
with Python and C parsers for a while.

> Implemented. The NEWS entry reads like this:
> * libgettextpo library:
>   - The functions po_message_comments and po_message_extracted_comments
>     return a multiline string where each line no longer starts with a 
> redundant
>     space. The leading space in every comment line is now stripped while
>     reading the PO file.

Just checking this is only the first space, not multiple spaces?  Its
sound correct in the NEWS but just wanted to check that you didn't mean
stripping all leading space.

>   - Conversely, when you pass a multiline string to the function
>     po_message_set_comments or po_message_set_extracted_comments, you normally
>     don't pass a space at the beginning of each line, because such spaces are
>     no longer trimmed during output.
> 
> Bruno
> 
-- 
Dwayne Bailey
Translate.org.za

+27-12-460-1095 (w)
+27-83-443-7114 (cell)