[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita-adoption] Groups - DITA/XLIFF Feature Article (DITA12XLIFFArticle.pdf) uploaded
Good comments, Gershon. Regarding your rewording about catalogs, please delete the word
"proprietary" in front of "tools". Not only doesn't it
really make sense (I'm not even sure what a proprietary tool is, but whether a
tool is proprietary or not has nothing to do with what catalog standards it
supports), but the wording as it stands makes support of the OASIS TR9401
Catalog standard sound "proprietary" rather than following an OASIS
standard. Finally, the word is just unnecessary and superfluous. paul From: Gershon Joseph
[mailto:gerjosep@cisco.com] Hi JoAnn, Here are my comments from reviewing this draft, including my
action to reword the catalog item: Cover page: - The following (below the Editor line) does not make sense:
*OASIS*
On behalf of the DITA Adoption Technical Committee *Technical Committee* Should it not be: On behalf of the OASIS DITA Adoption
Technical Committee? "OASIS" is in the wrong place, and "Technical
Committee" appears twice. Page 3: We need an entry in the Document History. We can't
vote on the document without it. I assume this is our initial revision being
submitted to OASIS for formal approval... May need to check with Chet how we're
supposed to word it. Is the Revision a number? Summary would probably state
something about this being the initial draft the TC developed for formal OASIS
approval. General question: We have more blank pages than pages with
text. Does the OASIS PDF template require a duplex page layout? That may make
sense for printed paper, but is annoying for PDFs read online. Should I ping
Chet on this issue? I don't think it works for short documents like our
articles. Page 7, first paragraph: Change "it
is not possible to predict level of cost reductions in advance." to "it is not possible to predict *the* level of
cost..." Page 7, "Initial workflow", end of first
paragraph: Once your project is ready for translation,
convert your maps to XLIFF format using a translation tool that supports DITA. This implies only the map is converted to XLIFF. This is
incorrect, the referenced topics are also converted to XLIFF. We need to recast
this sentence so that it's not misleading. I suggest: Once
your project is ready for translation, convert your maps *and topics* to XLIFF
format using a translation tool that supports DITA. Same section, second bullet: read
the map(s) and generate matched-hierarchical XLIFF The tool presumably also resolves the topic references and
therefore reads the topics as well, to generate the XLIFF. I think we should
clarify this. Page 8, first bullet (this is my action item from our
previous meeting): support your DITA specializations by using
OASIS XML catalogs and allowing custom configuration of elements and attributes
that are translatable I suggest we rewrite this bullet as follows (note I've added
2 sub-bulleted items here): support your DITA specializations by * validating the content against your DITA
specializations (the use of OASIS XML catalogs is strongly recommended, but
proprietary tools may have other ways to resolve the components of your DITA
specializations to validate content) * providing a means to indicate which elements and
attributes are translatable Page 8, step 1: The <map> is missing @id; please add
@id="birds" to the opening <map> element. If you make this
change, I assume the code in step 2 needs to be updated (you may need to check
with Bryan on this). Currently we have <trans_unit id="map"
resname="title">, but based on how the topics get converted to XLIFF, this may
change to @id="birds_t, but because it's the map and not the topic I'm not
100% sure (and don't have time to check the XLIFF spec right now). Page 8, step 1: Please add the following to each of the
topic files (ideally I'd like us to include the @encoding too, but I have not
added them here): <?xml version="1.0"?> <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA
Concept//EN" "concept.dtd"> I think it would be clearer if we state the filenames for
each file we're showing. I had requested this previously, too. The bookmap
presumably would be birds.bookmap, though the filename in step 2 (in the XLIFF
file) states birds.dita -- I think that's a mistake. Page 8, step 2, XLIFF file code: I think the
@original="birds.dita" is wrong, it should be "birds.ditamap
(please see my previous comment). Page 9, step 3. PDF of what? I requested we state "PDF
of the source content" to make it clear. Please add this change. Page 9, step 4: Please make the relevant changes I requested
to step 2 to this XLIFF code as well. Page 9, step 5: Please add in the changes I requested to
step 1 (file names and XML + doctype headers). Page 10, step 3: Is this done in the translation tool? If it
is, I think we should say so. Page 11, step 7, missing space between "between"
and "the" in the second paragraph. Page 11, step 8: I think this is wrong. Do we really want to
send the XLIFF in the source language? I thought we wanted to send the XLIFF we
got out of the above steps, which is partially translated. It's the PDF for
context that should be in the source language. This is my understanding... That's it for now ;) Gershon On Aug 27, 2011, at 1:21 AM, joann.hackos@comtech-serv.com
wrote:
The document revision named DITA/XLIFF Feature Article |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]