They're looked for based on the mahra:field attribute. We're not looking
at mahara:artefacttype here at all, which maybe we should be if
mahara:field isn't present, but I don't think it'll matter too much.

Currently imports date of birth and gender.

Use this hook instead of hard coding a call to the Internal plugin's
import_author_data method.

This allows the resume to also hook in and grab the personalinformation
fields out.

Currently imports goals, skills and cover letter/interests - aka the
"easy" fields.

I don't think it's that portable from other systems yet, but then I'm
not sure whether those systems have such fields either.

Now on to the more difficult fields - personal information, then
histories/awards etc.

Seems to be a reasonably good fit with the LEAP2A spec.

They're the wrong way around. I can't work out how exactly this was
working before, but switching them around to what they should be can't
be a bad thing.

Why exactly is this trying to catch an exception anyway??

JS popup position now a bit off - fix to come (probably in theme)

Conflicts:

This is documented at
http://wiki.mahara.org/Developer_Area/Import//Export/LEAP_Extensions#ownerformat

This is legal, I'd previously thought otherwise.

Smilies are now in a different directory. Also, TinyMCE seems to be
putting some attributes before the src tag, so match for that too.

We can't reliably convert them to exact RFC3339 dates, so we don't try
and risk breaking it.

Mahara import can import them straight back in.

Revert "Export resume dates in <content>, and in a custom element so Mahara <-> Mahara transfers will be able to work 100%."

After discussion with Simon Grant, and the resulting clarification to
the spec, we can export our text dates as labels for leap:date elements.

http://wiki.cetis.ac.uk/2009-03/LEAP2A_literals#Clarification_2009-07-14

This reverts commit 376f3a90.