Many months ago, I worked on a MYSTlore feature called Palapeli. Why the name? Well, I needed an obscure word as a codename because generic terms are boring, and it appears palapeli is the suomi (Finnish) word for jigsaw puzzles. And, jigsaw puzzles is what the feature was to be about. You take an image from MYSTlore’s database (it has plenty) either at random, or chosen from a category (say, only images from Riven), or picked in particular, and then have the server generate puzzle tiles for you.

But, alas, my skills weren’t quite up to it, at least not within reasonable time constraints. Splitting an image into a grid of tiles isn’t hard; doing so with “interlocking and tessellating”, as Wikipedia calls it, makes for much more of a challenge (to me, anyway). Delivering the tiles to the client isn’t hard; implementing drag and drop and verifying that the pieces really are meant to fit together is another matter.

So I dropped the thing for a while and put my respective OmniFocus¹ project on hold, but never really gave up.

Today, I made significant progress – but not with my own project. Rather, I found a decent pre-existing jigsaw puzzle implementation that, like Palapeli, uses JavaScript on the client end, and PHP server-side. Its demo page convinced me that this was more than good enough for a start.

This isn’t quite as sophisticated (yet) as Palapeli would have been. For example, as you can see from my project screenshot, I was going to have randomized tile sizes (for higher skill levels). What’s also lacking is a means of fetching the images straight from MYSTlore using either the MediaWiki API or a custom way of accessing the images (possibly directly by their file names; they’re not stored in the database).

But for now, I’m sufficiently pleased with it to launch it like this. So go ahead and fool around with it. Here’s the docs, here’s the puzzle (refresh to get a different image), and here’s the variant you perhaps didn’t want to see.

1. Yes, I’m one of the lucky alpha testers. ↩

Language is a wonderful means of abstraction. Our thoughts, our sentiments, our hopes and desires get expressed in a simple yet expressive, comprehensible yet diverse, colorful manner. Truly, language is a powerful tool.

But what if a language lacks the vocabulary that allows us to state what we have on our minds? What if it doesn’t have the flexibility to make our messages concise?

I do not consider Restored D’ni an adequate choice for everyday smalltalk. Nor do I even believe it possible to write so much as a simple three-paragraph encyclopedic article about, say, wet t-shirt contests. That, and that alone, is the thought behind Modern D’ni: make it practical for regular use.

The intent is not to crush RAWA’s tremendous, commendable work. It isn’t to dishonor that of the Guild of Linguists (back in the day), the D’ni Linguistic Fellowship (nowadays) and other groups and sites either. At no point does Modern D’ni clash with Classical and Restored D’ni. Everyone gets to choose what dialect they speak. Did British English become less usable because Americans sometimes say “jail”, not “prison”? Did American English because Australians sometimes say “dunny”, not “toilet”?

The result won’t be quite the same way the D’ni used to speak over two centuries ago. It will, however, be a way we can speak, today. That’s worth something. It attracts new people to D’ni as a language. It allows for D’ni to be actually used in general conversation: in forums, blogs, and, of course, in Uru Live.

How’s that for a plot twist for Cyan to deal with, after all: when Yeesha first speaks in Uru, she mumbles a few words, then realizes you “wouldn’t understand” because she was speaking D’ni. What if you were speaking it, only a different dialect, so she won’t understand all of it?

Don’t misunderstand any of this as an effort to undermine what’s already there. The opposite is the case. I want to put more emphasis on the D’ni language. Both in researching historical usage, as well as gathering how it can be implemented today.

I garnered more interest with my Modern D’ni proposal than I thought I would. It’s been discussed over at the D’ni Linguistic Fellowship with, again, more enthusiasm than I had expected.

Now comes the hard part of actually going through with it.

To the slightly obsessed member of the Myst Universe fandom, the idea of an encyclopedia written not just about a fictional language (in particular, D’ni), but in it, must be quite mouth-watering. An equivalent does exist for Star Trek fans: Wikipedia in Klingon (and you thought you’ve seen it all! ).

But the big hindrance making the concept hard to actualize is not lack of interest. The Guild of Linguists existed many years ago as a group of enthusiasts working on dictionaries, and even going so far as to develop their own transliteration system, who have been particularly focused on making the language’s intricacies easier to comprehend. Today, we have the D’ni Linguistic Fellowship. They may not be able to compete against the Klingon Language Institute, but again, that’s not the hold-up.

There has only been a single true original source of anything related to the language, and that would be RAWA. Cyan obviously can’t afford to employ him full-time just to work on the language, much less have multiple people work on it. In contrast, Klingon was developed by Marc Okrand, a linguist specifically hired for this task and with, unsurprisingly, plenty of experience in other real and artificial languages.

When Myst Fans need an unknown word translated or have questions on details such as the notation of simple arithmetic expressions in D’ni numerals, they can sometimes literally wait for years for an answer, or even entirely in vain. When answers do come, they’re either directly from Richard (traditionally on The Lyst, but lately also on other places, such as the DRC Forums), or integrated somehow into a game or novel. Riven, for example, provided many little pieces of information on matters such as basic numerals, timekeeping, etc. But Cyan doesn’t release new products that often, and hasn’t used Uru Live much at all either as an opportunity to expand the language (and related things) – presumably due to the good ol’ lack of resources. And RAWA, also for obvious reasons, doesn’t have much time these days to step up himself. Time spent communicating with language enthusiasts could be time economically better spent improving the state of Cyan and its core product, or even just communicating with actual customers with actual problems and concerns.

If all of the above was self-evident (but still interesting) to you, the following may not be: how about a dialect?

Think about it. We have modern guilds heavily inspired from the D’ni system, yet careful not to imitate it too much, both to avoid repeating its mistakes as well as to give its substitute a new, present-day spin. We have an ongoing restoration process in general. We have, thanks to Yeesha and/or the Bahro, linking books that go far beyond what the D’ni thought possible or safe. We have frequent discussions over whether we should choose plan A or plan B, or whether the cavern is doomed anyway and should be abandoned ASAP. Heck, we have Modern Greek. Why, then, not create a Modern D’ni branch? Is that really so terribly far-fetched? Is there any reason at all why, of all things, the language must be preserved to be as exact as possible, when everything else isn’t?

The basic structure and vocabulary can stay the same. But as for the advanced things we don’t know? Let’s come up with them ourselves! We have a huge community that is more than capable, and yes, we already have had an occasion where explorers proposed a new word. A compound of existing ones, mind you, but still: Vahkhro.

Anyone?

I wrote about CategorySuggest a couple of weeks ago, but wasn’t able to try it then since MYSTlore’s MediaWiki was still on the 1.8 branch, whereas this extension requires at least 1.10.

Another feature was requested that would have required a newer MediaWiki though, so I took the plunge and fortunately didn’t run into too many issues. Thus, CategorySuggest is now running on MYSTlore; kudos for Andreas for writing it.

However, I wasn’t happy with all of it. Here’s a few things I have changed. Obviously, most of them are subjective, and you may well prefer the original variant, or something different altogether.

First, MYSTlore’s charset is UTF-8 – as is, for instance, Wikipedia’s, so chances are your MediaWiki installation might use that as well. However, the suggestions are currently sent with no charset specified at all, and most browsers therefore assume it to be ISO 8859-1, or something different. This works fine in most cases, but obviously breaks with category names that aren’t so simple (in our case, “Untìl Uru shards”; note the deceptively near-invisible accent grave over the i in “Untìl”). So our first change is thus:

--- CategorySuggest_/CategorySuggestSuggest.php 2007-09-27 11:58:42.000000000 +0200
+++ CategorySuggestSuggest.php  2007-10-21 17:01:34.000000000 +0200
@@ -7,6 +7,8 @@
  *
 */

+header('Content-Type: text/html; charset=utf-8');
+
 //CONFIGURE WITH YOUR LOCAL CREDENTIALS
 mysql_connect("localhost", "USERNAME", "PASSWORD");
 mysql_select_db("DBNAME");

Second, I changed i18n/CategorySuggest.i18n.php to be a little friendlier, and provide a link to a project article on categories, like so:

--- CategorySuggest_/i18n/CategorySuggest.i18n.php	2007-09-27 11:27:42.000000000 +0200
+++ CategorySuggest/i18n/CategorySuggest.i18n.php	2007-10-21 15:34:08.000000000 +0200
@@ -9,8 +9,8 @@
  *
 */

-$messages['categorysuggest-title']	= 'CATEGORY ASSIGNMENT';
-$messages['categorysuggest-subtitle']	= 'Please enter the name of a category for this article.';
+$messages['categorysuggest-title']	= 'Assign Categories';
+$messages['categorysuggest-subtitle']	= 'Enter names of categories for this article; cf. MYSTlore:Categories.';
 $messages['categorysuggest-boxlabel']	= 'Categories:';
 $messages['categorysuggest-taglabel']	= 'Popular Categories:';
 ?>

Naturally, linking to MYSTlore: won’t do you any good, and the /wiki/ piece of the URL might not work in your case either. (However, I believe you can use the Project: namespace and have it automatically point to your project name.)

Thirdly, for those among us who care about semantic HTML, the markup output can be improved significantly. As a bonus, it’s actually also more readable and – in my very humble opinion – prettier.

--- CategorySuggest_/CategorySuggestFunctions.php	2007-09-27 11:30:32.000000000 +0200
+++ CategorySuggest/CategorySuggestFunctions.php	2007-10-21 15:39:28.000000000 +0200
@@ -50,13 +50,13 @@
 	$arrExistingCats = $m_pageCats;

 	#ADD INPUT BOX FOR USERS TO ENTER CATEGORIES
-	$m_pageObj->$m_place .= "<div id='categoryselectmaster'\"><b>" .wfMsg( 'categorysuggest-title' )."</b><br>\n";
-	$m_pageObj->$m_place .= wfMsg( 'categorysuggest-subtitle' ). "<br>\n" .wfMsg( 'categorysuggest-boxlabel' );
+	$m_pageObj->$m_place .= "<fieldset><legend>" .wfMsg( 'categorysuggest-title' )."</legend>\n";
+	$m_pageObj->$m_place .= "<p>".wfMsg( 'categorysuggest-subtitle' ). "</p>\n<label for='txtSelectedCategories'>" .wfMsg( 'categorysuggest-boxlabel' )."</label>";
 	$m_pageObj->$m_place .= "<input onkeyup='sendRequest(this.value);' autocomplete='off' type='text' name='txtSelectedCategories' id='txtSelectedCategories' maxlength='200' size='105' value='".str_replace("_"," ",implode(";", $arrExistingCats))."'/>\n";
-	$m_pageObj->$m_place .=  '<br><div id="searchResults"></div>';
+	$m_pageObj->$m_place .=  '<div id="searchResults"></div>';

 	//End DIV
-	$m_pageObj->$m_place .= "<br></div><br>\n"; //category select master
+	$m_pageObj->$m_place .= "</fieldset>\n"; //category select master

 	return true;
 }

brs are removed entirely, and we use fieldset, legend, label and p instead of the far more generic div and b. We leave the div where something more suitable probably doesn’t exist.

Finally, I’ve tweaked the CategorySuggest.css file a lot. Among the changes is an addition of the box-shadow (currently WebKit-only) and border-radius (currently Gecko- and WebKit-only) properties:

-webkit-box-shadow: 0 2px 3px black;
box-shadow: 0 2px 3px black;

-moz-border-radius-bottomleft: 4px;
-webkit-border-bottom-left-radius: 4px;
-khtml-border-bottom-left-radius: 4px;
border-bottom-left-radius: 4px;
-moz-border-radius-bottomright: 4px;
-webkit-border-bottom-right-radius: 4px;
-khtml-border-bottom-right-radius: 4px;
border-bottom-right-radius: 4px;

I’ve also made a lot of changes to the chosen colors and all, but nothing too unusual or surprising. The result still isn’t going to win any beauty contest, but I’m very happy with it for now.