Hello,
I would transform the bundle.properties in a document (article, book or section
whatever)Each line of the file corresponds to somethine like :
<simpara><guilabel xml:id="messageId">My message</guilabel></simpara>
One element simpara for one guilabel is useless : it is just to make it
readable in a DocBook parse.
In the document, you include the message - something like :<para>You should see
<xi:include href="bundle.properties.xml" xpointer="messageId"> after clicking
on the button.</para>
The French, English, German version of the document will take advantage of the
corresponding translated version of bundle.properties.xml
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.
Regards,Florimond
Le mardi 6 décembre 2022 à 00:05:49 UTC+1, Jean-Christophe Helary
<[email protected]> a écrit :
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 <link linkend endterm/> 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 @[email protected]
https://traductaire-libre.org
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
