David C. Partridge (25 October 2024 10:03) wrote: > While I applaud the thought of using std::format where appropriate, I > can't see what converting the existing tr() mechanism to that will > gain Qt Development or Qt Users
This needn't be about Qt converting its translations to use std::format; it's about being able to support it, if some project using Qt chooses to. After all, tr() takes a developer-written string and converts it to a translator-written string selected based on the user's locale settings and the singular/.../plural machinery. Once tr() has returned that string, the calling code can do what it likes with it. So while we've traditionally called .arg() on it to do formatting within the string, there's no obvious or sensible reason why a project using Qt shouldn't use std::format, or Qt's UTF-16-enhanced version of it, on the resulting strings, provided their developers and translators are all on the same page about how that works. Given that Qt is on its way to adding std::format support, it makes sense to support projects that chose to handle it that way. After all, if they're using PySide or PyQt they have a richer cousin of std::format at their disposal, which we should at least support for translations of PySide and PyQt applications, if only because it is native and idiomatic for python programmers. Ensuring that same support also works for C++ projects that want to use std::format follows naturally, as std::format is presumably expected to become the native and idiomatic way to do string formatting in C++, too. Eddy. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development