You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of the serialize_xliff.pm XLIFF serializer is built around the concept of one source file per XLIFF interchange file. You can see this assumption in the serialize subroutine where it creates a new <xliff> element every time it is ran (Source). However, the XLIFF Spec specifically states its support for multiple source <file> elements within an <xliff> element (Source):
<xliff>
XLIFF document - The <xliff> element encloses all the other elements of the document. The required version attribute specifies the version of XLIFF. The optional xml:lang attribute is used to specify the language of the content of the document.
Required attributes:version. Optional attributes:xml:lang, non-XLIFF attributes Contents: One or more <file> elements, followed by Zero, one or more non-XLIFF elements.
Therefore, it seems like we could update the serializer to support something like an upsert boolean to its schema. If true, this would fetch the existing file's contents and look for a matching <file> element. If found, it would update its contents instead of creating a new <xliff> file from scratch.
The deserialize subroutine actually already parses this information correctly across multiple <file> elements because it uses a //trans-unit XPATH query (Source), but I think we'd need to update the deserialize subroutine's API to take in additional and optional arguments in order to only extract the content associated with the appropriate original source file.
What do you think?
The text was updated successfully, but these errors were encountered:
As an additional vote for this, xcodebuild -exportLocalizations creates one .xliff file per language. It has a <file> node for each localizable file within the workspace.
This is an enhancement.
The current implementation of the
serialize_xliff.pm
XLIFF serializer is built around the concept of one source file per XLIFF interchange file. You can see this assumption in theserialize
subroutine where it creates a new<xliff>
element every time it is ran (Source). However, the XLIFF Spec specifically states its support for multiple source<file>
elements within an<xliff>
element (Source):Therefore, it seems like we could update the serializer to support something like an
upsert
boolean to its schema. If true, this would fetch the existing file's contents and look for a matching<file>
element. If found, it would update its contents instead of creating a new<xliff>
file from scratch.The
deserialize
subroutine actually already parses this information correctly across multiple<file>
elements because it uses a//trans-unit
XPATH query (Source), but I think we'd need to update thedeserialize
subroutine's API to take in additional and optional arguments in order to only extract the content associated with the appropriate original source file.What do you think?
The text was updated successfully, but these errors were encountered: