Localization using entities

There are quite a few ways to localize XSLT templates, some methods are described by Lebedev’s studio, but today I’ll talk about localization using entities.

ENTITY

C started on what “entities” are, without delving into the DTD. Entities are peculiar constants in an XML document, described using a DTD, and used as abbreviations. An example of such a replacement is the lettering of characters that are not present on the standard keyboard layout (©, ®, ₤, etc.). Entities are described as follows:



<!ENTITY - "-">



Or a more complete description for XSLT:

<! DOCTYPE xsl:stylesheet [

<! ENTITY - "-" >

] >



* This source code was highlighted with Source Code Highlighter .

')

In the XML table, the entities are substituted as follows: & entity-name ;

As an example, I will give a description of the well-known nbsp entity (non-breaking space):



<!ENTITY nbsp "&amp;#160;">



You can look at many “standard” entities in the HTML DTD: www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent



If for (X) HTML all entities of special characters are described by default, then only three entities are defined for XST: amp (& amp;), lt (& amp; lt;), and gt (& amp; gt;). If you want to use nbsp, you will have to either use a ready-made table, with a description of special characters, or describe the entity yourself.

Localization (start)

Now let's try to make the simplest localization for the XSLT template using entities:

<? xml version ="1.0" encoding ="UTF-8" ? >



<! DOCTYPE xsl:stylesheet [

<! ENTITY labelHello ", !" >

] >



< xsl:stylesheet version ="1.0" xmlns:xsl ="http://www.w3.org/1999/XSL/Transform" >

< xsl:output encoding ="utf-8" method ="xml" />



< xsl:template match ="/" >

< xsl:text > &labelHello; </ xsl:text >

</ xsl:template >



</ xsl:stylesheet >



* This source code was highlighted with Source Code Highlighter .

The result, I think, is obvious. But in this example there is one big drawback: when changing the language, we need to replace all the entities in all the templates, which means there is little use from such localization. Now suppose that our site is small, and all language constants can be collected in one place. Let this place be the file lang.dtd, where only “language” entities are described. Here is an example of such a DTD file:

<? xml version ="1.0" encoding ="UTF-8" ? >



<! ENTITY labelHello ", !" >

<! ENTITY labelLogin "" >

<! ENTITY labelRegister "" >



* This source code was highlighted with Source Code Highlighter .

Now it’s easy to attach this file to an XSLT template:

<! DOCTYPE xsl:stylesheet SYSTEM "lang.dtd" >



* This source code was highlighted with Source Code Highlighter .

The last option is already quite working; to change the language, it is enough to replace only one file. But in some cases this is still not enough.

Localization at the CMS level

Suppose that we have a CMS, where all language files are represented as arrays or are in the database at all. The easiest way to link system localization and XSLT templates is to automatically generate DTD files with “language” entities. The option, of course, is not the worst, but there is a little different - to generate a DTD "on the fly." This has two advantages: firstly, there is no longer a need to update the language DTD files when changes are made to localization; secondly, we can easily change the localization, giving the language of the essence of the language that is installed CMS.



Suppose that we wrote a script that delivers content, as in the lang.dtd file, we include it in the XSLT template:

<! DOCTYPE xsl:stylesheet SYSTEM "http://localhost/lang.php" >



* This source code was highlighted with Source Code Highlighter .

This raises a problem that would seem to be solved in any way - binding to the domain. But if our CMS is written in PHP (I’m not responsible for other languages), then it’s too early to despair :)



In PHP, starting from version 4.3, you can implement your own protocols. For example, you can implement support for the file (file: //) protocol or any other. The developer is responsible for implementing custom protocols. I will not dwell on this in detail, because this is another topic. You can read about the implementation of your protocols in the PHP documentation here , and you can see the finished example in the SVN of my project here .



Now apply this in XSLT. We implement the protocol, for example, lang and correct the pattern:

<! DOCTYPE xsl:stylesheet SYSTEM "lang://modulename" >



* This source code was highlighted with Source Code Highlighter .