OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita-translation message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: DITA Translation Subcommittee Meeting Minutes: 26 June 2006

Hi all,

Here are the minutes from yesterday's meeting. Please note that we're NOT
meeting next week. Our next meeting will be 10 July.

Best Regards,

Gershon L Joseph
Member, OASIS DITA and DocBook Technical Committees
Director of Technology and Single Sourcing
Tech-Tav Documentation Ltd.
office: +972-8-974-1569
mobile: +972-57-314-1170
DITA Translation Subcommittee Meeting Minutes: 26 June 2006

(Recorded by Gershon Joseph <gershon@tech-tav.com>)

The DITA Translation Subcommittee met on Monday, 26 June 2006 at 08:00am PT
for 60 minutes.

1.  Roll call

        Robert Anderson
        Don Day
        Kevin Farwell
        Nancy Harrison
        Gershon Joseph
        Rodolfo Raya

        Felix Sasaki

2.  Accept the minutes of the previous meeting.
    Accepted. Moved by Robert, seconded by Rodolfo, no objections.

3. Review open action items:

    ACTION -- Andrzej to send terminology definitions to Gershon. Gershon to 
    add them to the document and ensure all text uses only these terms.

    ACTION -- Don to inform us where to publish our best practices.
        In progress.

    Action Item: Andrzej will provide examples to the group for discussion.

4.  Returning Business:

4.1 Discuss Gershon Joseph's draft of the best practice for legacy TM

    Rodolfo: Erase last paragraph, earlier paragraph says all we want to say.
    --ACTION-- Rodolfo will rewrite other problem paragraph and send to 
        Gershon by email. Gershon will send the revised document to Kevin for 
        review. Upon Kevin's approval, Gershon will post to the group for
        discussion and approval next meeting.

4.2 Management of conref blocks for translations

    The SC reviewed and discussed the following content, and recommends
    it be included in the authoring best practice document JoAnn and Andrzej
    are writing.

    * Standardized (boilerplate) text should be kept in one or more standalone 
        DITA files used as a source for conrefs across a document set. Better 
        to have your conref definitions placed in a central and easily 
        locatable location.

    * All boilerplate content for a language must be stand-alone.
        Boilerplate text must be stand-alone phrases to avoid problems translating
        it into some languages, where it does not fit into the surrounding text.

        Rodolfo - conref dangerous when used as inline element, and should only
        be used as stand-alone element. If conref contains a full sentence, it's 
        safer, but if it contains a product name or phrase, it's a problem for 

        Don: suggests "If conref is used, care should be taken to use it in a 
        manner that does not rely on adjectives or other modifiers, which will 
        result in bad translation".

        Most common scenario for phrase level conref is product names.
        Minimize impact to translation by ensuring you include only the product 
        name and no modifier within the conref phrase. This rule does not work 
        in every language, for example Polish (Andrzej's examples).
        Be aware that some target languages may result in other issues with the 
        translated conref. Therefore, the translated document must be reviewed 
        by the translator.

    * Conreffing to an inline element (may be part of the previous bullet)
        Conreffing to an inline element may result in a badly translated phrase 
        with respect to its surrounding content, so we should probably be 
        against this. Examples: singular/plural, prepositions, acronyms e.g. 
        ABS (antilock breaking system). So if you conref to the text itself, 
        the translated text may noA??????Rcorrectly. [We're not saying not to use
        conref, only that authors and translators must be aware of the dangers
        (side effects).]

    * Order of translation
        The conref targets should be translated before the parent document 
        that refers to the conref is translated.
        Indicate which document is the source document(s) for the conrefs, so 
        that translators can translate them first. It's important that the 
        conref content "fits into" the source documents cleanly where used.

4.3 XLIFF transforms

    Discuss plans for Rodolfo's tests of their XLIFF transforms and possible 
    release to open source. Ask if there is a proposed date.

    Andrzej and Rodolfo have successfully converted DITA to XLIFF and back.
    Rodolfo plans to publish their converter as open source.

    Don summarized - emails between Rodolfo and Brian Schnabel on creating XLIFF
    from DITA documents. Andrzej supplied xml-tm input, and discussions on 
    how to apply the namespaces. Brian should be part of the ongoing discussions.

    Rodolfo: Brian's tool works only at block level, not at sentence level. 
    Samples that I sent to list (which JoAnn forwarded) use sentence level 
    segmentation. I used our own tool with SRX to identify sentences
    within the block. If you go to www.heartsome.net you can request a demo of 
    the translation suite and convert DITA files to XLIFF and back.

    Don: What's the preferred workflow so that every vendor will assemble the 
    tool set correctly?

    Rodolfo: When transforming a block, there's an option to analyze the block 
    to break it down into sentences and even smaller blocks if required (by 
    looking for fullstops, colons (begin list), etc. XSLT is not good at this, 
    we use a Java program to do this.

    Don: We should discuss what we expect from the XLIFF document -- preferred 
    workflow and what XLIFF file should contain. If XLIFF file is generated 
    from Brian's tool, the translator can break the blocks down further in the 
    CAT tool later.

    Don: We should create a best practice for the use of XLIFF in translation.

    Gershon: Workflow would be Brian's tool is used to convert DITA to XLIFF, 
    send XLIFF files out to translation provider, get XLIFF back, transform 
    back into DITA and publish to target outputs.

    Rodolfo: That's true for open source tool chain, commercial tools let you 
    export to XLIFF, pretranslate using TM, segment, etc., translate and then 
    export to XLIFF for import back into DITA.

    Rodolfo: Another workflow is to send the DITA content to the translator.

    Rodolfo has a workflow document published on IBM DeveloperWorks we could
    use as basis for the best practice document. This doc is at:
    Another useful document on XLIFF is at:

    Discussion on copyright of the DeveloperWorks document. No copyright issues.

    Don: Yves should be on review list of this best practice document.

    --ACTION-- Rodolfo to prepare an outline for this best practice document 
    for translating DITA and submit to list for discussion at a future meeting. 
    At that meeting, SC should agree on the outline.

5.  New Business:

5.1 Handling multi-language documents

    Charles Pau and others to provide examples to the list for discussion

    Don requests to move this item to the agenda of the next meeting.

5.2 Andrjez provided examples of the need to change reusable building block 
    to the group for discussion. We need to discuss this at a future meeting.

6.  Announcements

    The SC will not meet on July 3. Next meeting will be on July 10.

Meeting adjourned at 09:00am PT.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]