RE: [xliff-comment] Representation of Dialog-level Data

["Yves Savourel" <ysavourel@translate.com>]

Hi Florian, thanks for the comment.

The comment pertains to the very early draft of the Windows RC profile some
of us worked on many months ago. The TC will take this in account (along
with the other comments you already sent) when the work on the profile
resumes. This highlight again the need to publish profiles for the main
formats (HTML, RC, Properties, etc.) as soon as possible.

My personal take is that I would tend to agree with the proposal. At the
same time I can see some occurrences when having the data at the <group>
level may be more intuitive. Maybe the solution is to have them in both the
<group> and the first <trans-unit> (it would be merely explicitly outputting
the implicit inheritance).
That is how I have (so far) implemented our RC filter.

Cheers,
-yves



===========================================
Original:

Dear TC,

I'm not happy with XLIFF representation for dialogs (3.6.1. Dialog Box-Level
Data). I assume that you already have discussed this issue in detail and
came up with this soultion, but still let me give my comments;-) My question
is where to place dialog attributes coord, font, style which are likely to
be changed. The changed values will have to be written to the target of the
first trans-unit.

When processing an XLIFF file we normally can work with this rule: To get
target information look for a target element and use the contents. For all
attributes which could be of interest, check if the target has them, if not
look up one level (trans-unit) and use those values.

According to the document this will not work for a dialog because in this
case the attributes are stored in the group and not in the first trans-unit.
Even if the definition looks natural (coord belong to the dialog-group), it
in fact makes processing more complicated. For a dialog which normally
contains a caption we already need a special trans-unit to keep the caption
text. But this one has also to be handled differently from other trans-unit
in terms of where to look up attributes.

Storing the dialog attributes in the first trans-unit gets together all
localizable information in much the same way as it is done in all other
cases. We just need to keep in mind that the first trans-unit contains
information about the dialog.

This is a style issue but it also has practical impact: The need to look up
attributes from a higher group-level than a trans-unit means more checks and
processing time  because groups can be defined for other reasons at any
level and the nearest parent group must not be the right one. It is also not
good to simply look up the request parent in the chain of parents to take
the first one. This might cause problems for other resource formats. These
formats are not defined yet, but why not use a scheme that will work fine
for other resource formats, too.

So my proposal is: For a dialog put all the attributes but restype and
resname from the group to the first trans-unit.

Best regards from Bonn,
Florian


Florian Sachse

Managing Director
PASS Engineering GmbH
Remigiusstr. 1
53111 Bonn
Germany

phone: +49-228-697242
fax: +49-228-697104
email: fsachse@pass-engineering.com
web: www.passolo.com
egroup: www.egroups.com/group/passolo