OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Preserving spaces inline

Hi all,

I'm looking at the 2.1 draft specification (hopefully the latest one):

In section B.2.1.2 Inline Elements:

In my opinion, the end of the section, from the paragraph starting with "Preserved whitespaces can be also extracted as original
data stored outside..." should be completely removed, including the example B.7.

I think it is an extremely bad practice to place spans of white spaces into inline codes. It bring many issue during translation and
edit, for leveraging, and not to mention that it increases the number of inline codes. I know of one commercial tool that does that
in XLIFF 1.2 when extracting <pre> entries from HTML and we have had tons of issues with such encoding.

If the specification has to provide a solution for preserving the spaces of some section of a segment, I think the simplest and
safest way to do it is to preserve the spaces of the whole segment, or unit.

The Extraction tool can do this by:
-1) Normalizing the spaces in the content as needed (i.e. preserving the spans where they need to be preserved, normalizing
-2) Then extract the unit with xml:space="preserve"
Even if the tool does not do #1, the result is simpler and safer, and it let humans deal with deciding what extra spaces if any
should be deleted during translation or edit.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]