Re: [docbook-apps] Best practice for multilanguage Docbook?
Hi Bob, now that you have explained it, I now understand my own question ! Thanks. I will be writing both documentation (English French) in a single document (or xinclude), which is not the scenario which publican was designed for. I'll use profiling. Thanks. On Mon, Mar 14, 2011 at 10:01 PM, Bob Stayton b...@sagehill.net wrote: Hi Mathieu, I don't think there is a single best practice because different people have different requirements. If it is a single document and you are handling the translation, then a single multi-language source document and profiling would be fine. If you have lots of documents and/or many languages, a different approach might be more efficient. Further description of your requirements might generate a more detailed response from the list. One question is whether the document will need to be maintained, that is, updated with new information periodically. Each update will require retranslation, and the goal of the management system should be to minimize the cost of translation by minimizing the number of words to be retranslated. I've seen systems that break up the original language source document into modular sections, which are kept under source control. Modules are submitted to the translation service(s) as needed, based on a comparison of timestamps of the source and translated files. Someone should review the modules before submission to ensure real content changed, not just punctuation or product names that could be updated by you. Also, most translation services maintain translation memories, which means only changed content within a module will have to be retranslated, not the whole module. I don't think translation memories would work with a mixed language source document. Bob Stayton Sagehill Enterprises b...@sagehill.net - Original Message - From: Mathieu Malaterre mathieu.malate...@gmail.com To: DocBook Apps docbook-apps@lists.oasis-open.org Sent: Thursday, March 10, 2011 3:31 AM Subject: [docbook-apps] Best practice for multilanguage Docbook? Hi, I am looking for help/suggestion on the following issue: what is the best practice for writing a multilanguage docbook document ? docbook support the lang attribute in all elements, so I could use the profile mechanism to select generation of a target language based on that (*). However looking at the implementation in publican (**), they have preferred the 'pot' mechanism. Any comments/feedback on that ? -- Mathieu (*) http://www.mail-archive.com/docbook-apps@lists.oasis-open.org/msg03098.html (**) https://fedorahosted.org/publican/ - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org -- Mathieu - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] nested indexterms
I recently hit a problem with nested indexterms. While nesting an indexterm within an indexterm is invalid it seems there is a loop hole. If you put the systemitem tag within the primary tag then it allows an additional indexterm which is valid in a systemitem tag. I have not tried other tags. indexterm primary systemitemsystemitem indexterm primarynested indexterm/primary /indexterm /systemitem /primary /indexterm The validation process is not catching this in Arbortext or saxon. I build html and pdf output and it is only the PDF that is catching this with just a message but not breaking the build. java: [error] no entries for index key nested indexterm' I would like to address this in the DTD so the writers can catch this when validating but do not know where or how to state in the DTD to not allow nested indexterms once you nesting tags. I'm using Docbook 4.0 and I do have some customizations already so it is not a problem to add to my custom DTD. Can someone help? Thanks, Joy -- Joy Andree Software Developer II ANSYS, Inc. 275 Technology Drive Canonsburg, PA 15317 Tel: 724-514-2944 --- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
[docbook-apps] xinclude and olinking with entities
Hello, I do have a problem when assembling new documents with xincludes, turning external olinks to internal links by using entity-references, as it is described here: http://www.sagehill.net/docbookxsl/modular-olinks.html I put a reference to an external entity-declaration in a master document, i.e. one with includes, like that: ?xml version=1.0 encoding=UTF-8? !DOCTYPE book[ !ENTITY % entity SYSTEM entities.ent %entity; ] and have within that entities.ent - file all entities resolved to the master document, say *master.xml*: ?xml version=1.0 encoding=utf-8? !-- this is the entity-mapping for generating a frame document -- !ENTITY thisgoal master !ENTITY thatgoal master !ENTITY anothergoal master If the olinks in a included document are set like that: olink targetptr=targetindoc targetdoc=thisgoal; / then everything works fine since thisgoal; is resolved to *master*. But when I now include a part of that document into another one in *a different folder*, say master_2.xml and make for that another entities.ent file in *that same different folder*: ?xml version=1.0 encoding=utf-8? !-- this is the entity-mapping for generating a frame document -- !ENTITY thisgoal master_2 !ENTITY thatgoal master_2 !ENTITY anothergoal master_2 then the entities in the included file are still resolved according to the entities.ent where they are originally declared, which I find strange. I thought the entities would then be resolved according to the declaration of the including file, so that the olinks are correctly transformed to internal links. So it seems that the entities are being resolved before the include takes place? Any help is appreciated. cheers Benno
[docbook-apps] glossary template buglet?
In the default titlepage template for glossary, the title is formed from: title t.named-template=component.title [...] That seems wrong! In the manual that I'm hacking, that used the book's title at the top of the glossary. Changing it to use division.title made the expected glossary/title appear. Is this the correct fix? I am not very comfortable with the titlepage templates... Chris - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
Re: [docbook-apps] xinclude and olinking with entities
Hi, So it seems that the entities are being resolved before the include takes place? Yes, that is the case. Entities are resolved by the XML parser, and XML parsing must take place before an XInclude can proceed. It is mentioned at the end of the last bullet in this section: http://www.sagehill.net/docbookxsl/ModularDoc.html#XincludeTextEntities Bob Stayton Sagehill Enterprises b...@sagehill.net - Original Message - From: Benno Wolf To: docbook-apps@lists.oasis-open.org Sent: Wednesday, March 16, 2011 7:54 AM Subject: [docbook-apps] xinclude and olinking with entities Hello, I do have a problem when assembling new documents with xincludes, turning external olinks to internal links by using entity-references, as it is described here: http://www.sagehill.net/docbookxsl/modular-olinks.html I put a reference to an external entity-declaration in a master document, i.e. one with includes, like that: ?xml version=1.0 encoding=UTF-8? !DOCTYPE book[ !ENTITY % entity SYSTEM entities.ent %entity; ] and have within that entities.ent - file all entities resolved to the master document, say master.xml: ?xml version=1.0 encoding=utf-8? !-- this is the entity-mapping for generating a frame document -- !ENTITY thisgoal master !ENTITY thatgoal master !ENTITY anothergoal master If the olinks in a included document are set like that: olink targetptr=targetindoc targetdoc=thisgoal; /then everything works fine since thisgoal; is resolved to master. But when I now include a part of that document into another one in a different folder, say master_2.xml and make for that another entities.ent file in that same different folder: ?xml version=1.0 encoding=utf-8? !-- this is the entity-mapping for generating a frame document -- !ENTITY thisgoal master_2 !ENTITY thatgoal master_2 !ENTITY anothergoal master_2 then the entities in the included file are still resolved according to the entities.ent where they are originally declared, which I find strange. I thought the entities would then be resolved according to the declaration of the including file, so that the olinks are correctly transformed to internal links. So it seems that the entities are being resolved before the include takes place? Any help is appreciated. cheers Benno
