Entity localization

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

ENTITY

From the beginning about what “entities” are, without delving into DTD. Entities are unique constants in an XML document, described using 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:



Or a more complete description for XSLT:

  
]>

* This source code was highlighted with Source Code Highlighter.

Entities in the XML table are substituted as follows: & entity -name ;
As an example, I’ll give a description of the well-known entity nbsp (inextricable space): You can



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

If everything is for (X) HTML Since special characters are described by default, only three entities are defined for XST: amp (& amp;), lt (& lt;) and gt (& gt;). If you want to use nbsp, you will either have to 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:



  
]>


  

  
    &labelHello;
  



* 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 entities in all templates, which means that there is little sense in such localization. Now suppose that our site is small, and all language constants can be collected in one place. Let this place be the lang.dtd file, where only “language” entities are described. Here is an example of such a DTD file:







* This source code was highlighted with Source Code Highlighter.

Now the small thing is to include this file in the XSLT template:



* This source code was highlighted with Source Code Highlighter.

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

CMS Localization

Suppose that we have a CMS where all the language files are represented as arrays or are generally located in the database. 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 slightly different one - to generate DTDs on the fly. This provides two advantages: firstly, there is no longer a need to update language DTD files when making changes to localization; secondly, we can easily change the localization, giving the language entities of the language that is installed by CMS.

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



* This source code was highlighted with Source Code Highlighter.

Here a problem arises that, it would seem, cannot be solved in any way - binding to a domain. But if our CMS is written in PHP (I don’t answer for other languages), then it is too early to despair :)

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

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



* This source code was highlighted with Source Code Highlighter.