[xliff-tools] XLIFF detailed questions
xliff-tools at triplespin.com
Sat Jan 14 12:03:29 PST 2006
On 14 Jan 2006, at 17:43, Martin Wunderlich wrote:
> Dear all,
> May I trouble ye with a few very detailed questions regarding XLIFF
> and its implementation? I had a very close look at the specs and there
> are a few that are not entirely clear to me. Here we go:
> Under header-glossary a "glossary description" as contents for this
> element. Is this to be understood as a simple text node?
The contents of the the glossary is either an <internal-file> or an
<external-file> element. The external-file element is strictly
defined, whereas the internal-file element isn't, so I wouldn't
imagine that it is necessarily safe to assume that this will only
ever contain text nodes.
> <prop> element: Does anyone have examples for "Tool-specific data or
> text, no standard elements."? Again, is this to be interpreted as a
> text node? (I know this element has been deprecated, but for backward
> compatibility it should be taken into account, I guess)
I took "Tool-specific data or text, no standard elements." to mean
that the contents of the prop element was at the sole discretion of
the tool maker, as long as it didn't contain an Xliff defined
element. As an example, I support the use of xliff files as base
formats as well as just interchange formats, so I used the prop
element to remember document preferences, such as last window position.
Also, as it specifically mentions data as well as text, I imagine
that it would be possible to encounter nodes other than text nodes.
Presumably, unless your tool is the tool that created the prop
information, you shouldn't try to interpret it, or change it.
> There are several elements, e.g. <tool>, which may contain "Zero, one
> or more non-XLIFF elements." What are these elements and how are they
> to be handled?
The tool element defines a tool in some detail. Other elements can
then reference that information simply by providing the id. It saves
those other elements having to provide repetitive information in a
Phase works in a similar way - describes information about a workflow
phase, then allows that information to be referenced by other
elements simply by providing the name - almost like a short-hand.
Is that what you meant by "What are these elements"? Or have I
gone off on a tangent?
> Something rather curious for the <group> element. It says: "One or
> more <group>, <trans-unit>,
> <bin-unit> elements, in any order." Does this mean every group
> element _must_ contain at least one more
> group element and at least one bin-unit element?
I took this to be "or" rather than "and" - so at least one trans-
unit, or group, or bin-unit. However, I don't reject a file just
because it has a group with no children! :-)
> <bin-target>: In the description it says: "The optional state and
> state-qualifier attributes indicate
> in which state the <bin-target> is."
> The list of optional attributes is given as: "mime-type, ts, state,
> phase-name, restype, resname." No
> mention of a state-qualifier here. Does bin-target have a state-
> qualifier attribute or not?
Well spotted - I never noticed that. Although if you look at the
state-qualifier attribute you'll find :
"State-qualifier - Describes the state of a particular
translation in a <target> or <bin-target> element."
> <bx /> has optional attributes 'ctype' and 'clone'. <ex /> doesn't.
> Does this mean that the values of
> these two attributes by extension also apply to <ex />?
The <ex /> is directly connected to the <bx /> via the rid - and is
just an end marker for it, so it doesn't need the ctype and clone
attributes. That's the way I took it up anyway...
> Phew, that's all for the moment. Thanks a lot for any help in advance!
Hope it clarifies things rather than muddies them!
LocFactory Editor: a smart editor for Xliff, gettext (po),
WorkGlossary and other common localisation formats.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xliff-tools