[xliff-tools] Another question on PO and XLIFF
Josep Condal
pcondal at apsic.com
Tue May 3 03:54:07 PDT 2005
Hi Asgeir,
----- QUOTE -----
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?
----- END OF QUOTE -----
I think that makes some sense. At Representation Guide level, maybe it
is a good idea to define things so that the tool publishers do not get
confused on what they should do (ie, preserving data integrity), and in
their turn, the tool publishers should focus on making their
implementations clear to the user, weather that means showing or hiding
\n characters is up to the tool.
In other words, if at the representation guide level (ie filter level)
we normalize the string, there is less pace for confusion for the tool
publisher on what the interface to the filter should be. How the tool
publisher defines the user interface to actually translate the strings
is up to the publisher. The tool publisher responsability is to
minimize user errors when presenting the text to the user.
Therefore, in my opinion, it is better to think of this as two-tier
thing, and manye each tier should focus on its role.
Please keep in mind that the richer a format is, the more diverse are
the possibilities of presenting information for the user so the filter
must focus on integrity, and the tool on features and user experience.
Regards,
Josep.
More information about the xliff-tools
mailing list