An end of year update on where version 2.6.5 is up to

This is my final update of the year.  I hope you all have a bountiful Xmas and eat so much that your relatives have to call the fire department to extract you from your chair in front of the T.V.  Just kidding that would be awful, but I hope you all have a great Xmas and a Happy New Year.

Now onto the point of this post.  My last post, back at the start of November suggested that Santa may be bringing the 2.6.5 update in his bag of goodies.  Alas Santa got waylaid by some disgruntled Elves wielding sharpened candy canes and demanding better pay and conditions and thus won’t be able to make the delivery as planned.

Development of 2.6.5 hasn’t stopped, far from it, I just realized that I needed to create an editor to provide support for those creating the set of User Interface strings for a new language.

My original plan was to give the creators a .xlsx (Office Spreadsheet) file with a couple of columns and an extra column for them to fill in with the new translated string.  But this is about as user friendly as the ill-fated iPotato that Apple originally planned to release before the vastly superior iPhone made its debut.  A glorified text file, which is what a .xlxs file is, is also woefully error-prone, so instead I decided to actually create a strings Editor that a user can use to create their translated strings.  A picture of what it currently looks like can be seen below:

ui-language-strings-editor

There are numerous advantages of this Editor over a .xlsx file, not least the fact that it has built-in support for tab completion of referenced ids.  Let me explain.  To facilitate re-use I’ve allowed for the use of previously defined variables in a string.

So I might have a string with an id (the value I actually use in the code to reference a translated string):

objectnames.singular.project = Project

In other words, in the QW code I use “objectnames.singular.project” to reference the value “Project”.  When the value of “objectnames.singular.project” changes to, say, “Potato” everywhere that “objectnames.singular.project” is used in other strings it will also magically change to Potato.

So, I might have another string with id:

project.new.title = Create a new ${objectnames.singular.project}

The ${…} construct just allows me to find the values in the string.  This value will come out as: “Create a new Project”.  If I change the value of “objectnames.singular.project” to “Potato”, the value will be “Create a new Potato”.

This kind of reuse makes sure that consistent terms are used throughout the interface.

To return to my previous point, the Editor supports the ability to provide suggestions for partially entered ids, if it detects:

${objectn

then it will offer “objectnames” as a potential value in a popup, the user then presses the “Tab” key to accept the value.  Press “Tab” again and all the “child” values under “objectnames” will be displayed.

For example objectnames has two “children” (things after the dot), “singular” and “plural”.

This set of dot separated values allow for reuse of terms and allows for grouping of functionality.  So a prefix of “project” means “things to do with a project”, “warmups” is for the “Warm-ups” and so on.

The Editor’s other main purpose is to allow easy submission of the strings back to the server where they are stored.  It also provides verification and error checking so by the time the strings reach the server they need little to no extra processing (although the server does do its own error checking).

Unfortunately, all this extra work has taken time however the infrastructure to make it all work is now essentially in place.  The main thing remaining is a way to handle updates for future QW versions.  That is I need to make the new or modified strings for a new version available to translation creators BEFORE the new version of QW is available to everyone else.  A tricky problem but not insurmountable.

All of this, of course, has put my estimate back somewhat.  The work is worth it, if a little tedious at times.  At the moment, I think a realistic estimate of when 2.6.5 will be ready for release is sometime in late February 2018.

Happy Xmas and a healthy New Year to all!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s