xml:lang attribute should be allowed on some other elements than <source> and <target>

[rabularca]

Currently, the validator incorrectly throws an exception if xml:lang attribute is found on elements such as <xliff> or <file>. Checking the xsd schema for the <xliff> attribute, we see that only the xml:space attribute is specifically noted, but the line <xs:anyAttribute namespace="##other" processContents="lax"/> means that any other attribute from other namespace than the target namespace (which is urn:oasis:names:tc:xliff:matches:2.0). Considering that the xml:lang attribute falls into that category, the following file should be valid:

<?xml version="1.0"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" version="2.0" srcLang='fr-FR' xml:lang="fr-FR">
 <file id="f1">
  <unit id="1">
   <segment>
    <source>source</source>
   </segment>
  </unit>
 </file>
</xliff>

To make sure, I have checked the file and the official xsd http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/schemas/xliff_core_2.0.xsd against some online validators and all of them said that the file is valid.

Also, besides <xliff>, the following elements from Core should support xml:lang and other namespace attributes: <file>, <group>, <unit>, <note>, <ph>, <pc>, <sc>, <ec>, <mrk> and <sm>.

[simonech]

I think it's allowed on structural elements (file, group, unit, notes) but not on inline elements (ph, pc, sc, ec, etc..).
Anyhow, applying just an XSD to check for validity is not enough as the Xliff specs have other "business" rules that cannot be enforced by a simple xsd validation.

To have the full validation you should use the schematron rules.

So, to wrap up, xml:lang should be allowed on file, group, units, notes (even if not really recommended) but should still raise error on inline elements.

[rabularca]

Anyhow, applying just an XSD to check for validity is not enough as the Xliff specs have other "business" rules that cannot be enforced by a simple xsd validation.

I understand that. Basically, even if it would be legal, it would have no sense to be there, since Source and Target are the only elements which are truly effected by the attribute, but inline elements can't contain them.

However, the case for implementing it on file, group and unit still stands.

[DavidFatDavidF]

Hi there, rabularca and simonech,
the om should not raise an error when xml:lang is used on structural elements and notes, as xml:lang is allowed there as an extension.
It's also true as simonech mentioned that it's not recommended to use xml:lang on those extension points, unless you really know what you're doing.
Basically the only reason to use xml:lang there I can think of would be to manage notes in a third language or in a number of different languages. This would be still best achieved by having it locally on notes.. w/o messing with the main tree..
While the xml:lang on source and target is directly inherited from srcLang and trgLang and hence shouldn't really be affected by what you set as xml:lang on structural extension points. Chances are that the XLIFF could be edited by a generic XML processor that doesn't understand XLIFF business logic and for instance populates the xml:lang on source or target based on the xml:lang from the extension points. So it's fair to give a validation warning when using xml:lang on structural extension points and the om is of course correct in preventing that inline..

[invertedburger]

Hello,

I need to add xml:lang to note element. While generating Xliff I was able to successfully generate document with IExtension, IExtensionAttribute. There result looks like this.

<xliff xmlns:mda="urn:oasis:names:tc:xliff:metadata:2.0" xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:mtc="urn:oasis:names:tc:xliff:matches:2.0" srcLang="en-US" trgLang="ar-SA" version="2.1" xmlns="urn:oasis:names:tc:xliff:document:2.0">
...
<note category="Project Name" xml:lang="en-US">

But when opening generated file again, there is an issue and extension does not work. I looked into the library and problem is in XliffElement.cs, condition:

(name.Prefix == NamespacePrefixes.Xml)

This will block using extension for xml:lang. Removing condition solves the issue.

Whole method:

     SetAttributeResult IXliffDataConsumer.TrySetAttributeValue(XmlNameInfo name, string value)
        {
            SetAttributeResult result;

            result = SetAttributeResult.Success;
            if (name.LocalName == NamespacePrefixes.XmlNamespace)
            {
                // xmlns shouldn't be stored at all.
                result = SetAttributeResult.ReservedName;
            }
            else if (this.TrySetPropertyValue(name, value))
            {
                // Property saved.
                result = SetAttributeResult.Success;
            }
            else if ((name.Prefix == NamespacePrefixes.Xml) || Utilities.IsModuleNamespace(name.Namespace))
            {
                // xml:xx is not an extension.
                // Known modules cannot be stored as extensions.
                result = SetAttributeResult.InvalidAttribute;
            }
            else
            {
                // abc:xx might be an extension.
                result = SetAttributeResult.PossibleExtension;
            }

            return result;
        }

Is this expected behavior? Am I doing something wrong?

[VladimirRybalko]

This feature is available in the forked repository: Xliff.OM.NetStandard.
Feel free to use it.
Don't hesitate to create an issue there in case of any questions.