I18n and L10n of Mudlet

[SlySven]

A topic that has come up for discussion recently is that of equipping Mudlet for more than just a EN-us language environment. There are powerful tools available to assist the developers in this but like anything that is powerful there are costs and risks involved in uses them, not least that of unintended side effects.

One tool is Qt's own translation system, which allows any piece of text that the user gets to see to be replaced with text in a different language when they run an application that has been both internationalised {a.k.a. "I18n"} ( = constructed to be used for different languages - hopefully a one time process, with any new code subsequently added being so added in a way that supports multiple languages) and then localised {a.k.a. "L10n"} ( = translated into the required language, in a process for each localisation). Neither step is necessarily trivial, parts of the user interface can be awkward to get right at the I18n stage for every target and every change in source text used there will require a corresponding update in each and every L10n.

A specific factor is the Lua system that is available to users to add their own functionality to the Mudlet application to customise it both to their own desires and to work more effectively with the particular MUDs that they wish to play. At this point in time a developer (well, myself!) is making provision to prepare to supply error messages that can be localised - which is not too complicated. However the Application Programming Interface (API) that Mudlet presents to the user/script writer is not so straightforward a matter. The simplest, and most robust approach will be NOT to try to support non-EN-us language so, for comparison with other possibilities, given a room ID number i the command to get the exit to the north and east of that room will be

Code: Select all

lua echo(getRoomExits(i)["northwest"].."\n")

and similarly to get all the normal exits for a specific room (123)

Code: Select all

lua display(getRoomExits(123))
{
  southeast = 78,
  west = 80,
  southwest = 77,
  northeast = 67,
  east = 70,
  north = 68,
  ["in"] = 120,
  northwest = 66,
  south = 76,
  up = 7521
}

A partial localisation attempt (which is what gets my vote ) would be a hybrid that keeps the names of the provided functions the same but changes the texts of strings used as arguments to, and as keys and possibly values in responses from, those functions:

Code: Select all

lua echo(getRoomExits(i)["noroeste"].."\n") {ES-es}

Code: Select all

lua echo(getRoomExits(i)["nord-ouest"].."\n") {FR-fr}

and

Code: Select all

lua display(getRoomExits(123))
{
  sudeste = 78,
  oeste = 80,
  sudoeste = 77,
  noreste = 67,
  este = 70,
  norte = 68,
  en = 120,
  noroeste = 66,
  sur = 76,
  subir = 7521
} {ES-es}

Code: Select all

lua display(getRoomExits(i))
{
  ["sud-est"] = 78,
  ouest = 80,
  ["sud-ouest"] = 77,
  ["nord-est"] = 67,
  est = 70,
  nord = 68,
  entrer = 120,
  ["nord-ouest"] = 66,
  sud = 76,
  dans = 7521
} {FR-fr}

The most involved case would translate the names of the functions as wel:

Code: Select all

lua reenviar(obtenerSaleHabitación(i)["noroeste"].."\n") {ES-es}

Code: Select all

lua répéter(obterSaeDoCuarto(i)["nord-ouest"].."\n") {FR-fr} etc.

The middle ground as it were would have the advantage if the right strings were used that some things such as speed walking might work without the user having to code their own translator for the directions that Mudlet puts out to the ones the non-EN-us MUD server they have connected to uses. However, there is no other way to put it , it would be downright ugly for a non-English speaker to use and would be harder for script-writers to work with if they wished to cover multiple languages than the first case - thought as a matter of course there would have to be a lua function to report the language setting that is in use so script writers could at least attempt to accommodate the different strings they will have to process! If such support is NOT written in then scripts, including existing work, could not work in anything other than the current EN-us locale. One way around this would be to provide two "translations" both of which would translate the User Interface (e.g. tool-tips, texts on dialogues etc.) but only one would translate the aspects of the Lua API as described here. That one would be used on Mudlet instances where ALL the scripts are written to support the translated API and the other where NONE are - unfortunately I do not think both could be supported this way within the same running instance of Mudlet. The other downside is obvious: twice as many translations to support and run through the Qt Linguist translation system and to distribute.

The "translate everything" would be the cleanest for non-English speakers but would need the most work of all - if it was done completely and properly (and the design of Mudlet was completely static) then to those users it would seem an Application that was completely native to them. However, the design is not yet static and to be honest I'm not sure it will ever be completely so. The extra work involved to maintain and test in multiple languages could be too much for the current team to achieve and require developers who can deal with both the English source and the languages that are chosen to be covered.

Another developer has proposed doing what translations are required in the Lua system itself, after all, it is can process information very quickly and I understand there is already a gettext implementation for Lua. There is certainly scope there but it is not yet something I can speak on - and it would only cover the Lua system - we'd still have to use the Qt system for the UI that the application presents. I suspect that the Qt system may well use gettext underneath anyway!

Anyhow this rather long post is just my thoughts on the subject. I'd be interested to hear what others think on this and hope they would point out any other relevant points that I've missed or errors in my assumptions...

[Zaphob]

I have run into these English strings in the mapper API before, and it is really a PITA if your MUD does not send English strings to compare with. An easy solution would be to add a way for scripts to overwrite the accepted strings. Translation tables seem more complicated. If you can already ship the strings for the most popular languages, would be even better. Then a script developer would only once have to specify: This MUD will send info in language X, and be done with it.

I would however vote against translating function names, etc. These things are to be kept precice and clear, and are only used internally / for developing new scripts. No regular user or MUD programmer comes into contact there. Also, think about the process of constantly updating and improving translations. You do not want to change function names every few months and complete break the old code base.