QTranslator::load() exists in three variants, of which two are really hard to use and write:

bool QTranslator::load(const QString &filename, const QString &directory = QString(), const QString &search_delimiters = QString(), const QString &suffix = QString())
bool QTranslator::load(const QLocale &locale, const QString &filename, const QString &prefix = QString(), const QString &directory = QString(), const QString &suffix = QString())
bool QTranslator::load(const uchar *data, int len, const QString &directory = QString())

Especially the first two ones are hard to use properly, and it's easy to confuse arguments (4 QString's in a row)!

I think a Property based API would greatly improve readability, and also allow some more flexibility, for example:

QTranslator translator;
translator.setLocale(QLocale()); // could be the default?
translator.setSearchPath(":/i18n"); // could be the default? Should we support multiple search paths?
translator.setBaseName("app_");
translator.load();

An implementation could also remove some features that are IMO unnecessary:

• No need to look up for files without a suffix, or a suffix different from '.qm'.
• No need to look up for files without a locale part.
• No need for setting a separate prefix, you can always specify this as part of name.

The API should instead make use cases easy which we miss so far:

• Look up translations in common places, with sane defaults (QLibraryInfo::TranslationPath, AppData/i18n ...)
• Consistenly load the same locale for different .qm files (e.g. qt_xxx.qm, myapp_xxx.qm)

Finally, the lifetime of a QTranslator object is currently problematic - it has to be installed before the first tr() call, until the last tr() call, whenever that works. Ideally the lifetime would be bound to QCoreApplication, e.g. by making QTranslator a shared object in the background.