[xliff-tools] Another question on PO and XLIFF

Rodolfo M. Raya rodolfo at heartsome.net
Tue May 3 03:45:40 PDT 2005


On Tue, 2005-05-03 at 13:36 +1000, Asgeir Frimannsson wrote:

Hii,


> > 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:



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.


> 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.



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?



> 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).


You don't have to convert real newlines to "\\n". Simply write a newline
character in the <source> or <target> element. 


> 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



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.


> ...maybe with a nifty nice <enter> arrow after 'hello' if 'view formatting' is 
> turned on.


Ahh, that's decoration. 

Rodolfo
-- 
Rodolfo M. Raya <rodolfo at heartsome.net>
Heartsome Holdings Pte Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xliff-tools/attachments/20050503/2c43aa86/attachment.htm


More information about the xliff-tools mailing list