[xliff-tools] Another question on PO and XLIFF

[Rodolfo M. Raya]

On Tue, 2005-05-03 at 11:29 +1000, Asgeir Frimannsson wrote:

Hi

> On Mon, 2 May 2005 23:39, Rodolfo M. Raya wrote:
> > Line breaks are defined by the translator. When translations are long,
> > you find things like this:
> >
> >
> > msgid ""
> > "Short text in the original"
> > msgstr ""
> > "long translation, that spans to perhaps two "
> > "lines or more in the target language because "
> > "it does not fit in the dialogue where it has "
> > "to be displayed"
> >
> >
> > Translators add the necessary line breaks at translation time in the
> > editor. Lines are usually kept shorter than 70~80 characters.
> 
> I might have misunderstood you here, but in this example the msgstr at runtime 
> would be one long line without newline characters. But I assume you here 
> meant that translators add the necessary '\n' characters to break the target 
> string into multiple lines at runtime.


I know that the text is seen as a long string by the program at runtime.
But the program needs to parse the escape characters embedded in the
string, so you should never remove the escape characters as Yves and you
proposed.


> In an XLIFF editor, instead of manually adding newlines to be able to see the 
> whole *long* string in the editor window, shouldn't it be word-wrapped (and 
> visually indicated some how),


I know that. Heartsome's XLIFF editor has automatic word wrapping. I
don't care if the translated document says 


        msgstr  ""
        "line 1 "
        "line 2"
        

or 


        msgstr  "line 1 line 2"


but when the entry is 


        msgid "line 1\n line 2\n"


the translated version should be


        msgid "line1\n line2\n"
        msgstr "linea 1\n linea 2\n"


or 


        msgid ""
        "line1\n "
        "line2\n"
        msgstr ""
        "linea 1\n"
        " linea 2\n"


To achieve that, it is important that all characters that are inside
double quotes in the msgid appear in the <source> element. Do not assume
that some magic can recreate them at reverse conversion if they are not
present in the source.

Regards,
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/20050502/b6ca2267/attachment.html