<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.3.2"> </HEAD> <BODY> On Tue, 2005-05-03 at 13:36 +1000, Asgeir Frimannsson wrote: Hii, <BLOCKQUOTE TYPE=CITE> <PRE> > The "\n" is part of the text. It is a sequence of two characters: '\' > and 'n'. It is not only an instruction for the program that will > display the text on screen. The translator should be able to see these > characters and move them wherever they fit. "\n" is a sequence of two characters, yes I agree so far. But it is still only a representation of an escape-sequence. And this is also how they are represented internaly in gettext. In addition, Gettext ignores totally how the PO file is formatted (if it's on multiple lines, or a single line). Let's do a simple test: </PRE> </BLOCKQUOTE> <PRE> </PRE> I see that you base everything on Gettext API. Isn't it too dangerous to assume that all files were originated in C programs? Some PO files are generated from XML documents. If at reverse conversion you add the sequence "\n" whenever you find a linefeed, the result will be a mess. <BLOCKQUOTE TYPE=CITE> <PRE> Representing this in XLIFF by replacing THE TWO CHARACTERS '\' and 'n' with a real newline character on conversion, and similarly replacing the real newline character with "\n" on back-conversion would be a just as valid approach. </PRE> </BLOCKQUOTE> <PRE> </PRE> What about PO files originated from PHP? Is it still correct to replace a real newline character with "\n" on back conversion? And what about Python? XML? Any format? <BLOCKQUOTE TYPE=CITE> <PRE> In fact, if I were to use your approach here, I would have to manually replace all real newline characters with "\\n" before converting to XLIFF, as the gettext API handles "\n" as real newline characters internally (and yes, I'm using the gettext api for parsing/reading/writing PO files in my filters). </PRE> </BLOCKQUOTE> You don't have to convert real newlines to "\\n". Simply write a newline character in the <source> or <target> element. <BLOCKQUOTE TYPE=CITE> <PRE> I don't want the XLIFF editor to display a '\n', i just want it to add a newline character where there is a newline in the source, so: msgid "hello \n world" becomes <source xml:space='preserve'>hello world</source> and would display in a editor: hello world </PRE> </BLOCKQUOTE> <PRE> </PRE> As the attribute xml:space is set to "preserve", XLIFF editors display the text as you sketched above. BTW, it is better to set the xml:space attribute in the <trans-unit> element and let the scope rules cover the <target> and <alt-trans> children. <BLOCKQUOTE TYPE=CITE> <PRE> ...maybe with a nifty nice <enter> arrow after 'hello' if 'view formatting' is turned on. </PRE> </BLOCKQUOTE> Ahh, that's decoration. Rodolfo <TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%"> <TR> <TD> -- Rodolfo M. Raya <<A HREF="mailto:rodolfo@heartsome.net">rodolfo@heartsome.net</A>> Heartsome Holdings Pte Ltd </TD> </TR> </TABLE> </BODY> </HTML>