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
Maxprograms http://www.maxprograms.com
-------- Original Message --------
Subject: RE: [xliff] Online validation for XLIFF
From: "Yoshito Umaoka" <>
Date: Wed, January 20, 2021 2:49 pm
To: "Rodolfo M. Raya" <>
Cc: "" <>
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
