Writing MLP-Ready Plugins.

Localised strings

If you want to allow users to edit your plugins’ strings using the string editing features of the new MLP Pack then you need to take a few extra steps to get your plugins into shape for the task.

Don’t worry, this will not make your plugins dependent upon the MLP Pack being present in an installation in order for it to work—it will work just fine without the MLP Pack.

Here are the steps…

1. Have an internal array of named strings.
2. Register a callback routine.
3. Write your callback routine—copy the example routine from the code that follows changing details as needed. This will pass your array of strings to the MLP pack and register them as owned by your plugin.
4. Write, or modify the example, plugin-specific gTxt() function that…
   1. tries to get the string from the $textarray and if that fails,
   2. tries to get the string from it’s private array and if that fails,
   3. returns the name of the string you were trying to access.
   4. does any variale substitutions that are needed
5. Use the specific gTxt() function consistently throughout your pluign.

Here is an example you can use for study…

Gettng Localised Data

The MLP Pack creates tables with localised content in them from the master textpattern table. The pack then uses a table-name remapping on the public interface to serve language specific content to plugins through the DB layer.

This remapping is not done on the admin side.

Although a language-specific temporary textpattern table could have been created to hide the original textpattern table for each client connection this would put a continuous un-needed load on the server so the MLP pack maintains a set of copies of the textpattern table—one table per site language— and then relies on a simple function to remap any queries against the ‘textpattern’ table to the copy with content in that language.

If your plugin uses any of the safe_blah() functions (except safe_query) or the fetch() routine; then this will happen without your needing to do anything special.

However, if your plugin accesses the textpattern table via a call to safe_query() or any of the other routines in txplib_db.php then it will work, but will potentially retreive rows for languages that the site visitor is not using.

To get around this you can make a few simple adjustments…

a) use the built-in DB access functions found in textpattern/lib/txplib_db.php rather than going to the DB via PHP’s MySQL access routines.

b) Don’t use the PFX constant.
Huh? Yes, if your plugin is meant for TxP 4.0.4 or above then this is easy as you can simply switch all PFX prefixing over to the safe_pfx() or safe_pfx_j() routines. The MLP Pack currently uses these to do some crafty table name changing to give access to localised content.

For plugins that need to work in TxP versions prior to 4.0.4 and you use the PFX constant then you can use the following routine to prefix your tables (and redirect to localised tables if the MLP Pack is present)...

Now use this call whenever you need to construct the name of a table for a call to safe_query().

Or…

c) Try not to use the safe_query() routine but rather use the specific routines for the operations you are trying to perform (this is not possible for all queries)

For example, instead of doing…

safe_query( "select * from ".PFX."textpattern where `ID`='$my_id'" );

either use your prefix routine…

$table = sed_example_pfx( 'textpattern' ); safe_query( "select * from $table where `ID`='$my_id'" );

or use a more specfic access routine…

safe_row( '*', 'textpattern', "`ID`='$my_id'" );