Page 1 of 1
Translated note label variables - where?
Posted: Mon Dec 12, 2016 3:48 pm
by kris
Hi,
I learned here in another topic, that variables to customize the note labels and images are defined in the 'DITA-OT2.x/plugins/org.dita.pdf2/cfg/common/vars/en.xml'.
I found that for translations of the note labels, DITA-OT uses the files like strings-fr-fr.xml under 'DITA-OT2.x/xsl/common'.
However, the same variables are defined in the language files of 'DITA-OT2.x/plugins/org.dita.pdf2/cfg/common/vars'.
Can you please explain which variable is used in which situations?
Thanks,
Kris
Re: Translated note label variables - where?
Posted: Tue Dec 13, 2016 12:25 pm
by Radu
Hi Kris,
With DITA OT 1.8 and older, the HTML-based outputs used default translations from the
DITA-OT/xsl/common folder while the PDF output used translations from the
DITA-OT/plugins/org.dita.pdf2/cfg/common/vars/ folder. So the translation mechanisms for HTML-based and PDF were fully separated.
For DITA OT 2.x somehow the PDF publishing also looks for translations in the common translations, although it still preserves some separate translations.
This recent DITA OT 2.x documentation topic explains how to build a plugin which adds new keys or modifies values for older keys, plugin which as far as I remember should work for both HTML-based and PDF:
http://www.dita-ot.org/dev/dev_ref/plug ... dtext.html
Regards,
Radu
Re: Translated note label variables - where?
Posted: Thu Mar 02, 2017 2:32 pm
by kris
Hi Radu,
I followed the article but bumped into a doubt. At some point it says to use getString.
If I check the definition of getString in the dita-utilities.xsl file, it says:
<!-- Deprecated. Use getVariable template instead. -->
What is the best practice?
As much as I can see, the original code still uses getString for all common text resources, like note labels in the xsl\common\ folder...
Thanks,
Kris
Re: Translated note label variables - where?
Posted: Thu Mar 02, 2017 2:47 pm
by Radu
Hi Kris,
In DITA OT 2.x the "getString" was deprecated (but it still works) in favor of "getVariable".
All the XSLT code in the DITA OT 2.x common XSLT code or plugins should use "getVariable".
Do you know of any specific XSLT stylesheet which still uses "getString" and is bundled with DITA OT 2.x?
Regards,
Radu
Re: Translated note label variables - where?
Posted: Fri Mar 03, 2017 1:13 pm
by kris
Well, I was hoping you will tell me

I just noticed that in my environment, the note labels are strings in the
string-[lang]-[loc].xml files under the
DITA-OT2.0.1\xsl\common. I guess, DITA-OT fetches these strings with some getString, but that's just an assumption

Please, let me know how DITA-OT grabs those.
Re: Translated note label variables - where?
Posted: Fri Mar 03, 2017 4:00 pm
by Radu
Hi,
So if we are talking about DITA <note> processing for the XHTML-based outputs, the XSLT stylesheet:
OXYGEN_INSTALL_DIR/frameworks/dita/DITA-OT2.x/plugins/org.dita.xhtml/xsl/xslhtml/dita2htmlImpl.xsl
does something like this:
Code: Select all
<xsl:template match="*" mode="process.note.common-processing">
<xsl:param name="type" select="@type"/>
<xsl:param name="title">
<xsl:call-template name="getVariable">
<!-- For the parameter, turn "note" into "Note", caution => Caution, etc -->
<xsl:with-param name="id"
select="concat(upper-case(substring($type, 1, 1)),
substring($type, 2))"/>
</xsl:call-template>
</xsl:param>
.........
and indeed the
Note key is translated for example in
strings-en-us.xml
Regards,
Radu
Re: Translated note label variables - where?
Posted: Fri Mar 03, 2017 4:41 pm
by kris
My plugin generates PDF. Does the same apply?
Re: Translated note label variables - where?
Posted: Mon Mar 06, 2017 4:52 pm
by Radu
Hi,
So for the PDF based output this XSLT stylesheet:
OXYGEN_INSTALL_DIR\frameworks\dita\DITA ... ommons.xsl
has a template:
Code: Select all
<xsl:template match="*" mode="placeNoteContent">
............
which calls
getVariable with various params depending on the note @type attribute.
And the same translation files from
OXYGEN_INSTALLATION_DIR/frameworks/dita/DITA-OT/xsl/common/ should be used.
Regards,
Radu