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: Re: Marked up and edited acronym proposal


Hi Andrzej,

Thanks for the fixed word.

I will expand the sections. The information is there, I just need to develop it. I'd like you to review it though before I send it to the SC for review. Are you OK with this?
 
Gershon L Joseph
Director of Technology and Single Sourcing
Tech-Tav Documentation Ltd. 
Secretary, OASIS DITA Technical Committee
Secretary, OASIS DITA Translation Subcommittee
Member, OASIS DocBook Technical Committee
 
+972-8-974-1569 (direct)
+972-57-314-1170 (mobile)
http://www.tech-tav.com

----- Original Message ----
> From: Andrzej Zydron <azydron@xml-intl.com>
> To: Gershon L Joseph <gershon@tech-tav.com>
> Cc: JoAnn Hackos <joann.hackos@comtech-serv.com>; DITA Translation SC <dita-translation@lists.oasis-open.org>
> Sent: Sunday, November 25, 2007 11:59:00 PM
> Subject: Re: Marked up and edited acronym proposal
> 
> Hi Gershon,
> 
> Apologies, but I have been traveling over the weekend. I have
> corrected
> 
 
> the Polish as requested. Unfortunately, the expansion of the sections 
> will take a bit longer, as I need to think them through thoroughly.
> 
> Best Regards,
> 
> AZ
> 
> Gershon L Joseph wrote:
> > Hi Andrzej,
> >
> > I have cleaned up the markup (and moved the Doctype to point to
> the
> 
 OASIS spec). I also did technical and general editing.
> >
> > As agreed in the SC meeting this past Tuesday, I also changed
> the
> 
 name of the 'abbreviate-form' attribute to 'abbreviated-form' (added
> the
> 
 'd').
> >
> > Here is the marked up proposal. I noticed that the example
> using
> 
 OASIS used the wrong expanded form. The last 'S' stands for Standards,
> not
> 
 Systems. Andrzej, please could you fix the Polish expanded word in
> the
> 
 XML, since I can't do that ;-)
> >
> > Please could you fix the error ASAP and send the proposal back to me.
> >
> > While we probably could submit the proposal as-is after your fix,
> I
> 
 think we need to expand the following sections:
> > Rendition (I want to clarify the tasks processors are expected to
> do
> 
 in this section, since most of that information is currently
> scattered
> 
 over the proposal)
> > Technical Requirements (I refer to the above info, but
> should
> 
 probably specify the exact changes herein)
> > New or Changed Specification Language (I told them to read the
> rest
> 
 of the proposal, but would like to expand this out...)
> >
> > I will try to get to these 3 sections on Sunday so we can at
> least
> 
 get this proposal to the DITA TC at the next meeting, for discussion
> the
> 
 following week.
> >
> > Thanks,
> > Gershon
> >  
> > Gershon L Joseph
> > Director of Technology and Single Sourcing
> > Tech-Tav Documentation Ltd. 
> > Secretary, OASIS DITA Technical Committee
> > Secretary, OASIS DITA Translation Subcommittee
> > Member, OASIS DocBook Technical Committee
> >  
> > +972-8-974-1569 (direct)
> > +972-57-314-1170 (mobile)
> > http://www.tech-tav.com
> >
> >
> >   
> 
> 
> -- 
> email - azydron@xml-intl.com
> smail - c/o Mr. A.Zydron
>     PO Box 2167
>         Gerrards Cross
>         Bucks SL9 8XF
>     United Kingdom
> Mobile +(44) 7966 477 181
> FAX    +(44) 1753 480 465
> www - http://www.xml-intl.com
> 
> This message contains confidential information and is intended only for
> the individual named.  If you are not the named addressee you may not
> disseminate, distribute or copy this e-mail.  Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system.
> E-mail transmission cannot be guaranteed to be secure or error-free as
> information could be intercepted, corrupted, lost, destroyed, arrive
> late or incomplete, or contain viruses.  The sender therefore does not
> accept liability for any errors or omissions in the contents of this
> message which arise as a result of e-mail transmission. 
> If
> 
 verification
> is required please request a hard-copy version. Unless
> explicitly
> 
 stated
> otherwise this message is provided for informational purposes only and
> should not be construed as a solicitation or offer.
> 
> 
> 
> 
> -----Inline Attachment Follows-----
> 
> 
> 
> 
>  "reference.dtd">
> 
> 
DITA Proposed Feature # 12038> 
> Add a new element based on an expansion of the extant
> DITA
> 
 
> ><keyword> element to assist in the resolution and handling
> of abbreviated-form text such as acronyms, general abbreviations,
> and short forms in source and target text within
> DITA
> 
 documents
> 
> Longer description       Abbreviated
> forms, such as acronyms, are ubiquitous in
> technical
> 
 documentation.
> Although there are similarities between abbreviated forms and glossary
> terms from the localization and presentation points of
> view,
> 
 abbreviated
> forms are a special case. Abbreviated forms need to be expanded in
> the first encounter within a printed document. In electronic published
> documents, abbreviated form expansions can also be made available
> in the form of a hyperlink or 'tool tip' mechanism. In addition, the
> abbreviated form expanded text should be available for
> automatic
> 
 inclusion
> in glossary entries for the publication. This proposal relates to
> all types of abbreviations, such as acronyms, initialisms, apocope,
> clipping, elision, syncope, syllabic abbreviation, and portmanteau.

> >
> Statement of RequirementAbbreviated forms
> and their translations require special handling:

> Some abbreviated forms are never translated, especially those
> that are intended for a knowledgeable, technical audience, as well
> as those that refer to standardized international concepts, such
> as
> 
 
> >XML.
> Some abbreviated forms represent a brand name for which
> the
> 
 original
> expanded form is no longer used or is secondary to the abbreviated
> forms.
> Abbreviated forms such as xml, jpg,
> and html are typically used in their original form, that
> is, they may be quoted in lower case, and they are not translated.
> Abbreviated forms that have equivalent expressions in
> other
> 
 languages
> are typically translated. United Nations (UN) and Weapons of Mass
> Destruction (WMD) have equivalents in other languages besides English.
> For instance, the French translation of “UN” is “ONU”.
> Some abbreviated forms are translated for clarity and also referred
> to in their original untranslated form. For instance, OASIS
> > may be translated so that readers understand its significance in
> their native language but the original acronym would be retained in
> the translation to facilitate electronic search.
> The first occurrence of an abbreviated form in the target language
> may require a different formulation than the first occurrence of an
> abbreviated form in the source language, depending on the
> target
> 
 audience
> and the grammatical features of the target language.
> If the first occurrence of an abbreviated form in English
> is followed by its full form in parentheses, the translated version
> may require the expanded form followed by the abbreviated form in
> parentheses. It might also be necessary to include the English and
> a translation.
For example, in a Polish book on Java
> Web
> 
 programming,
> the first reference to JSP may appear as follows:
JSP (ang.
> Java Server Pages)Another example from a publication concerning
> OASIS:
OASIS (ang. Organization for the Advancement of Structured
> Information Standards—organizacja dla propagowania strukturalnych
> standardów infomracyjnych)In the first example, the translator
> assumes the reader will not require a translation of the
> English
> 
 abbreviated
> form. In the second example, the translator assumes the reader may
> not understand the English expanded form and therefore adds
> the
> 
 translation.

> >
> Technical<br />> ProposalThe
> 
 proposal
> is to create an element which would be a specialized form of
> the
> 
 
> ><keyword> element. The abbreviated form resolution will
> be via the conref attribute to the abbreviated form's
> text for short, expanded and first forms. The abbreviated form element
> is designed to be extended via specialization to reflect the actual
> form of abbreviation, for
> example:
<acronym
> 
 conref="acronyms.dita#acronyms/abs"/>
> >The entry in the acronyms.dita file would
> be as follows:
<abbreviated-form id="abs">
>   <expanded>Anti-lock Braking System</expanded>
>   <short>ABS</short>
>   <surface-form>Anti-lock Braking System (ABS)</surface-form>
> </abbreviated-form>The ID of
> the
> 
 abbreviated-form
> > element only needs to be unique to the file in which it is defined,
> and does not need to match the acronym, so translations of the above
> example will continue to use
> id="abs".The
> 
 
> ><expanded> form will be a specialization of the 
> ><keyword> element, while the <short>
> > element will be a specialization of the <data>
> > element. This means that the expanded term is a normal phrase, while
> the short form is metadata that is hidden when processes do not know
> what to do with it. Translation processes should treat this
> data
> 
 specialization
> as a subflow element for the purposes of translation. The 
> ><surface-form> element represents how the acronym should
> be displayed on the first occurrence of the acronym, or for hypertext
> display with the tool-tip rendition.

> 
> 
> 
> This new element…
> Is specialized from this base element…
> 
> 
> 
> 
> <abbreviated-form>
> <keyword>
> 
> 
> <expanded>
> <keyword>
> 
> 
> <short>
> <data>
> 
> 
> <surface-form>
> <keyword>
> 
> 
> 
> The first time an abbreviated form is encountered, the
> processing tool should use the text in
> the
> 
 <surface-form>
> > element. Subsequent instances should be replaced by the contents
> of the <short> element.
> The
> 
 <expanded>
> > form is designed to be used in glossaries. These three elements
> therefore allow the full needs of acronym handling to be met:

> First occurrence rendition
> Subsequent short form rendition
> Glossary entry
> This proposal assumes that <keyword>
> > can be nested inside <keyword>, which is not
> supported in DITA 1.1, but is a proposed feature of DITA 1.2 (see
> proposal #12020).     
> Translation IssuesThe following cases must
> be contemplated when working with documents that
> require
> 
 internationalization:

> >
> If there is no short form for the target language, then
> the
> 
 
> ><short> element will be empty to signify that no short
> form exists for this language. The <surface-form>
> > must always contain the text that will be displayed for the first
> occurrence. Consider the following example in English:

> ><abbreviated-form id="wmd">
>   <expanded>Weapons of Mass Destruction</expanded>
>   <short>WMD</short>
>   <surface-form>Weapons of Mass Destruction (WMD)</surface-form>
> </abbreviated-form>In Spanish, this becomes:

> ><abbreviated-form id="wmd" xml:lang="es">
>   <expanded>armas de destrucción masiva</expanded>
>   <short/>
>   <surface-form>armas de destrucción masiva</surface-form>
> </abbreviated-form>
> In some languages, like Spanish, abbreviated-form expansion
> should be written in lower case. This can lead to a grammatical error
> if the first appearance of an abbreviated form occurs at the beginning
> of a sentence. The same problem may arise with the indefinite article
> in English 'a' depending on whether the text to be inserted begins
> with a vowel. It is up to the composition/display software to handle
> this. For example, the acronym for AIDS should be translated as:

> ><abbreviated-form id="aids" xml:lang="es">
>   <expanded>síndrome de inmuno-deficiencia adquirida</expanded>
>   <short>SIDA</short>
>   <surface-form>síndrome de inmuno-deficiencia
> adquirida
> 
 (SIDA</surface-form>
> </abbreviated-form>Normally
> the
> 
 <surface-form>
> > version of the abbreviated form in the above example could not be
> used at the start of a sentence, because it begins with a lower case
> letter. It is up to the composition software for the given language
> to cope with these requirements.

> Abbreviated forms can cause problems primarily for inflected
> languages because abbreviated form expansion needs to be presented
> in the nominative case, without any inflection. This can be achieved
> by placing the expansion of the abbreviated form in
> parentheses
> 
 immediately
> following the acronym in the <expanded> element.
> For example, the Polish acronym for the European Union may be:

> ><abbreviated-form id="eu" xml:lang="pl">
>   <expanded>Unia Europejska</expanded>
>   <short>UE</short>
>   <surface-form>UE (Unia Europejska)</surface-form>
> </abbreviated-form>Using the above construct enables
> automated handling of the abbreviated form in Polish without causing
> any problems with grammatical inflection. For example, when stating
> that something occurred within the EU, the inflected form in Polish
> caused by the use of the locative case would have to be used. For
> the actual abbreviated form itself this is not a problem,
> since
> 
 abbreviated
> forms are not inflected. Consider, for example, the phrase In the
> European Union (EU) there are many institutions…:
W Unii
> Europejskiej (UE) jest wiele instytucji…
However, by allowing
> the translator to control how the text is displayed via the 
> ><surface-form> element, the first occurrence for the
> abbreviated form allows the translator to use the following acceptable
> construct:
W UE (Unia Europejska) jest wiele instytucji…

> >
> 
> RenditionAuthors will enter the 
> ><abbreviated-form> element for every occurrence of a
> given acronym.
At compose time, when putting together
> the
> 
 publication,
> the publishing tool will print the <surface-form>
> > element the first time. The ABS acronym used in previous examples
> would be rendered as:
The Anti-lock Brake System (ABS) system
> will prevent the car from skidding in adverse weather conditions.
> >Subsequent instances will then be rendered as:
The ABS system
> will provide the driver with feedback via the
> brake
> 
 pedal.
> Technical Requirements       A new 
> ><abbreviated-form> element needs to be created, which
> is a specialization of the <keyword> element.
> The content model of <abbreviated-form>
> was
> 
 described
> above in 
> scope="local" type="section">> text="Technical
> 
 Proposal"
> ?>.

> New or Changed Specification LanguageThe
> language for the language and architectural specifications can be
> taken from the information in the above sections. That information
> is not repeated here to save the user from having to read it
> all
> 
 twice.> Caret?>

> CostsWe do not believe that the addition
> of the <abbreviated-form> elements as
> a
> 
 specialization
> of <keyword>, and its child
> elements
> 
 <expanded>
> >, <short>, and <surface-form>
> > involve significant work.

> BenefitsAbbreviated forms will be handled
> in a uniform and consistent manner. The handling of the abbreviated
> form will be under the control of the composition software. The first
> occurrence of the abbreviated form can show
> the
> 
 <surface-form>
> >. The text for both the source and target languages will be consistent
> as it will be resolved via the conref attribute from
> a single source. The resolution of the abbreviated form can
> be
> 
 completely
> under the control of the composition software so that
> glossary,
> 
 tooltip,
> and first forms can be provided as required to meet the
> end-user
> 
 requirements.

> >
> 
> 
> 
> 
> 





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