[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook] Entities vs olinks
On Jan 29, 2010, at 11:03 AM, Bob Stayton wrote: > Hi Steve, > Can you say *why* you don't recommend Olinks for this purpose? These aren't really cross references (in the linking sense). So, you have to build all kinds of exceptions into downstream processing to treat them as "non-links." For example, the HTML processor has to know that OLinks are hypertext, except for those that are really these other string type Olinks. Same with the PDF engine, and so on. The more exceptions there are, the more complex and difficult it is to process the documents. It's much easier, IMO, to use entities and then work around the one case where entities don't work (in this situation, the translation memory engine). This will require a preprocessing step before translation, but it won't disrupt any other downstream processes. I prefer the Ockham's razor approach whenever possible. Change the *process*, not the markup. Another alternative would be to use an element that more closely matches the actual data type. Then use an attribute to identify the "entity" name and have a pre-processor update the element content with the latest replacement text. The downside here is that this update needs to happen for all outputs, not just L10N deliveries. The most important reason why I think direct text expansion *before* translation is the optimal solution is because the translation of the entity text itself often depends on the surrounding text. Phrases or words that can be used in multiple contexts within English documents often won't make sense in a translated document. If the entity has been expanded to plain text *before* translation, then the translator can alter the text as needed in each context. But if OLink or some other replacement is done *after* translation, there can only be one replacement per entity, regardless of context. Hopefully that makes sense. Sorry I didn't give more background before... -Steve > > 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 >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]