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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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


Subject: RE: [dita] RE: Element-by-element recommendations for translators




> -----Original Message-----
> From: Rodolfo M. Raya [mailto:rmraya@maxprograms.com]
> Sent: Monday, 2009 October 12 18:43
> To: dita@lists.oasis-open.org
> Subject: Re: [dita] RE: Element-by-element recommendations for
> translators
> 
> On Mon, 12 Oct 2009 19:16:02 -0400
> "Grosso, Paul" <pgrosso@ptc.com> wrote:
> 
> > > -----Original Message-----
> > > From: JoAnn Hackos [mailto:joann.hackos@comtech-serv.com]
> > > Sent: Monday, 2009 October 12 18:06
> > > To: dita; Grosso, Paul
> > > Subject: Element-by-element recommendations for translators
> > >
> > > Paul Grosso commented that this topic does not belong in the Arch
> > Spec.
> > > However, this topic is essential for localization service
providers
> > > to know how to correctly set their systems to include or exclude
> > > certain elements from the translation workbench. We specifically
> > > requested
> > that
> > > it be added to DITA 1.1.
> > >
> > > Why should this topic be excluded? I also don't see why it is a
> > subject
> > > for the Adoption TC since it is a requirement for implementers.
> >
> > Implementors of the DITA spec?  Or localization service providers?
> >
> > In any case, what does this have to do with DITA architecture?
> >
> > I would imagine this large topic is of no use/interest to most
> > DITA implementors.  If none of this topic is normative as far as
> > basic implementation of the DITA standard is concerned, then perhaps
> > it should be an informative appendix to the language spec.
> 
> Hi,
> 
> This topic is essential for developers of translation tools that
> support
> DITA.
> 
> Translation tools parse DITA files and need to understand their
> internal details. Knowing how to collect the topics referenced in
> a DITA map is a must. Understanding the scope of the "translate"
> attribute is essential. To manage conrefs, keyrefs and all refs is a
> challenge that needs to be addressed. Support specializations is also
> necessary.
> 
> If you want DITA files to be easily localizable, increasing their
> usefulness, you have to provide reference material for localization
> tool developers.
> 
> Robert Anderson did a great job maintaining the tables that indicate
> how
> to treat elements. I personally used that material in different
> translation tools and found it valuable.
> 
> If DITA files are treated as just another XML format by translation
> tools, localization of DITA content results in a bad experience. Avoid
> that pain to end users simply collaborating with translation tools
> developers. The best way to help is indicating what needs to be
> translated and how to do it.

Okay up to here.  I am willing to stipulate the information is useful.

> The best place for writing that vital information is the Architecture
Spec.

I do not understand why.  This is not architectural.  It is a list 
of information about elements in the DITA vocabulary giving certain 
processing semantics for those elements.  If this is necessary
information for each element in the DITA language, then it should
probably be specified in the description of each element in the
language spec, but since this is probably too much work at this
point, then it should be a section in the language spec.  Not
the architecture spec.

paul



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