The short version of my previous XUL post is that our framework attempts to convert entity references into translated strings by trying three different approaches until one succeeds:

1. A fast and accurate method, provided the developer has added a <tfs_string> element
2. A slow but accurate method, provided the developer has put a default translation into the database
3. A fast but potentially inaccurate translation

Obviously we want all our strings to be translated via method (1) if at all possible. Because of this, if we have to fall back to method (2) we also send a warning to the Firebug console so that the developer will (hopefully) be prompted to add the necessary elements for method (1) to work.

We really don’t want to end up using method (3). It’s there so that the application doesn’t just stop working altogether, but it doesn’t allow the end user to translate the text, and the use of simple heuristics means that the auto-translated version could be misleading or completely incorrect. Any uses of this method are therefore also reported with a warning in the Firebug console.

Now warnings are all well and good, but it’s possible to get into a situation where dozens of these warnings fly up the console for each and every field on the screen – hundreds of lines of warnings which the hapless developer is supposed to sort through and convert into <tfs_string> elements, database entries, or both. Without creating duplicates.

To simplify this task the code for methods (2) and (3) does something else. As well as printing a warning, it also adds a string to a global associative array. In the case of method (3) it adds an appropriate SQL INSERT statement. For method (2) it adds a suitable fragment of XUL – a list of pre-populated <tfs_string> elements. The developer can then access that array to get a list of SQL statements to run in the database tool of their choice, or a list of XUL elements to copy and paste into the code.

Why use associative arrays for this? Well, it prevents the “duplicates” issue. The key in the array is simply the entity reference used in the code – so if the same entity reference is used more than once, they all refer to the same key in the array rather than resulting in duplicate entries.

In practice these convenience tools result in a development cycle something like this:

1. Developer creates an app, pointing some of the fields at database columns which have no suitable translations
2. The Firebug console gets filled with method (3) warnings
3. The developer calls a function, via the Firebug console, which outputs the contents of the SQL array to the console
4. The developer copies the SQL, pastes it into a database tool, edits and runs it
5. The developer deletes the DTD files so that they are re-generated at the next page load
6. The developer runs the application, and the Firebug console gets filled with method (2) warnings
7. The developer calls a function, via the Firebug console, which outputs the contents of the XUL array to the console
8. The XUL is copied from the console and pasted into the code
9. The developer runs the application, and no warnings appear in the Firebug console because only the fast-and-accurate method (1) translation code is being used

Now this may seem like a long-winded way to deal with this problem, but believe me it’s a lot faster than trying to construct the appropriate SQL and XUL by hand. Besides which, it’s not compulsory – the application will continue to run even without the additional SQL or XUL. But taking these steps does improve the speed and translatability (!) of the application.