Home Forums General XMetaL Discussion Using xml:lang Values to Control Spell Checking Reply To: Using xml:lang Values to Control Spell Checking

Derek Read

Reply to: Using xml:lang Values to Control Spell Checking

The information I originally posted in this message is not accurate for XMAX.

I'm checking with our dev team to see what can be offered for your situation, but the behaviour you are seeing is expected primarily because this configuration is done with INI settings (for XMetaL Author) but XMAX does not have an INI file.

Some APIs have been added to recent releases of XMAX to allow you to configure it to support some features that are set using INI values in XMetaL Author, but these do not cover the spell checking INI settings.

Essentially, the reason you are seeing the behaviour in XMAX is due to the fact that internally Writing Tools was created to support made-up language codes that mostly do not match standard xml:lang codes (Writing Tools predates xml:lang by a decade or so). When XMetaL Author communicates with Writing Tools it uses these odd codes, but the solution for exposing the correct codes to the outside (via xml:lang) requires correct values to be set in the INI file.

The codes that Writing Tools supports internally do not include “en-ca”. The made-up codes include “CE” (presumably for Canadian English) and “en-oz” (Australian English). These are adjusted in the default XMetaL Author INI file to “en-ca” and . “fr-ca” is also not there and instead Writing Tools recognizes “CF” (not “fr-cf” just “CF”). Again, this is adjusted in the INI file for XMetaL Author.

What they probably should have done was to hard code more standard xml:lang values into XMetaL Author itself as defaults (which would then be inherited by the XMAX code). The INI settings would still allow people to set their own values if desired but then at least the defaults would be normal xml:lang values.

At this point I'm not sure what we're going to do, but I suspect we should do some cleanup in addition to adding specific support for this to XMAX (if still required after this cleanup).

Workaround (?)

I can think of a fairly elaborate workaround that might work now, but I'm not sure if you want to go to these lengths (this is a pretty hacky workaround). It would be possible to add xml:lang to your document's DTD without modifying the actual DTD using the event On_DTD_Open_Complete. The method is addAttribute() and depending on how you want to do it you might even add the xml:lang as a fixed attribute with a set value, probably to the root element (assuming your docs contain one language). If the value was set to “CE” or “CF” I think that might work. Setting it to be a “fixed” attribute should mean that you do not need to change the markup. If it were set to “implied” then you'd need to change the actual XML markup (then probably undo that before saving so that the document remains valid for the rest of your XML software chain).

Reply

Products
Downloads
Support