Bu dÚcha gum bi an tuath-gaoith as mÚ san t-saoghal air a stËidheachadh ann an LeÚdhas, air MÚinteach Bharbhais, an an ceann a tuath na h-eilein. Nise, bha mi ann an uiridh, air mo bh‡idhsagal agus chan eil c‡il ann ach fraoch agus gaoth! A dh’aindeon sin, ‘se ‡ite ‡lainn a th’ann, fiadhaich agus fosgailte dhan cheithir gaothan. ¿ite far an tËid aig a’mhac-mheannmain a bhith na sheachranaiche, a’saoilsinn air dË bhiodh e air a bhith coltach ri a bhith beÚ anns na l‡ithean anns nach robh feum aig duine cummhachd a thoirt bhon thalamh.
Ach tha sinn a’fuireach anns an aona linn fichead nise agus ag iarraidh fada fada cus dealain na th’anns an talamh fhËin agus sinn a’coimhead air a’ghaoith gar s‡bhaladh. An-dr‡sta co-dhi?. Tha an colbh Gh‡idhlig an t-seachdain-sa a’cumail a-mach gu bheil LËodhas a’p‡igheadh airson mearachdan muinntir na Staitean Aonichte agus tha an t-eilean a’dol a bhith na fhactory dÏreach airson cogais an t-saoghal. Uill, fhad ‘s a tha cumhachd bhon ghaoith san fhasan…

leugh an colbh an seo

Internationalisation (I18N), which, once built into an application, allows Localisation (L12N), so users can choose which language to use. Some applications are i18n enabled but come with mutually exclusive language packs, so the interfaces are only ever available in one language, although that language can be changed. They support i18n but dynamic i12n is not supported.

Having worked on many i18n efforts over the years, I’ve become used to dynamic language switching of the user interface, which gives you a great language learning tool too. For example, when I’m perusing a Gaelic localised interface, if I’m not sure of a term, I can quickly switch back to English to see what it is, then back to Gaelic. Great if your memory is as bad as mine So, this answered the question of whether to support dynamic language switching – yes!

So, what’s involved in i18n for bodington?

Modified classes

• org.bodington.servlet.BuildingServlet – modified to process requests from the language control panel, in the user preferences section
• org.bodington.servlet.template.Template – the Template class has been modified to pass language information from the upper layers down to the XmlTemplate processor
• org.bodington.server.realm.User – modified to hold the user’s language preference as well as store and retrieve it from the database, in the “users” table
• org.bodington.servlet.template.XmlTemplate – modified to process the and nodes in the new style templates as well as to modify the CDATA in system nodes now handles the localisation calls from the new localisation template that provides “Translate this location” functionality
• org.bodington.server.resources.Resource – this now has a localise() method that will accept translations from the “Translate this location” function and also a has a way of localising an org.bodington.text.BigString object
• org.bodington.database.PersistentObject – added a localise() method to this abstract class
• org.bodington.database.Database – added a localiseObject() method to this abstract class
• org.bodington.sqldatabase.SqlDatabase – added a localiseObject() method to create localised versions of the big_strings table in the database. If a translation for a Resource is received and the language specific table doesn’t exist, this will create it on the fly. e.g. If I translate a Resource to Gaelic, a big_strings_gd table is created to store all Gaelic strings for all Resources
• org.bodington.servlet.facilites.Facility – added a hook for the “localise” command from Resources and added confirmLocalise() to handle on the fly translation of Resources

New classes

• org.bodington.i18n.Localiser – provides the i18n engine and content cache

Modified SQL files for installer

• org.bodington.server.realm.User.sql – added the required SQL for adding a “language” field and for setLanguage() and getLanguage() methods

Modified templates

• style_default/default/useroptions.html – has a new form for changing a user’s language

New templates

• style_default/default/localise.html – provides “Translate this location” functionality
• style_default/default/confirmlocalise.html – provides “Translate this location” functionality
• style_default/default/manage.html – provides a “Translate this location” link

Database updates

There are a couple of database updates that are required if you’re not installing Bodington from scratch. The first adds a “language” field to the “users” table:
ALTER TABLE users ADD COLUMN language varchar(5)

while the other adds the getLanguage() and setLanguage() methods to the User object’s database presence. This is required for the User.save() method to function:
INSERT INTO fields (type, sequence, field, set_method_name, get_method_name, set_java_class, get_java_class, flags, foreign_type, set_method_name_foreign, get_method_name_foreign ) VALUES(1, 10, ‘language’, ‘setLanguage’, ‘getLanguage’, ‘java.lang.String’, ‘java.lang.String’, 0, null, null, null )

So now that the engine is in place, how do you localise a template?

Setting up a template for localisation

The template opens with <template facilityclass=”org.bodington.servlet.facilities.Facility”>. The next node under this root node MUST be:
<i18n resource-path=”lang” resource-file=”login.properties”/>
as this sets up the XmlTemplate compiler to insert dynamic calls to the Localiser engine, which will be available to the rest of the template.
The “resource-path” attribute tells the Localiser where this template’s resource files are located. If it’s an absolute path, as in:
“/WWW/clan/i18n/strings”
then it is used as is, whereas if it’s a relative path, as in:
“lang”
it is appended to the current directory of the template.
The user’s language setting is then appended to this path.
The “resource-path” attribute tells the Localiser the name of actual file containing the templates strings and content, e.g. “login.properties”
The Localiser then constructs the full resource file path thus:
resource-path/[USER_LANG]/resource-file.

Localising a template’s textual content

To localise a template, all you need do is decide where you’re keeping the resource file for that template, then extract the text and replace each instance with the node:
<localise id=”x” />
The “id” attribute tells the Localiser which ID to extract from the resource-file.
Let’s say we have a template and we want to localise the HTML <title> element:
<head><title>Test localisation template</title></head>
extract the text and put it in test_template.properties and replace with:
<head><title><localise id=”1″ /></title></head>
so the top part of the template looks like this:

<template facilityclass=”org.bodington.servlet.facilities.Facility”>
<i18n resource-path=”lang” resource-file=”test_template.properties”/>
<head><title><localise id=”1″ /></title></head>

and the resource file for the Gaelic version of the template, [TEMPLATE_DIR]/lang/gd/test_template.properties, looks like:
1=Test template title

bodington.properties additions

default_language=en
This sets the default language for the system to English. When retrofitting i18n to a Bodington installation, all users will not have a preferred language. Upon login, their language will be set to the default_language in their entry in the “users” table in the database.

language_debug=off
There are 3 settings for this:

• off = all text is displayed as the Localiser finds it, either from the resource files, cache or database
• on = all text is has the ID prepended to aid translators when localising templates or resources
• verbose = all text has it’s corresponding resource-path and resource-file prepended, or database table name if it’s for a resource

The debug level can be controlled dynamically from the System Administrator’s user preferences page. There is no need to stop/start Bodington.

The following properties are used by SqlDatabase.localiseObject:
sql_verify_localised_table=SELECT big_string_id from big_strings_LANGUAGECODE where big_string_id \= ‘__ID__’
sql_create_localised_table=CREATE TABLE big_strings_LANGUAGECODE (big_string_id int NOT NULL, string TEXT, CONSTRAINT PK_big_strings_LANGUAGECODE PRIMARY KEY (big_string_id), CONSTRAINT FK_big_string_to_objects FOREIGN KEY (big_string_id) REFERENCES objects (id))
sql_update_localised_string=UPDATE big_strings_LANGUAGECODE set string \= ‘__STRING__’ where big_string_id \= ‘__ID__’
sql_insert_localised_string=INSERT INTO big_strings_LANGUAGECODE (big_string_id, string) VALUES (‘__ID__’, ‘__STRING__’)

During development of CLAN, we were looking at various web server security companies, from which to source a CLAN secure certificate, as well as address the issue whereby SSL (and there HTTPS) requires a unique IP address for each virtual host.

Having sorted the virtual interfaces and obtained test certificates from various vendors, we decided to go with Thawte and have purchased a secure certificate for www.clan.uhi.ac.uk

This means users won’t be subjected to the browser warnings that appeared when logging in to CLAN, stating that the server’s certificate couldn’t be verified. Users will also notice the Thawte seal on the login page, which is there for all to be sure that CLAN passwords are now secure.

The Semantic Web, to me, has always been a bit of a wonky idea. Machines talking to machines, using machine language but there’s a debate whether they should use XML or RDF. XML is designed for human interpretation. Think not? Then why does it take account of whitespace? So, you come to XML thinking you can create XML using notepad and you can. Then you buy Java for dummies and try the same using the Java XML bindings and you die horribly in namespaces. The human readable part is a facade, behind which, the guts have been removed and replaced with a machine view of the world.

In Stephen Downe’s interpretation:
“…The Semantic Web (in capitals) is something hard-edged Java gurus write…And it is therefore (to the vast majority of people) useless.

Strong words indeed. I tend to agree, it is pretty useless to Joe Public and his community website. If FrontPage don’t do it, Joe Public ain’t gonna do it either. Stephen trumpets RSS as the saviour of the Semantic Web but the first commenter of his article admits to a ignorance of what RSS is! If the populace can’t come to terms with what’s on offer, then they just won’t use it.

The gospel according to Stephen is:

• if you can’t do it simply, with a simple text-editor, a web server and a standard browser, it’s broken
• if you can’t say what you want to say with it, it’s broken
• if you can’t link, it’s broken
• if you can’t find it, it doesn’t exist

Read Whither the Semantic Web

Auricle
Recent RSS developments in eLearning are pointing the way towards monolithic VLEs becoming rather large and vacuous white elephants:

“…RSS feeds, like MedWeb’s, can be incorporated into many different types of container, including mainstream virtual learning environments. While I believe this to be an enrichment of the otherwise closed world of the VLE, it does raise the spectre (for vendors) of such VLEs becoming devoid of their own learning objects and merely being relegated to the role of relatively expensive delivery vehicles or front-ends. In such a scenario it becomes a moot point whether it is cost-effective to support a proprietary VLE for this purpose at all…”

Here’s Scott Wilson’s view of the VLE of the future

Auricle article on WordPresMU
Seems other people are thinking the same thing. How to manage thousands of users and their blogs?

WordPress Multiuser
Interesting developments at WordPress…