Re: [dita] Product names and reuse

Title: Email signature standard

  
  
    Hi Kristen:

    

    At the former company, we attempted to restrict product names as
    untranslated, and this initially worked for western languages where
    we started first, but then it didn't work later for some eastern
    languages that already had a special trademark for that country,
    from what I remember. I think we had some problems too around
    feature names that in some cases simply had to be translated even
    for cultural reasons.

    

    We had Information Developer training around how to use product and
    feature name variables effectively by restricting the way we wrote
    around them to avoid translation common issues. 

    

    Finally, we avoided references to the product in general going
    forward. Fortunately, in software, we can often refer generically to
    the product as "the system" or application in context. Still, we had
    some high level material that required the product name and we would
    use the variable there.

    

    In most cases, we used the majority of variables for nasty,
    constantly changing feature names. :-)

    

    In another case, we had a specialized product that required
    variables for business object names that could be overridden by the
    customer, which we then output to in-place help variables with a
    dynamic mapping file. (Kind of cool, actually, though little seen
    elsewhere.) 

    

    In short, I don't think there is an easy answer that avoids changes
    to schemas, workflow, writing practices, and output processing for
    holding and processing an effective product or feature element along
    the lines of a variable, but once implemented, the automation and
    customization is very powerful.

    

    I have played around with content references with some success to
    simulate variables as used in a previous company. I forget what the
    specific limitations are, but I wasn't totally happy with it.

    

    If I were to create a variables architecture for DITA today using OT
    as a reference processor, I would create a generic schema for
    variables, then specialize attributes as needed for products and
    features (at minimum). Use a mapping file in XML to hold the
    resolved values and keys. Then create a processing plug-in for those
    variables, which might include special graphics associated with the
    product name, if needed (has actually happened).

    

    Troy

    

    On 1/16/2013 9:03 AM, Kristen James Eberlein wrote:
    
      
      

      

        
        
Troy, there were a couple of
          questions that I want to ask. Did the company's style guide
          restrict the content developers as to how they used the
          product names, for example, using product names only in the
          nominative case?

          

          Were the product names translated or left in English? I think
          translated, based on your post, but wanted to check -- some
          companies handle the problem of reusing company names by NOT
          translating them.

          

          You mentioned using attributes to indicate plurals or
          possessives; did you do anything to handle case or part of
          speech?

          

          Thanks for your interesting post!

          

          
Best,

            Kris

            

            Kristen James Eberlein

            Principal consultant, Eberlein Consulting

            Co-chair, OASIS DITA Technical Committee

            Charter member, OASIS DITA Adoption Committee

            www.eberleinconsulting.com

            +1 919 682-2290; kriseberlein (skype)

            

          

          On 1/16/2013 8:47 AM, Troy Klukewich wrote:

        

        
          
          Hi Andrzej:

          

          We translated the English XML content and mapping files into
          multiple languages, including Chinese, Japanese, and Arabic,
          which are probably some of the more difficult languages to
          translate. The agencies worked with our build kit and
          generated translated versions per language, including PDF.
          Granted, we had some great development resources to program
          the XSLT and XSL:FO appropriately to handle multiple
          languages. 

          

          I do remember some iterations where translation had to tweak
          the PDF output until we programmed a solution (indexing was
          challenging for Japanese, right-to-left languages, etc.). In
          any case, the amount of total manual work translation had to
          perform versus previous iterations was massively reduced with
          subsequent cost savings and rapid turn-around. From what I
          recall, we reached 100% automation for all languages handled.

          

          If you could be more specific about which language
          morphologies cannot work with variables, I'd be interested. In
          some cases, the best solution might be to dump out an XLIFF
          with resolved values for variables, so the base XML isn't
          translated, but the XLIFF version of the same with a two-way
          transformation back to the build kit for a translated version
          of deliverables.

          

          Some translation groups will work with build kits, some don't,
          so this also needs to be factored into workflow.

          

          So I suspect that there may be no perfect global solution to
          handle all possible languages from base DITA XML, but a
          technical solution that handles most and then an alternate
          workflow for those languages that cannot work with variables
          as such.

          

          Troy

          

          On 1/15/2013 1:34 PM, Andrzej Zydron wrote:
          
            
            
Hi Troy,

                

                Thank you for
                  this interesting post. Your mechanism will work for English,
                    and the small group of languages with a similar
                    primitive morphology. Unfortunately it will
                  fall apart when you come to translate the XML
                  content into any
                      language with a richer morphology - the
                        resultant output will produce ungrammatical
                            output and the cost of recovery from
                              this will be extensive. 

                            

                            English is a linguistic freak (a fact that
                                                is lost on most monolingual

                                                  English speakers)

              which allows for the relative easy substitutions that you described. I you plan to
                  translate your content into other languages this is
                    not a
                      practical
                        possibility.

              

              

                
                
                
                
                
                

                  
Best Regards,

                  

                    Andrzej Zydroń

                    

                  
---------------------------------------

                  
CTO

                  
XTM International Ltd.

                  
PO Box 2167, Gerrards Cross, SL9 8XF,
                      UK

                  
email:               

                    

                  
Tel: +44 (0) 1753 480 479

                  
Mob: +44 (0) 7966 477 181

                  
skype: Zydron

                  
www.xtm-intl.com