RE: [xliff] Online validation for XLIFF

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

Hello Yoshito,

There is something curious in the specification. It says that <target> contains text but it also says that it can either be empty or contains the translations of the sibling <source> (section 4.8 "Segmentation")

If you have an empty <source> then <target> can only be empty, leaving you with a useless <segment>.

Perhaps OpenXLIFF should be less strict and allow empty <source> when there is no sibling <target> or when the sibling <target> is empty.

Regards,

Rodolfo

--
Rodolfo M. Raya <rmraya@maxprograms.com>
Maxprograms http://www.maxprograms.com

-------- Original Message --------
Subject: RE: [xliff] Online validation for XLIFF
From: "Yoshito Umaoka" <yoshito_umaoka@us.ibm.com>
Date: Wed, January 20, 2021 2:49 pm
To: "Rodolfo M. Raya" <rmraya@maxprograms.com>
Cc: "xliff@lists.oasis-open.org" <xliff@lists.oasis-open.org>

Rodolfo,

Thank you for your quick response.

> Section "4.2.2.12 source" says that <source> contains text and may
> contain other optional stuff.  It does not say that text content is
> also optional.
>

I saw the explanation. It's not really clear to me that "text" here explicitly excludes "empty text".

> The specification generally indicates that something is optional
> when it is optional, but this is not done in a consistent way. This
> is something that certainly needs review.

For clarity, for this case, we should probably explicitly specify text must not be empty (length > 0).
However, I think it should allow empty value for <source> and <target> for the reason below:

>
> OpenXLIFF treats empty source elements as error because that would
> be a a useless element in most cases. Do you have a good use case
> for an empty <source>?
>

We often see prefix/suffix on UI text might be empty in a language, while non-empty value is used in another language.
In our case, we use Okapi XLIFF toolkit and it does not invalidate the case.

-Yoshito