[xliff-tools] Another question on PO and XLIFF

[Tim Foster]

Hey Folks,

On Mon, 2005-05-02 at 17:28, Josep Condal wrote:
> I think that what makes sense is to provide the string and let the
> editor decide how that is presented to the user (i.e. line wrapped).
>  
> Therefore, the following string:
>  
> Line 1\n line 2\nLine3.\n
>  
> is the one that makes sense.

Me too ! Sorry I didn't get a chance to reply to this yesterday (public
holiday in Ireland) but this is exactly how we manage PO files in our
filters : we basically ignore the physical layout of the message in the
PO file, and choose the logical contents of the message.

Of course, users weren't too impressed with this approach when being
presented a PO file at the end-of-translation back-converted PO file, so
I spend a while (too long) writing some neat pretty-printing that
respects "\n" strings in PO entries, and tries to line-wrap to 80
characters. I think it works quite well, and you'll be able to get your
hands on it when we finally get around to releasing our filters.

> The only drawback is that you don't have the convenience of round-trip
> testing of filters (mentioned by Rodolfo I believe) because the
> cosmetic line wrap in the PO source is gone forever.  

Yep, that's true, but remember, you should only ever be looking at the
actual message content - everything else is just cosmetic (as you say
:-)

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

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

> However, just let me add that I think that C escape characters should
> be somehow tagged, at least by default. It helps many tools downstream
> (such as spellcheckers in XLIFF-aware tools, etc) make assumptions on
> what is text and what is code more easily.

Yep, we're doing this for .po files - though we still need to come up
with some more cleverness though to check for the GNU formatting type
comment and apply the appropriate escaping mechanism (right now, we just
try c-format for po files)

	cheers,
			tim
 
> Regards,
>  
> Josep.
>  
>  
> 
> ______________________________________________________________________
> De: xliff-tools-bounces at lists.freedesktop.org
> [mailto:xliff-tools-bounces at lists.freedesktop.org] En nombre de Yves
> Savourel
> Enviado el: lunes, 02 de mayo de 2005 14:55
> Para: xliff-tools at lists.freedesktop.org
> Asunto: [xliff-tools] Another question on PO and XLIFF
> 
> 
> 
> Hi,
> 
> I have a new question on XLIFF representation of PO.
> The guide
> (http://xliff-tools.freedesktop.org/wiki/Projects_2fXliffPoGuideDraft2) does not seem to say anything about multi-line entries. 
> 
> msgid ""
> "Line 1\n line 2\n"
> "Line 3.\n"
> 
> How this should be represented?
> 
> <trans-unit xml:space="preserve">
> 
> Line 1\n line 2\n
> Line 3.\n</trans-unit>
> 
> Or 
> 
> <trans-unit xml:space="preserve">
> Line 1\n
>  line 2\n
> Line 3.\n
> </trans-unit>
> 
> Or
> 
> <trans-unit xml:space="preserve">
> Line 1
>  line 2
> Line 3.
> </trans-unit>
> 
> ?
> 
> The third seems more logical to me, but it could cause issues too, for
> example if the line-breaks are not \n but \r or \r\n (if the PO file
> is used for a non-Unix application) how would we know which type of
> line-break notation to put ack when merging.
> 
> Anyhow, a section on this topic would be good to have in the Guide.
> 
> Cheers,
> -yves
> 
> 
> 
> ______________________________________________________________________
> _______________________________________________
> xliff-tools mailing list
> xliff-tools at lists.freedesktop.org
> http://lists.freedesktop.org/cgi-bin/mailman/listinfo/xliff-tools
-- 
Tim Foster - Tools Engineer, Software Globalisation
http://sunweb.ireland/~timf http://blogs.sun.com/timf
http://www.netsoc.ucd.ie/~timf