[xliff-tools] Another question on PO and XLIFF

[Asgeir Frimannsson]

Hi Tim, and welcome to the discussion :)

On Tue, 3 May 2005 17:44, Tim Foster wrote:
> However, one thing I would have thought, is that the "\n" strings should
> remain in the message, not be converted to the actual '\n' character : I
> tend to look at message files as containing the string that the
> programmer wants to have in the message, not the string as it's finally
> rendered on screen...

Does this mean that you can never have the actual newline character in a PO 
fragment in your editor? (What happens if a translator presses <enter> when 
editing a PO TU?) If not, what happens to the added newline characters on 
back-conversion? 

What if you have a msgid like:
msgid ""
"Here are the options: \n"
"            -V  displays version information\n"
"            -X  extracts magic information\n"

Am I right to assume this would become something like this in your filter 
(Ignoring the fact that your segmenter would do magic here first):
<source>Here are the options :\n            -V  displays version information\n            
-X  extracts magic information\n</source>

...and then dynamically word-wrapped in your editor? 

> If you try to 2nd guess how the string is ultimately rendered, where do
> you stop ? (Does your XLIFF converter need to understand what <b> and
> <i> tags mean in HTML ?) 

There is a difference between markup and escaped characters. Newlines are 
escaped characters, and if the target format supports the native characters, 
why not use them? The only reason they are presented as characters is because 
PO use the newline character for something else (and similarly in source 
code). 

> I believe that if the XLIFF file needs to 
> contain exactly the string to be translated, and the file should include
> something in the header to mark the format. At that stage, it's up to
> your XLIFF editor of choice to present that translatable string to the
> translator a convenient manner, but crucially :
>
> "This is a \n string"
> is different to :
> "This is a
> string"
>
> - let your XLIFF editor work out how to display them to translators.

It all comes back to the same question I guess: Should the representation 
guides provide a common recommendation for handling newline characters in 
software resource formats like PO and .properties? What we really don't want 
to see is one open source editor displaying '\n' characters and another using 
newlines - that would really confuse translators! 

cheers,
asgeir