I know this totally isn't the answer you were looking for, but I wanted to make a quick comment... I think that rather than creating a custom datatype it would be a lot easier and possibly more efficient to just utilize another column or table in your DB to represent the different languages... For example:
LanguageID (FK from LanguageTable)
..the primary key in WordTable would be a combination of WordID and LanguageID.... Here is an example of what might be in the tables:
1 | English
2 | French
3 | Italian
1 | 1 | Horse
1 | 2 | Le Cheval
1 | 3 | Il Cavallo
2 | 1 | Mouse
2 | 2 | Le Souris
....etc. (I have to stop there because I don't know the italian for mouse lol)
An advantage of achieving your goal this way (or a similar way, depending on your application) would give you the added benefit of Indexes and ability to search and use relationships, which is really what the DB is best at...
Not sure if you are hardcore about making your new datatype, but I wanted to post this as an alternative. If you do find a solution, please be sure and let us all know!
Thanks for your comments. I actually did consider an idea similar to yours, however, since I will have several entities (i.e. tables) all of which require fields with multi-lingual text, it would at least double my database schema in size and incur several extra relationships complicating matters further.
So far I have managed to set up a new data type in JAWS that mapps a new String type (LongString) to a TEXT type in mySQL. The problem is now to override the serialization methods so they don't store all the class signatures etc apart from the data! I'm posting a new question on the matter: "Persistence of Custom Data Types".