Working toward 2.0, the language package has seen quite a bit of cleanup and restructuring mostly for removing features we considered to be CMS specific (i.e. search callbacks) and shifting toward a non-static API (this mostly affected the Text class). All in all, the functionality right now is still pretty close to what we've known for a while. I'd like to throw some ideas out though that start changing some of that structure.
2) Introduce the possibility of named parameters. Either as a full replacement for Text::sprintf(), a changed signature in existing Text methods, or a new method altogether, named parameter support could potentially make working with translations easier (instead of needing to deal with sprintf ordering, named parameters would identify what each item in a string actually is).
3) A separated message catalog from the Language instance. Instead of each Language instance containing an internal store of the processed key to string translations, this data could be extracted into a separate catalog object. Doing this could potentially introduce the future possibility of caching compiled translations (the app doesn't need to load files and run them through the INI parser on each request but could load a cached catalog with the already processed strings).
4) Proper fallback language support. The CMS has a patch that allows it to always load strings from the en-GB language files. The Framework should implement something similar but allow that fallback language to be defined in the Language object. Maybe this just means using the Language::$default value more efficiently.