Re: [docbook-apps] Multiplatform toolchain for outputting "nice" PDF
> On Jan 22, 2024, at 15:47, Thomas Schraitle wrote: > > If I'm not mistaken, there is no direct summary of changes between DocBook 4.5 > and 5.1. > > However, you can review the changes between 4.5 and DocBook 5.0 here: > > https://tdg.docbook.org/tdg/5.0/ch01#introduction-whats-new > > There is another summary that also includes changes between DocBook 5.0 and > 5.1 > which you can see here: > > https://tdg.docbook.org/tdg/5.2/ch00-online#changes-in-52 > > Hope that helps. :) It does. Thank you. - 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] UI strings vs manual strings ?
> On Dec 13, 2022, at 19:28, Tony Graham wrote: > > What result are you looking for? I am looking for an authoring process where software UI strings can easily be handled in the documentation. I'm imagining that there would be an editor that uses a UI strings "library" as reference and calls its contents when required in the doc during the build process. What would be the best way to achieve that in a DocBook centered process? > Are you treating one language (say, English) as the main language (which > has empty elements for value lookups) and the other languages as end > products (which have all text filled in), where you'd use OmegaT's > translation memory to keep translations consistent across revisions? I'm not sure I understand the above question, even though I've been using OmegaT almost daily for the past 20 years. > Or do you want the other languages to be structurally equivalent to the > main version (apart from inline elements moved around because of > sentence structure), where elements containing text are turned back into > empty elements? I don't understand the second part "where elements containing text are turned back into empty elements?". Jean-Christophe > > Regards, > > > Tony Graham. > -- > Senior Architect > XML Division > Antenna House, Inc. > > Skerries, Ireland > tgra...@antenna.co.jp > > - > To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org > For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org > -- Jean-Christophe Helary @jchel...@emacs.ch https://traductaire-libre.org https://mac4translators.blogspot.com https://sr.ht/~brandelune/omegat-as-a-book/ - 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] UI strings vs manual strings ?
Thank you all for the replies so far. Let me reply in one mail. > On Dec 6, 2022, at 21:44, Tony Graham wrote: > >> Problem at hand: >> - a Java application with ~2k UI strings (not all users facing), in >> a Bundle.properties file > > Java also has an XML format for properties files. Interesting. It could be part of a solution (esp. considering Florimond's reply). >> - a ~80K words DocBook manual >> It is not trivial to keep track of the whole string set (searches, etc.) >> Also, the l10n process takes place on the DocBook sources, not on >> the HTML output, so tricks like don't work because >> translators don't see the target terms. > > Before translation, replace each with the replacement text from > the XML properties file wrapped in a well-known element that still > carries the identifier for the properties file entry. > > After translation, if necessary, convert the well-known elements back > into and also do something to handle the strings that have been > translated differently in different places. The problem is that it's not possible to do that for a lot of languages. There are inflected forms that transform the text of the "endterm" part and the translation targets 3 dozen languages, including BiDi documents. That process would add another layer of transformation+verification. Or maybe I missed something? > Once you have the properties file for a second language, you could > insert the translated strings in place of when preparing for > translation. Alternatively, or as well, you could set up your > computer-aided translation tool to not translate the well-known elements > for the strings and insert the translated strings after everything else > is translated. It looks feasible but only with a small set of target languages. >> I'm left with having to rewrite the strings explicitly and that's a pain, >> and also adds risks of mistakes in translations. > > The more that you can automate, the better. Hence the question ;-) > On Dec 6, 2022, at 22:04, Alemps Florimond wrote: > > Hello, > > I would transform the bundle.properties in a document (article, book or > section whatever) > Each line of the file corresponds to somethine like : > My message > > One element simpara for one guilabel is useless : it is just to make it > readable in a DocBook parse. Interesting. Considering that Java properties can also be expressed as XML there could be some automation here. > In the document, you include the message - something like : > You should see xpointer="messageId"> after clicking on the button. > > The French, English, German version of the document will take advantage of > the corresponding translated version of bundle.properties.xml Why only those 3 languages? My understanding of xi:include is that it is not required to be resolved before the actual documentation build process. Which means that the document to translate (and the way it is displayed in the tool) is actually > You should see after clicking on the > button. Which is not different from what we have now with > As far as no id message starts with a number (NC Name for xml:id) you are ok. > With an XSLT 2.0 processor, it might even be possible to transform the > bundle.properties in XML. It looks like Java properties can be expressed as XML natively (see above) so there is something to explore here. > On Dec 7, 2022, at 5:13, Jan Tosovsky wrote: > > On 05/12/2022 23:05, Jean-Christophe Helary wrote: >> What's the best way in a DocBook centered process to ensure that the >> list of terms used in a software UI is (semi-automatically?) taken >> into account in the DocBook sources that describe that software? > > In your document you can use and other which can indicate the content must match the GUI label. You can then > instruct the localization agency to follow this rule. > But there is no way to avoid human error so this still has to be checked > manually which is inefficient. The problem is not instructions, the problem is to lower the burden of the translators by explicitly displaying the strings in the DocBook sources. Creating a normative glossary from the UI strings first could be something, but there are Windows/Linux mnemonics (&) characters in the strings so we'd need to remove them to create that glossary and that would add another step (which can be automatized I guess). Full disclosure: the manual is for OmegaT, a free software solution for translators, that supports DocBook out of the box, and Java properties too. I am project leader, also in charge of the manual, I made a close to full rewrite of the thing this summer/fall to prepare for our next release but I know that the solution that I chose (link li
[docbook-apps] UI strings vs manual strings ?
What's the best way in a DocBook centered process to ensure that the list of terms used in a software UI is (semi-automatically?) taken into account in the DocBook sources that describe that software? Problem at hand: - a Java application with ~2k UI strings (not all users facing), in a Bundle.properties file - a ~80K words DocBook manual It is not trivial to keep track of the whole string set (searches, etc.) Also, the l10n process takes place on the DocBook sources, not on the HTML output, so tricks like don't work because translators don't see the target terms. I'm left with having to rewrite the strings explicitly and that's a pain, and also adds risks of mistakes in translations. -- Jean-Christophe Helary @jchel...@emacs.ch https://traductaire-libre.org https://mac4translators.blogspot.com https://sr.ht/~brandelune/omegat-as-a-book/ - 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] Multiplatform toolchain for outputting "nice" PDF
For some historical reasons (and maybe others, I don't know), the tool chain
used in the project where I'm in charge of the manual uses a very outdated tool
chain based on the following elements:
• DocBook XSL Stylesheets 1.75.2 ("dbk") or above
• DocBook XML 4.5 ("docbook-xml-4.5")
• fop 1.1 ("fop-1.1")
• libxml2 2-2.7.7 ("libxml2-2.7.7")
• Saxon 6-5-5 ("saxon")
• XMLmind Web Help Compiler ("whc")
• Ant 1.7.1 or above ("apache-ant")
I'm still investigating the reasons why we're stuck 15 years in the past, but
I'd like to move on.
Currently, the PDF that's built from our DocBook set is, not visually pleasant,
to say the least.
There are few contributors to the documentation but ideally I'd like something
that works equally well on the three major platforms that are Linux / Windows
and macOS.
A friend of mine who also is a DITA specialist converted the set to DITA and
semi-automatically produced a really nice PDF and there are no reasons why we
would not be able to have something equally nice with a modern DocBook
toolchain.
So the question is, what are the options?
Thank you in advance for your help.
--
Jean-Christophe Helary @brandelune
https://traductaire-libre.org
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/
-
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] translated indexes
On 27 sept. 10, at 23:21, Rowland, Larry wrote: We use an XSLT script to add the sortas attribute to the documents before we turn it over to the Japanese localizers, since some of the translation memory tools they use do not allow them to modify the structure of the document (and the attributes attached to an element is considered part of the structure by the tools). Thank you Rowland, Indeed the document I am talking about is going to be handled in a translation memory tool (OmegaT) so the translators will not have access to the underlying code and we don't want them to have access since most of them are translators and not XML specialists. Would you minds giving me an idea of how your XSLT works so that I can see how that could apply to us ? I am going to be in charge of the l10n for that document (which is in fact the OmegaT user manual that we just converted from HTML to Docbook) and I am not yet used to that whole new environment. Jean-Christophe Helary Regards, Larry -Original Message- From: Cramer, David W (David) [mailto:dcra...@motive.com] Sent: Saturday, September 25, 2010 9:48 AM To: Jean-Christophe Helary; DocBook Apps Subject: RE: [docbook-apps] translated indexes Correct. When the translators translate your document, instruct them to add sortas attributes with the term transliterated in hiragana/katakana. This applies to your glossentrys as well. David -Original Message- From: Jean-Christophe Helary [mailto:jean.christophe.hel...@gmail.com] Sent: Saturday, September 25, 2010 10:02 AM To: DocBook Apps Subject: Re: [docbook-apps] translated indexes On 25 sept. 10, at 12:49, Cramer, David W (David) wrote: Typically you just translate the indexterms in place in the document and let the xslts generate a new index. For Japanese, you add sortas attributes to your primary, secondary, and tertiary elements with the term transliterated into a phonetic script (katakana or hiragana). Ok, so you need to add that code to the Japanese DocBook file, right ? Jean-Christophe Helary fun: http://mac4translators.blogspot.com work: http://www.doublet.jp (ja/en fr) tweets: http://twitter.com/brandelune - 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] translated indexes
On 25 sept. 10, at 12:49, Cramer, David W (David) wrote: Typically you just translate the indexterms in place in the document and let the xslts generate a new index. For Japanese, you add sortas attributes to your primary, secondary, and tertiary elements with the term transliterated into a phonetic script (katakana or hiragana). Ok, so you need to add that code to the Japanese DocBook file, right ? Jean-Christophe Helary fun: http://mac4translators.blogspot.com work: http://www.doublet.jp (ja/en fr) tweets: http://twitter.com/brandelune - 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] translated indexes
I never tried that but I was wondering what was the best way to sort an index after translation of the file set ? Especially in the case of languages that do not use the same character set (for ex English vs Japanese) ? What would be the best way to establish an easy to translate index ? Jean-Christophe Helary fun: http://mac4translators.blogspot.com work: http://www.doublet.jp (ja/en fr) tweets: http://twitter.com/brandelune - 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] JavaHelp index
On 23 août 10, at 02:30, Mauritz Jeanson wrote: By the way, my impression is that interest in JavaHelp is waning. Nothing much seems to happen with the technology and discussion forum activity is low. But perhaps you have another opinion? Is there any other way to simply create a help system for Java applications ? Jean-Christophe Helary fun: http://mac4translators.blogspot.com work: http://www.doublet.jp (ja/en fr) tweets: http://twitter.com/brandelune - 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] JavaHelp index
On 23 août 10, at 07:10, Robert Lucente wrote: Why not just use JavaDoc ? What is the value add to use JavaHelp ? Because JavaDoc is: a tool that parses the declarations and documentation comments in a set of source files and produces a set of HTML pages describing the classes, interfaces, constructors, methods, and fields. http://download.oracle.com/javase/1.5.0/docs/guide/javadoc/index.html While JavaHelp can be use to integrate a user manual in the application, or I missed something on the way :) Jean-Christophe Helary fun: http://mac4translators.blogspot.com work: http://www.doublet.jp (ja/en fr) tweets: http://twitter.com/brandelune - 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] simplified docbook ?
What is the current status of Simplified DocBook ? Jean-Christophe Helary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] simplified docbook ?
On Aug 16, 2007, at 11:42 AM, Scott Hudson wrote: Hi Jean, the current official release is 1.1. There is also a 1.2CR1, based on DocBook 4.5, but we have not taken it further. I would anticipate providing a newer version based on DocBook v5.0, once it is officially released. Thank you Scott. I saw that info on the page but I asked since nothing new seemed to be happening on that front. So, we'd have a new CR based on DB 5.0 in the near future ? How compatible would that one be with the 1.1 version ? And would the 1.2 version still be released in the end ? JC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] simplified docbook ?
On Aug 16, 2007, at 12:12 PM, Scott Hudson wrote: Hi JC, I can certainly bring this up at the next TC meeting. Thank you very much for doing so. Norm has created some DocBook NG versions of Simplified in the past (see http://docbook.org/docbook-ng/simple/), so it should be fairly straightforward to create the next version based on the official DocBook v5. The transition guide (http://www.docbook.org/docs/howto/) should apply for Simplified docs, too. I would imagine that the 1.2 release would be based on NG (5.0) rather than 4.5 at this point. Thank you very much for the information. I'll check 1.2CR then. Regards, Jean-Christophe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
