No, there are architectual flaws with _T() which is why we didn't use it. PM and I argued for a long time about how to go about it, and I think, given the amount of time we tried to cram this in, it's very good. We've even made some revisions since then.
Problems with _T: Since we don't have the source to 0.9.9 I can't say for sure, but it appears to use Small's new ability to return arrays (and before that I'm sure it passed a cell reference). This means the translation occurs BEFORE the string is sent.
With AMX Mod X, the translation occurs AFTER the string is sent. This is VERY important because then the native command can modify the string before it's sent. In the case of client_print, it allows you to send a message to all clients in their OWN translated language, rather than in the server's language. I don't know if dJeyL found a way around this, but _T() would say "no".
However, here are the changes we've made to the multilingual system since.
You can now embed multiple layers of translating. This will be valid:
Code:
[en]
Msg_Greeting = Hello, %d! You have %d messages.
Latest_Msg = Latest Message: %s
Code:
//PLUGIN = plugin name
client_print(id, print_chat, "[%s] %L %L", NAME, id, "Msg_Greeting", clientName, Messages, id, "Latest_Msg", LatestMessage)
//Param 1 goes to %s
//Param 2,3,4,5 go to the first %L
//Param 6,7,8 go to second %L
While certainly not pretty, this is definitely a useable system.
Lastly, because people might need a _T() style mechanisms for things that don't pass through format_amxstring() / MF_FormatAmxString(), we'll provide LTrans() to wrap %L. It will work the same way, and will require %L.
Code:
copy(string, 128, LTrans("[%s] %L %L", NAME, id, "Msg_Greeting", clientName, Messages, id, "Latest_Msg", LatestMessage)
I hope this clears things up
