Re: [docbook] Entities vs olinks

["Bob Stayton" <bobs@sagehill.net>]

Hi Steve,
Can you say *why* you don't recommend Olinks for this purpose?

Bob Stayton
Sagehill Enterprises
bobs@sagehill.net


----- Original Message ----- 
From: "Steven Cogorno" <Steven.Cogorno@Sun.COM>
To: <Kate.Wringe@sybase.com>
Cc: <docbook@lists.oasis-open.org>
Sent: Friday, January 29, 2010 2:51 AM
Subject: Re: [docbook] Entities vs olinks


> Kate,
>
> I would not recommend OLinks for this purpose.
>
> Have you thought about expanding the text entities before the document goes through 
> translation memory?  We do that for our translations because the text entity word 
> order often doesn't make sense in other languages anyway.
>
> -Steve
>
>
> On Jan 28, 2010, at 2:51 PM, Kate.Wringe@sybase.com wrote:
>
>>
>> We need to tie our software resource-strings ( e.g., the strings that contain the 
>> text used in dialogs, windows, etc.,)  to our documentation but we can't use 
>> entities. Any suggestions?
>>
>> The problem we discovered with entities is that our translation software is unable 
>> to display the entity values (unlike our XML authoring software-oXygen).
>> So, our translators are forced to work with the entity names (e.g., 
>> &ml_oracle_driver; ) instead of the entity values (iAnywhere Solutions 12 - Oracle 
>> ODBC driver). As
>> you can imagine, this severely limits the number of entities we can have in our 
>> documentation.
>>
>> Currently, we have about 14,000 instances in our collection that contain the text 
>> from our software-resource strings. These instances are currently tagged with a 
>> guilabel
>> element. Also, our software resource-strings are available in an XML (XLIFF) file 
>> that we would love to be able to connect to our XML docs.
>>
>> An idea that we have been kicking around involves embedding the entity value (e.g, 
>> iAnywhere 12-Oracle ODBC driver) within the xml file (so that the
>> translators can see the text). We were thinking about a solution that would work 
>> similar to how we use our olinks (except that it wouldn't create links in the 
>> output).
>>
>> This is currently how our olinks are processed:
>> 1) We use xslt to build olink.db files for each of our books.
>> 2) We author in oXygen, so we insert our olinks using an olink dialog that oXygen 
>> implemented for us. Our olink tags look like the following in our
>> documentation: <olink targetdoc="dbadmin" targetptr="da-backup-dbs-5679299">Types 
>> of backup</olink>.
>> 3) The contents of the olink tag (e.g.,Types of backup) are replaced during the 
>> xsltbuild; although, they are not updated in the xml files during the build. To 
>> update
>> the files, we periodically run a refresh olink tool within oXygen.
>>
>> Our idea was to use the XLIFF file to create a .db file that could be used to 
>> insert olinks or xlinks in the XML files. The XSLT build would replace/update
>> the software-resource-string text during the build.
>>
>> Has anyone done something like this?  Any advice or suggestions would be greatly 
>> appreciated. We are also wondering whether we should
>> attempt such a solution with the olink element (with an attribute) or the xlink 
>> element.
>>
>> Thank you (again!),
>>
>> Kate
>>
>>
>> ..........................................................................................................................................................................................................................
>> <Mail Attachment.jpeg> Kate Wringe | Tech Writer 2| Sybase
>> 445 Wes Graham Way, Waterloo, ON, N2L 6R2 Canada | Tel: (519) 883-6838 | 
>> kate.wringe@sybase.com | www.sybase.com
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-help@lists.oasis-open.org
>
>
>